csrf 防御方法には次のものが含まれます: 1. HTTP Referer フィールドを検証する; 2. リクエスト アドレスにトークンを追加して検証する; 3. HTTP ヘッダーの属性をカスタマイズして検証する。 CSRF は、ユーザーが現在ログインしている Web アプリケーション上で意図しない操作を強制する攻撃手法です。
csrf は、現在ログインしている Web アプリケーション上でユーザーに意図しない操作を強制する攻撃手法です。
csrf 防御方法:
CSRF 攻撃を防御するための主な戦略は現在 3 つあります:
1. HTTP Referer フィールドを確認します;
2.リクエスト アドレスにトークンを追加して確認します;
3. HTTP ヘッダーの属性をカスタマイズして確認します。
詳しい説明をしましょう:
(1) HTTP Referer フィールドを確認します
HTTP プロトコルによると、 Referer と呼ばれる HTTP ヘッダーは、HTTP リクエストの送信元アドレスを記録します。通常、安全な制限付きページへのアクセス要求は、同じ Web サイトから送信されます。ハッカーが銀行の Web サイトに CSRF 攻撃を実装したい場合、自分の Web サイトでリクエストを作成することしかできません。ユーザーがハッカーの Web サイト経由で銀行にリクエストを送信すると、リクエストのリファラーはハッカー自身の Web サイトを指します。 。
したがって、CSRF 攻撃を防御するには、銀行 Web サイトは各送金リクエストの Referer 値を確認するだけで済みます。bank.example で始まるドメイン名であれば、リクエストが銀行からのものであることを意味します。ウェブサイト自体はい、合法です。リファラーが別の Web サイトである場合、ハッカーによる CSRF 攻撃である可能性があり、リクエストは拒否されます。
この方法の明白な利点は、実装がシンプルで簡単であることです。Web サイトの通常の開発者は、CSRF の脆弱性について心配する必要はありません。必要なのは、セキュリティに敏感なすべてのリクエストにインターセプタを追加することだけです。最後にReferer値を確認することができます。特に現在の既存システムの場合、既存システムのコードやロジックを変更する必要がなく、リスクもなく、非常に便利です。
(2) リクエスト アドレスにトークンを追加して検証する
CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造できるためです。リクエスト内のすべてのリクエスト すべてのユーザー認証情報は Cookie 内に存在するため、ハッカーは認証情報を知らずにユーザー自身の Cookie を直接使用してセキュリティ検証に合格することができます。
CSRF に対抗するには、ハッカーが偽造できない情報をリクエストに含めることが重要です。この情報は Cookie には存在しません。ランダムに生成されたトークンをパラメータとしてHTTPリクエストに追加し、サーバー側でトークンを検証するインターセプタを作成することができますが、リクエストにトークンが存在しなかったり、トークンの内容が間違っていたりする場合は、トークンが不正である可能性があると考えられます。 CSRF 攻撃であるため、リクエストは拒否されます。
(3) HTTP ヘッダーの属性をカスタマイズして検証する
このメソッドでもトークンを使用して検証を実行します。前のメソッドとの違いは、ここで、トークンを HTTP リクエストのパラメータとして使用すると、HTTP ヘッダーのカスタム属性にトークンが配置されます。 XMLHttpRequest クラスを使用すると、このタイプのすべてのリクエストに csrftoken HTTP ヘッダー属性を一度に追加し、そこにトークン値を入れることができます。
これにより、以前の方法でリクエストにトークンを追加する不便さが解決されると同時に、XMLHttpRequest でリクエストされたアドレスがブラウザのアドレス バーに記録されなくなり、リファラーを通じてトークンが他の Web サイトに漏洩します。
ただし、この方法には大きな制限があります。 XMLHttpRequest リクエストは通常、Ajax メソッドでページの部分的な非同期リフレッシュに使用されます。すべてのリクエストがこのクラスでの開始に適しているわけではなく、このクラス リクエストを通じて取得されたページはブラウザによって記録できないため、前方、後方、更新が可能です。 、収集などの操作はユーザーに不便をもたらします。
さらに、CSRF 保護を持たないレガシー システムの場合、この方法を保護に使用したい場合は、すべてのリクエストを XMLHttpRequest リクエストに変更する必要があります。これにより、Web サイト全体がほぼ書き換えられることになり、間違いなくコストがかかります。 . は受け入れられません。
関連する問題をさらに知りたい場合は、php 中国語 Web サイト にアクセスしてください。
以上がCSRF防御方法とは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。