CSRFとは何か？CSRFを防ぐ方法は？

デジタル時代において、インターネットは私たちの日常生活に深く織り込まれています。買い物からさまざまなプラットフォームでの交流、銀行取引まで、多くの活動がオンラインに移行しています。金融取引がより広範になるにつれて、ネットワークセキュリティの影響もより顕著になっています。インターネット上で最も一般的なサイバー脅威の一つがCSRF（クロスサイトリクエストフォージェリ）であり、その詳細を探ることが重要です。

CSRFとは何か？

CSRF攻撃は、ターゲットとなるウェブサイトのリクエスト検証メカニズムの脆弱性を利用します。特定の状況下で、ユーザーはターゲットウェブサイトにログインしている間に悪意のあるリクエストを無意識のうちに実行してしまいます。攻撃者は通常、ターゲットウェブサイトのドメインに似たアドレスを使用し、ユーザーにクリックを促します。彼らは画像の読み込みや隠しフォームとして悪意のあるコードを埋め込み、ターゲットウェブサイトにリクエストを送信し、秘密裏に不正なアクションを実行します。ユーザーのパスワード変更や不正な銀行振り込みなどの目的は、ユーザーに大きな損失をもたらす可能性があります。

実例

電子銀行サービスを提供するe-bank.comというウェブサイトを想像してください。このサイトには、振り込みリクエストを送信するための/transferというページがあります。ユーザーがe-bank.com/transferページにアクセスすると、ユーザーが入力した詳細を表示するフォームが表示されます。フォームが完了して送信されると、HTTP POSTリクエストがページのアドレスに送信され、ユーザーが入力した受取人や金額などのパラメータが含まれます。

この時点で、攻撃者は、送信アドレスをe-bank.com/transferに向けた不可視のフォームを持つ悪意のあるページを作成できます。攻撃者はフォームに特定の受取人と金額のパラメータを事前に入力します。ユーザーがこの悪意のあるページをクリックするように騙されると、ブラウザはJavaScriptコードを実行し、フォームを送信します。

ユーザーがe-bank.comに登録されていないかログインしていない場合、振り込みリクエストは実行できません。しかし、ユーザーが最近サービスを利用しており、ログイン状態が持続している場合、振り込みリクエストが成功する可能性があります。

これがCSRF攻撃の概要です。原理は単純ですが、大きな潜在的な危害を秘めています。幸いなことに、このような攻撃を防ぐための多くの成熟した方法があります。以下でそれらを探ってみましょう。

CSRFを防ぐ方法

この問題に対処するには、積極的および受動的な対策があります。

HTTPメソッド制限とReferer制限

開発者として、サービス内の機密性の高いアドレスに対してより厳しい制限を課すことができます。例えば：

データ送信を必要とするアドレスに対して、HTTP GETリクエストの使用を禁止し、POSTリクエストの使用を強制します。これにより、攻撃者が悪意のあるページを作成する際の複雑さが増します。
さらに、HTTPリクエストヘッダーのRefererフィールド（Referer）を制限し、既知の正当なアドレスからのみ許可し、悪意のあるリクエストをブロックできます。

これはシンプルで積極的な保護策であり、コストは低いですが、攻撃に対してやや脆弱です。

CSRFトークン

CSRFトークンは広く採用されている解決策で、サーバーサイドのセッションメカニズムと組み合わせてCSRF攻撃を防ぎます。具体的には、サーバーサイドのプログラムが保護が必要なページにランダムに生成されたCSRFトークンを隠し入力フィールドとしてフォームに埋め込みます。同時に、サーバーサイドでセッションを作成し、このランダムな文字列を有効期限付きで保存します。

ユーザーがページをリクエストすると、サーバーはセッションを初期化し、サーバーサイドにデータを保存し、クライアントサイドのブラウザにSession IDを含むCookieを設定して関連付けます。CSRFトークンはセッションに保存されます。フォームが送信されると、CSRFトークンが送信されます。サーバーサイドのプログラムはこのトークンをセッションに保存された部分と比較します。検証が成功すると、後続のロジックが実行されます。そうでない場合、エラーが返されます。同時に、次の送信のために新しいCSRFトークンがフォームに挿入されます。

これは積極的な保護策であり、ある程度の労力を要しますが、強力な保護を提供します。

クロスオリジン保護

私たちはしばしばCORS（クロスオリジンリソースシェアリング）という技術に出会います。これは、ブラウザがクロスオリジンリクエストを許可するかどうかを示す仕様です。現代のブラウザはこの仕様をサポートしています。既存のページでFetch/XHRリクエストを開始すると、ブラウザはHTTP OPTIONSリクエストを送信し、ターゲットサービスが現在のソースアドレスからのリクエストを許可するかどうかを事前にチェックします。サーバーは許可されたソース、リクエストメソッド、ヘッダーを指定するレスポンスヘッダーリストを提供します。ブラウザはこれらの指示に従い、クライアントサイドで禁止されたリクエストを防ぎます。

これは別の積極的な保護策であり、サーバーサイドで設定可能ですが、通常のユーザーがこの機能を無効にする可能性は低いものの、クライアントサイドでは依然として可能です。

サードパーティCookieのブロック

私たちが開発するサービスでは、ユーザーのSession IDをCookieに保存してログイン状態を維持することがあります。CookieはSameSite設定をサポートしており、ブラウザがクロスオリジンサイトにCookieを送信するのを防ぎます。CSRF攻撃を試みると、ターゲットサイトで認証されていない状態になります。

さらに、HTTP Cookieメカニズムの悪用によるクライアント追跡のため、ブラウザ開発者はサードパーティCookie（Cookie Countdown）を段階的に制限およびブロックすることを決定しました。ドメインAのページがドメインBへの呼び出しを試みると、CORSルールチェックを通過しても、ブラウザはそのクロスオリジンサイトにCookieを送信しません。

Chrome Timeline Example

まとめ

APIゲートウェイとして、Apache APISIXとAPI7 Enterpriseは、前述の2つの保護策であるCSRFトークンとCORSをサポートし、CSRF攻撃を防ぎます。

結論として、CSRF攻撃を防ぐには、サーバーサイド、ブラウザ、HTTPプロトコルなど、さまざまな技術を組み合わせた多面的なアプローチが必要であり、包括的な保護を実現します。