知っておきたいクロスサイトリクエストフォージェリの仕組み

2020-03-12 00:00

CSRF（Cross-site Request Forgery：クロスサイトリクエストフォージェリ） は Web アプリケーションのユーザー（利用者）に意図しない通信リクエストを送信させ、利用者の意図しない処理をサービスに実行させることが可能となる脆弱性、またはその脆弱性を利用した攻撃手法を指します。

昨今のサイバーセキュリティにおける代表的な攻撃手法です。

本記事では CSRF の仕組みから対策方法までそれぞれ解説していきます。

CSRF の概要

CSRF（クロスサイトリクエストフォージェリ）は、Web アプリケーションが偽装された（本来送信されるべきではない）リクエストを正規のものとして受信してしまう脆弱性、または攻撃手法を意味します。

CSRF には呼び名がいくつか存在し、以下のような名称で呼ばれることもあります。

シーサーフ
XSRF
リクエスト強要
セッションライディング

※名前の似ている攻撃手法としてXSS（クロスサイトスクリプティング）がありますが、全く異なる種類の攻撃です。

攻擊者側はこのCSRFの脆弱性を利用することで、ユーザーに高額の支払いや SNS への投稿などの通信を送付させ、それを成立させることができます。

また、アプリケーションユーザー側でこの攻撃を防御する手立ては無いため、この攻撃手法はリクエスト強要と呼称されることがあります。

典型的な CSRF 攻撃の流れを簡単に以下に紹介します。

CSRF 攻撃の流れ

攻擊者はある金融機関のオンラインサイトにおいて、自身の口座に送金するリクエストを含んだ URL を生成する
攻擊者は金融機関のサイトにログインしているユーザー A に対して、上記の URL を踏ませるような仕掛けを実行する（公開掲示板への書き込み、SNS 経由、フィッシングメールなど）
ユーザーがログインした状態で、該当の URL を踏むことで、ユーザーが気づかないうちに攻擊者が仕込んだリクエストが金融機関のオンラインサイトに対して送信される
金融機関のオンラインサイトの Web アプリケーションはリクエストを正常なものとして受け取り、処理する

また、CSRF 攻撃の対象は Web アプリケーションにログインしているユーザーと思われがちですが、もちろんログインしていない状態のユーザーに対して実施される攻撃も可能です。

たとえばログインシステムを持たないネット掲示板などに意図しない書き込みをさせるなどと行った攻撃方法が例として挙げられます。

CSRF への対策方法とは

CSRF に対する対策方法はどのようなものがあるのでしょうか。
これはユーザー側と Web アプリケーション側双方で取るべき対策があります。

ユーザー側の対策例

使用していないときには Web アプリケーションやオンラインサイトからログアウトする。
ユーザー名とパスワードの保護（ソーシャルエンジニアリングなどで流出させない）
ブラウザにパスワードを記憶させない。
アプリケーションにログインしているときに同時にブラウジングすることを避ける。

これに対して Web アプリケーション側ではどのような対策が必要になるでしょうか？

CSRF 攻撃で使われるリクエストは、基本的に攻撃者が勝手に作成したものです。

そのため、CSRF 対策の基本的な考え方として、リクエストがユーザからの正規なものか、攻擊者が作成した偽装リクエストをサーバーが識別できれば CSRF への対策が可能となります。
（例: ユーザーと Web アプリケーションの通信の中に、攻撃者が推測できない情報をはじめから入れておくなど）

Web アプリケーション側の対策例

ライブラリやフレームワークでの機能 / 対策の利用

CSRF は Web アプリケーションにおける代表的な脆弱性、攻擊手法であるがゆえに、ライブラリやフレームワークにおいてもこれを防止するための機能や対策、実装方式が設けられていることが多分にあります。

そのため開発に際しても選択したライブラリやフレームワークのマニュアルなどを読み、CSRF の対策を実装していくことが基本になります。

また、後ほど脆弱性が発見された場合にも修正パッチやアップデートを迅速に適用することによって、脆弱性を利用した攻擊にさらされる危険性を下げることができます。

※以前掲載した「OWASP Top 10」に関するブログ記事に記載しましたが、「OWASP Top 10 2017」から CSRF が外れた際にも、理由として「各フレームワークが CSRF への対策を備えたため」との言及がなされていました。

具体的な実装例

トークンを利用した対策

先述の対策の実装例としてポピュラーなものが、トークンを利用して正しいリクエストを識別する方法です。

トークンとは第三者が知りえない秘密情報を意味し、この情報を Web アプリケーションとブラウザ間で突合し、CSRF を利用したトークンを持っていないリクエストをブロックします。
特にワンタイムトークン（1回の送信ごとに変更されていくトークン）を利用した対策方法はポピュラーな対策の一つとして扱われています。

具体的なワンタイムトークンの実装方法としては、まずランダムな文字列（トークン）を生成し、Web アプリケーションのユーザーのセッションに保存します。
そして生成したトークンを HTML フォームなどに hidden で埋め込みます。

リクエスト先では、セッションに保存したトークンと送信されたトークンが一致するか確認を行い、一致しない場合は不正なリクエストとして扱います。
攻撃者は生成されたトークンの値を知ることができないため、不正なリクエストとして識別されます。

※ワンタイムトークンでなければならないというわけではなく、第三者から推測困難であることが、CSRF トークン対策として重要なポイントになります。そのため、固定トークン（ログイン完了後ずっと固定値になる）でも CSRF 対策は可能です。しかしトークン漏洩時や、リプレイアタックなどへの考慮が必要となってきます。）

独自 HTTP ヘッダ（カスタムヘッダ）の追加

CSRF 攻擊に対する対策としてカスタムヘッダを付与する方法が存在します。
これらの条件を満たさないヘッダを持つリクエストはブラウザがエラーとして扱うため、リクエストをブロックすることが可能です。

また「独自 HTTP ヘッダの追加」対策と合わせて、二重送信クッキー(Double Submit Cookie)という対策方法が実装されるケースがあります。

二重送信クッキーとは、Cookie に設定されたトークンと、カスタム HTTP ヘッダ（場合によっては HTTP Body）に付与されたトークン値を突合させ、同値である場合のみ正常なリクエストとして処理するという対策方法です。

Same Site 属性（Lax、Strict）の追加

SameSite=Lax や SameSite=Strict を付与することで CSRF 攻擊を防ぐこともできます。

Chrome 80 以降、SameSite が宣言されていない Cookie は SameSite=Lax と扱われ、クロスサイトで Cookie を利用する場合には明示的に SameSite=None; Secure を付与する必要があります。

ライブラリやツールを最新版にアップデートする

CSRF が各ライブラリやフレームワークで対策がなされたとはいっても、代表的な脆弱性であることには変わりなく、今でも CSRF の脆弱性は発見されています。

つい先日も、OSS の IP アドレス管理ツール「phpIPAM」において、CSRF の脆弱性が発見され、修正されたバージョンが提供されています。
（詳しくは NVD によるCVE-2020-7988 をご参照ください）
ライブラリやフレームワークに脆弱性が発見されたら対応できるように日頃からウォッチすることが重要です。

先日のクロスサイトスクリプティング（XSS）に関するブログ記事にも同様の言及がありましたが、定期的に脆弱性に関する情報を確認し、最新版にアップデートするようにしましょう。

さいごに

CSRF はクロスサイトスクリプティング同様、Web 開発者も運営者も注意を払うべき脆弱性であり、また適切な対策を行えば防ぐことができる脆弱性です。

利用者と Web アプリケーション間のリクエストを識別可能にすること、これを意識することが問題解消へ向けての第一歩となります。
Web に携わる開発者・管理者として、セキュア開発を意識しながら開発を進めていくことが大切になります。

また、稼働中の Web サイト・Web アプリケーションに対して、CSRF の検証・対策を実施するのは大変な労力がかかります。
脆弱性が見つかっても開発やビジネスの優先度から対策が後回しになったり、放置になるケースもあるのではないでしょうか。

CSRF は攻撃が成功した場合、不正送金や過激な内容の偽装投稿などに直結しやすく、ご利用中のユーザーや顧客、果ては社会全般など被害の影響が大きいため、継続的にリソースを確保して検証および対策を実施していきましょう。

最後になりますが、Web アプリケーションで用いられるフレームワーク・ライブラリに潜む CSRF の脆弱性については、yamory を用いることで検出が可能です。
ぜひ一度お試しいただければ幸いです。