(CJP) 大きな会議テーブルの周りに 5 人か 6 人のバックエンド開発者と一緒に座っていました。 月曜日の朝 10 時、私たちは皆黙々とラップトップで作業していました。 慌ただしい雰囲気が漂い、全員が目の前の仕事に集中しようとしていました。
2時間も経たないうちに、私はオフィスに足を踏み入れましたが、まだ害はありませんでした. すぐに奥の会議室に呼ばれ、自分の机に座る暇もありませんでした。 それでも私はすぐにコーヒーを手に取り、他の数人の同僚がすでに集まっている奥に行きました。
彼らと一緒に私たちの上司、ナイスガイがいました。 「上層部」の文化も何もなく、私たちはただの同僚でした。 部屋にいた他の人たちはすでに何が起こっているかを知っていたので、彼は私に個人的に説明してくれました。
社内フレームワークにバグがありました。
「確かに最初じゃないな」 — 思ったのを覚えています。
この時点で、この特注のフレームワークを数年間使用していました。 多かれ少なかれ、200 の Web サイトが影響を受けました。
バグはばかげた間違いでした — 結局のところ、どのバグがそうではないでしょうか?
フレームワーク ルーターは URL を受け取り、繰り返されるスラッシュを除外します。 //admin になるだろう /admin. これは、HTTP 仕様の一部だと思います。 少なくとも私はそう言われましたが、再確認したことはありません。 ただし、問題は認証レイヤーにありました。 /admin は保護された URL でしたが、 //admin ではなかった。 したがって、ルーターは解決します //admin およびその下にあるすべてのページを管理セクションに追加すると、承認者はそれを管理者権限が必要な場所として認識しません。
言い換えれば、すべてのウェブサイトの管理セクションは、ログインせずに、単に置き換えるだけで入力できます。 /admin と //admin.
その後コーヒーを飲んだ記憶がありません。
そのため、私たちにできる唯一のことを行いました。すべての Web サイトを手動で更新し、一部の Web サイトは非常に古いバージョンのフレームワークを実行していました。 これを 5 人か 6 人の開発者で行うのに 3 日かかりました。 いくらかかるか計算できます。
結局、バグが悪用されたかどうかを実際に知ることはできませんでした。週末に同僚の 1 人が偶然発見したもので、数日以上アクセス ログを保持していませんでした。 そのため、過去数年間に誰かが私たちのサイトの 1 つに不正にアクセスしたかどうかを知ることはできませんでした。 ましてや、どのデータが漏洩したかを知ることはできません。
少なくとも有料クライアント向けの Web サイトを構築している場合は、独自のフレームワークを作成しないでください。 あなたの仕事がプロフェッショナルで安全であると信頼する人。 使用するフレームワークが何であれ、それが大規模なコミュニティによって支えられていることを確認してください。
あなたの考えを共有したいですか？ HNでそれらについて議論しましょう。
読んでくれてありがとう！ この投稿は、開発者としての私自身および個人的な経験について書いている「開発日記」シリーズの一部です。 もう少し読みたいですか？
このブログの最新情報を知りたい場合は、私をフォローしてください。
Twitter上で または私のニュースレターを購読してください：