通常、CSRF 攻撃を防御するために広く使用されている方法は、トークンの検証、HTTP リクエストのリファラーの検証、XMLHttpRequest のカスタム ヘッダーの検証の 3 つです。さまざまな理由から、これら 3 つの方法はどれも完璧ではなく、それぞれに独自の長所と短所があります。
1.CSRFの分類
クロスサイト リクエスト フォージェリ (CSRF) 攻撃では、攻撃者はユーザーのブラウザを通じて追加のネットワーク リクエストを挿入し、Web サイト セッションの整合性を侵害します。ブラウザのセキュリティ ポリシーにより、現在のページが任意のアドレスにリクエストを送信することが許可されています。つまり、ユーザーが制御できないリソースを閲覧している場合、攻撃者はページのコンテンツを制御してブラウザを制御し、慎重に作成されたリクエストを送信することができます。 。
1. ネットワーク接続。たとえば、攻撃者がファイアウォール内のリソースに直接アクセスできない場合、ファイアウォール内のユーザーのブラウザを使用して、アクセスしたいリソースにネットワーク リクエストを間接的に送信できます。攻撃者が IP アドレスベースの検証ポリシーをバイパスするために、被害者の IP アドレスを使用して要求を開始する状況さえあります。
2. ブラウザのステータスを取得します。ブラウザがリクエストを送信するとき、通常、ネットワーク プロトコルにはブラウザの状態が含まれます。これには、Cookie、クライアント証明書、認証ベースのヘッダーなど、多くのものが含まれます。したがって、攻撃者がブラウザを使用して、検証のために上記の Cookie、証明書、ヘッダーなどを必要とするサイトにリクエストを送信すると、そのサイトでは実際のユーザーと攻撃者を区別できなくなります。
3. ブラウザのステータスを変更します。攻撃者がブラウザ経由でリクエストを開始すると、ブラウザもサーバーの応答を分析して応答します。たとえば、サーバーの応答に Set-Cookie ヘッダーが含まれている場合、ブラウザは Set-Cookie に応答し、ローカルに保存されている Cookie を変更します。これらの変更は非常に巧妙な攻撃につながる可能性があります。これについてはパート 3 で説明します。
範囲内の脅威: このセクションは、危険の大きさに基づいて 3 つの異なる危険モデルに分割されます。
1. フォーラムは交流の場です。フォーラムなどの多くの Web サイトでは、ユーザーは限られた種類のコンテンツをカスタマイズできます。たとえば、通常、Web サイトではユーザーが画像やリンクなどの受動的コンテンツを送信できます。攻撃者がイメージ URL に悪意のあるアドレスを指定させた場合、このネットワーク要求によって CSRF 攻撃が引き起こされる可能性があります。これらの場所からリクエストを行うことができますが、これらのリクエストでは HTTP ヘッダーをカスタマイズできないため、GET メソッドを使用する必要があります。HTTP プロトコルの仕様では、リクエストが有害であってはいけないことが求められていますが、多くの Web サイトはこの要件を満たしていません。
2. Web 攻撃者。ここでの Web 攻撃者の定義は、攻撃者.com などの独自の独立したドメイン名を持ち、攻撃者.com の HTTPS 証明書と Web サーバーを持つ悪意のあるプロキシを指します。これらすべての機能の費用はわずか 10 ドルです。ユーザーが Attacker.com にアクセスすると、攻撃者は GET メソッドと POST メソッドの両方を使用してクロスサイト リクエストを開始できます。これは CSRF 攻撃です。
3. ネットワーク攻撃者。ここでのネットワーク攻撃者とは、ユーザーのネットワーク接続を制御できる悪意のあるエージェントを指します。たとえば、攻撃者はワイヤレス ルーターや DNS サーバーを制御して、ユーザーのネットワーク接続を制御できます。この攻撃には Web 攻撃よりも多くのリソースと準備が必要ですが、HTTPS サイトに対する脅威でもあると考えられます。HTTPS サイトはアクティブなネットワークしか保護できないためです。
範囲外の脅威: 以下に、この文書の範囲外である関連するハザード モデルもいくつかリストします。これらの危険に対する防御は、CSRF に対する防御を十分に補完できます。
1. クロスサイト スクリプティング (XSS)。攻撃者が Web サイトにスクリプトを挿入できる場合、攻撃者はその Web サイト上のユーザー セッションの整合性と機密性を侵害する可能性があります。一部の XSS 攻撃では、ユーザーの銀行口座から攻撃者の口座に送金するなど、ネットワーク リクエストを開始する必要がありますが、通常、CSRF 防御ではこれらの状況は考慮されません。より安全な実践を考慮して、Web サイトは XSS と CSRF の両方に対する保護を実装する必要があります。
2. マルウェア。攻撃者がユーザーのコンピュータ上でマルウェアを実行できる場合、攻撃者はユーザーのブラウザを制御して、信頼できる Web サイトにスクリプトを挿入することができます。現時点では、攻撃者がユーザーのブラウザを悪意のあるプラグインを含むブラウザに置き換える可能性があるため、ブラウザベースの防御戦略は効果がありません。
3. DNS の再バインド。CSRF と同様に、DNS 再バインドではユーザーの IP アドレスを使用して、攻撃者が指定したサーバーに接続できます。ファイアウォールの背後にあるサーバー、または IP アドレスに基づいて認証するサーバーには、DNS 再バインドに対する防御が必要です。DNS リバインディング攻撃と CSRF 攻撃の目的は非常に似ていますが、必要なソリューションは異なります。DNS 再バインド攻撃に対する簡単な解決策は、ホストの HTTP 要求ヘッダーを検証して、期待される値が含まれていることを確認することです。別の方法としては、DNS トラフィックをフィルタリングして、外部 DNS 名が内部プライベート アドレスに解決されないようにすることです。
4. 証明書エラー。HTTPS 証明書エラーが発生したときにユーザーがクリックしてアクセスし続ける場合、HTTPS が提供できるセキュリティ保護の多くは無意味になります。一部のセキュリティ研究者はこの状況の危険性を指摘していますが、この記事では、HTTPS 証明書エラーが発生した後、ユーザーがクリックし続けてアクセスしないことを想定しています。
5. 釣り。ユーザーがフィッシング Web サイトにアクセスし、認証時に個人情報を入力すると、フィッシング攻撃が発生します。ユーザーがフィッシング Web サイトと本物の Web サイトを区別することが難しい場合があるため、フィッシング攻撃は現在非常に一般的かつ効果的です。
6. ユーザー追跡。一部のパートナー Web サイトでは、クロスサイト リクエストを使用して、ユーザーの閲覧習慣に基づいて相関行動ライブラリを構築します。ほとんどのブラウザは、サードパーティ Cookie の送信を防止することで同様の追跡を防止していますが、ブラウザのこの機能はオフサイト リクエストを使用して回避できます。
2.CSRFにログインします。
ブラウザのネットワーク接続を悪用するかブラウザの状態を悪用するかにかかわらず、CSRF のほとんどの議論はサーバー側の状態を変更するリクエストに焦点を当てています。CSRF 攻撃は、信頼できる Web サイトにアクセスしたユーザーがブラウザの状態を変更することで損害を与える可能性がありますが、まだ十分に真剣に受け止められていません。CSRF 攻撃では、攻撃者は信頼された Web サイトでユーザーのユーザー名とパスワードを使用して、Web サイトへの偽造リクエストを開始します。リクエストが成功すると、サーバーは Set-Cookie ヘッダーで応答し、それを受信したブラウザーはセッション Cookie を作成し、ユーザーのログイン ステータスを記録します。このセッション Cookie は後続のリクエストをバインドするために使用されるため、攻撃者が認証のために使用することもできます。Web サイトによっては、CSRF 攻撃を受けると重大な結果が生じる可能性もあります。
検索履歴: Google や Yahoo を含む多くの検索エンジンでは、ユーザーが検索履歴の保存に同意するかどうかを選択でき、ユーザーが自分のプライベートな検索履歴を表示するインターフェースを提供しています。検索リクエストにはユーザーの習慣や興味に関する機密情報が含まれており、攻撃者はこれらの詳細を利用してユーザーを騙したり、ユーザーの ID を盗んだり、ユーザーを監視したりする可能性があります。攻撃者がユーザーとして検索エンジンにログインすると、ユーザーの検索履歴を閲覧できます。図 1 に示すように、ユーザーの検索クエリ レコードは攻撃者の検索レコードに保存され、攻撃者は自分のアカウントにログインしてユーザーの検索レコードを自由にクエリできるようになります。
図 1. ログイン CSRF 攻撃イベントの追跡グラフ。被害者が攻撃者の Web サイトにアクセスすると、攻撃者は Google へのクロスサイト リクエスト ログイン ボックスを偽造し、被害者が攻撃者によって Google にログインされるようにします。その後、被害者が検索を使用すると、攻撃者によって検索履歴が記録されます。
PayPal: PayPal では、ユーザーが自由に資金を相互に送金できるようになります。送金の際にはクレジットカードまたは銀行口座の登録が必要となります。攻撃者はログイン CSRF を使用して次の攻撃を開始できます。
1. 被害者は悪意のある販売者の Web サイトにアクセスし、PayPal を使用して支払うことを選択しました。
2. 被害者は PayPal にリダイレクトされ、自分のアカウントにログインするように求められます。
3. Web サイトは、ユーザーが PayPal アカウントにログインするのを待ちます。
4. 支払いの際、被害者はまず自分のクレジット カードを登録しますが、実際にはそのクレジット カードは悪意のある販売者の PayPal アカウントに追加されています。
iGoogle: ユーザーは iGoogle を使用して Google ホームページをカスタマイズできます。iGoogle にはいくつかのプラグインも含まれています。使いやすさを考慮して、これらのプラグインは「iGoogle に埋め込まれています」。つまり、iGoogle のセキュリティに影響を与えます。通常、iGoogle が新しいプラグインを追加すると、ユーザーに信頼するかどうかを決定するよう求められます。しかし、攻撃者は、CSRF 攻撃にログインして任意のプラグインをインストールすることで、ユーザーの意思決定を支援する可能性があります。
1. 攻撃者は、ユーザーのブラウザ認証を通じて iGoogle プラグイン (悪意のあるスクリプトを含む) をインストールし、そのプラグインをユーザーのカスタマイズされた iGoogle ホームページに追加します。
2. 攻撃者はユーザーを Google にログインさせ、iGoogle へのフレームワークを開きます。
3. Google は、被害者が攻撃者であると考え、攻撃者のプラグインを被害者にプッシュし、攻撃者が https://www.google.com ドメインでスクリプトを実行できるようにします。
4. 攻撃者は、(a) 正しい URL ページにログイン ボックスを構築する (b) ユーザーの自動的に入力されるパスワードを盗む (c) ユーザーが別のウィンドウにログインして document.cookie を読み取るのを待つ。
上記の脆弱性について Google に通知し、Google は 2 つの方法でこの脆弱性による被害を軽減する措置を講じました。まず、Google はインライン プラグインを非推奨にし、開発者が同様のプラグインを開発することを禁止し、より人気のある少数のインライン プラグインのみを許可しました。第 2 に、Google はログイン CSRF (後述) を防ぐためのプライベート トークン戦略を開発しましたが、この戦略はログイン ユーザーに対してのみ有効です。Google は、防御策を十分にテストし、有効であることが確認されたら、ログイン CSRF の脆弱性を否定するだろうと予想しています。
学習ルート
ネットワーク セキュリティに触れたことのない学生のために、詳細な学習と成長のロードマップを用意しました。これは最も科学的で体系的な学習ルートと言え、誰もがこの大まかな方向性に従って問題なく学習することができます。
同時に、成長ルートに応じた各セクションのサポートビデオも提供されます。
