CSRF の概念: CSRF クロスサイト リクエスト フォージェリ (クロスサイト リクエスト フォージェリ) は、XSS 攻撃と同様に多大な害を及ぼします。
#攻撃者があなたの ID を盗み、あなたの名前で悪意のあるリクエストを送信します。このリクエストはサーバーにとって完全に合法ですが、あなたの名前で電子メールやメッセージを送信するなど、攻撃者が予期する操作を完了します。 、アカウントを盗み、システム管理者を追加し、さらには商品の購入、仮想通貨の送金などを行うことができます。 (推奨学習:
PHP プログラミングの入門から熟練度まで )
例: Web A は CSRF 脆弱性のある Web サイト、Web B は攻撃者によって構築された悪意のある Web サイト、ユーザー C はWeb A Web サイトの正当なユーザー。
CSRF 攻撃に対する防御:
現在、CSRF 攻撃を防御するには 3 つの主な戦略があります: HTTP Referer フィールドを確認する、リクエスト アドレスにトークンを追加するヘッダーのカスタム属性を確認して確認します。
(1) HTTP Referer フィールドの確認
HTTP プロトコルによると、HTTP ヘッダーには Referer と呼ばれるフィールドがあり、これには、HTTP リファラーの送信元アドレスが記録されます。 HTTPリクエスト。通常の状況では、安全な制限付きページへのアクセス要求は同じ Web サイトから送信されます。たとえば、http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory にアクセスする必要がある場合、ユーザーは最初にログインする必要があります。 Bank.example に移動し、ページ上のボタンをクリックして転送イベントをトリガーします。
このとき、送金リクエストの Referer 値は、送金ボタンがあるページの URL になります。通常は、bank.example ドメイン名で始まるアドレスになります。ハッカーが銀行の Web サイトに CSRF 攻撃を実装したい場合、自分の Web サイトでリクエストを作成することしかできません。ユーザーがハッカーの Web サイト経由で銀行にリクエストを送信すると、リクエストのリファラーはハッカー自身の Web サイトを指します。 。
したがって、CSRF 攻撃を防御するには、銀行 Web サイトは各送金リクエストの Referer 値を確認するだけで済みます。bank.example で始まるドメイン名であれば、リクエストが銀行からのものであることを意味します。ウェブサイト自体はい、合法です。リファラーが別の Web サイトである場合、ハッカーによる CSRF 攻撃である可能性があり、リクエストは拒否されます。
(2) リクエスト アドレスにトークンを追加して検証する
CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造できるためです。リクエスト内のすべてのユーザー認証情報は Cookie 内に存在するため、ハッカーは認証情報を知らずにユーザー自身の Cookie を直接使用してセキュリティ検証を通過できます。
CSRF に対抗するには、ハッカーが偽造できない情報をリクエストに含めることが重要です。この情報は Cookie には存在しません。
ランダムに生成されたトークンをパラメーターの形式で HTTP リクエストに追加し、サーバー側でインターセプターを作成してトークンを検証できます。リクエストにトークンがない場合、またはトークンの内容が正しくありません。CSRF 攻撃によりリクエストが拒否された可能性があると考えられます。
(3) HTTP ヘッダーの属性をカスタマイズして検証する
このメソッドでも、前のメソッドとは異なり、トークンを使用して検証を実行します。トークンはパラメータの形式で HTTP リクエストに配置されませんが、HTTP ヘッダーのカスタム属性に配置されます。 XMLHttpRequest クラスを使用すると、このタイプのすべてのリクエストに csrftoken HTTP ヘッダー属性を一度に追加し、そこにトークン値を入れることができます。これにより、従来のリクエストにトークンを追加する煩わしさが解消されると同時に、XMLHttpRequestでリクエストしたアドレスがブラウザのアドレスバーに記録されず、トークンが他に漏洩する心配もなくなりました。リファラー経由のウェブサイト。
以上がPHPでcsrf攻撃を防ぐ方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
