クロスサイトリクエストフォージェリとは？

クロスサイトリクエストフォージェリ（CSRF）とは？

クロスサイトリクエストフォージェリー攻撃は、混乱した使節*サイバー攻撃の一種で、ユーザーを騙して、認識させることなく自分の認証情報を使用させ、口座からの資金移動、メールアドレスとパスワードの変更、またはその他の望ましくないアクションなどの状態を変化させる活動を起動させます。

一般ユーザーに対する潜在的な影響も大きなものではありますが、管理者アカウントに対するCSRF攻撃が成功すると、サーバー全体が危険にさらされ、Webアプリケーション、API、その他のサービスが完全に乗っ取られる可能性があります。

クロスサイトリクエストフォージェリーの仕組みは？

この攻撃は、状態を変化させるリクエストを対象に重点を置いており、これはあるデータの値を別の値に変更するタイプのリクエストを指します。例えば、対象となるリクエストは、購入を行うことや、アカウントの値の変更を行う場合があります。興味深いことに、これは「目に見えない攻撃」であり、攻撃者にデータを返さないため、データ盗難には不向きです。

ここでは、クロスサイトリクエストフォージェリ攻撃の4つのステップの例を示します。

1. 攻撃者は、実行すると特定の銀行から攻撃者の口座に1万ドルを送金するという偽のリクエストを作成します。
2. 攻撃者は、この偽造したリクエストをハイパーリンクに埋め込み、大量の電子メールで送信したり、Webサイトに埋め込んだりします。
3. 攻撃者によって設置されたメールやWebサイトのリンクをクリックすると、被害者は銀行に1万ドルの送金依頼をすることになります。
4. 銀行のサーバーはこのリクエストを受信し、被害者が適切に認証されていることから、このリクエストを正当なものとして扱い、送金を行います。

CSRF攻撃は、その手法も様々ですが、一般的に以下のような特徴があります。

1. ユーザーのIDに依存するWebサイトを悪用する
2. ユーザーのブラウザーを騙して、標的のサイトにHTTPリクエストを送信させる
3. これには副作用があり、適切なCSRF保護が施されていないHTTPリクエストを使用することが含まれます。

HTTP動詞が異なるとCSRF攻撃に対する脆弱性も異なるため、防御策も様々なものになります。これは、Webブラウザがそれぞれの動詞を異なる方法で処理することに起因します。

HTTP GETリクエストには、画像タグ内にパラメータなどが埋め込まれており、それらを操作して悪用される可能性があります。通常、GETリクエストは状態を変更しないため、適切に実装されたWebアプリケーションや他のリソースのCSRFのターゲットとしては有効ではありません。

HTTP POSTは状態を変更するために使用されるため、保護の必要性が高くなります。このため、Webブラウザは、クロスオリジンセキュリティポリシーを含む同一生成元ポリシー（SOP）とオリジン間リソース共有（CORS）と呼ばれるセキュリティ対策を実装しています。SOPは同一生成元からのリクエストのみを許可し、CORSは異なる生成元からの特定の種類のリクエストのみを許可します。これらの実装を組み合わせることで、リクエストやWebページが異なる生成元とやり取りする機能を制限し、CSRF攻撃（など）を防ぐことができます。

PUTやDELETEなどの他のHTTP動詞は、SOPとCORSを使用してのみ実行できるため、多くのクロスサイト攻撃を軽減することができます。

一般的ではありませんが、これらのセキュリティ対策を明示的に無効にしているWebサイトも存在し、Webブラウザの内部で無効にすることも可能です。

クロスサイトリクエストフォージェリーを軽減する方法は？

CSRF攻撃を軽減するための最も一般的な方法は、2つの方法のいずれかを使用してアンチCSRFトークンを使用することです。トークンの実装は若干異なりますが、基本的な原理は同じです。ランダムに生成されたトークン文字列を作成して比較することで、攻撃者は奇跡的にありえない推測をしなければ攻撃を実行できる可能性は低くなります。

シンクロナイザートークンパターン。

ユーザーが送金を行う銀行のWebページなどにアクセスすると、銀行のWebサイトによってランダムトークンがフォームに埋め込まれます。ユーザーがフォームを送信するとランダムなトークンが返され、銀行は2つのトークンが一致するかどうかを確認することができます。トークンが一致した場合、送金が行われます。攻撃者にはWebページに作成されたランダムトークンの値にアクセスする手段がなく、もしページをリクエストしたとしても、同一生成元ポリシーによって攻撃者がレスポンスを読むことはできません。

この方法の軽減の欠点は、リクエストごとにトークンの有効性をチェックするため、サーバー側の負担が増えることです。また、ユーザーが複数のブラウザウィンドウを使用している場合や、異なるソフトウェアがリクエストを行うその他の条件下では、問題が発生する可能性があります。トークンの範囲をリクエストごとではなく、セッションごとに拡張することで、このような問題の一部を回避することができます。

Cookie-to-headerトークン。

もう一つの方法では、ランダムなトークンを含むクッキーを訪問者のWebブラウザーに発行します。クライアント側で動作するJavaScriptは、Cookie内のトークンの値を読み取り、それをリクエストごとに送信するHTTPヘッダーにコピーします。ユーザーが送信したリクエストが正当であった場合、サーバーはヘッダー内の値を確認することができます。それ以外の場合は失敗となるため、攻撃が成功する確率は軽減されます。

WAFを介してカスタムルールを使用することで、ユーザーは特定のCSRF攻撃を防止ぐことができます。詳しくはCloudflareのWeb Application Firewallをご覧ください。

*混乱した使節の問題

混乱した使節とは、コンピュータのプログラムが騙されて、その権限を悪用されることを指します。このような脆弱性に関連するリスクがあるからこそ、機能ベースのセキュリティが悪用に関連するリスクの低減に役立ちます。例えば、ソフトウェアをインストールする際、現在のほとんどのコンピュータでは、ユーザーがログインする必要があります。これは、ユーザーが誤って自分の権限でインストールを許可したときに、コードが意図せず実行されるのを防ぐことができます。