yamory Blog

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

CSRF(Cross-site Request Forgery:クロスサイトリクエストフォージェリ) はWebアプリケーションのユーザー(利用者)に意図しない通信リクエストを送信させ、利用者の意図しない処理をサービスに実行させることが可能となる脆弱性、またはその脆弱性を利用した攻撃手法を指します。
昨今のサイバーセキュリティにおける代表的な攻撃手法です。

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

CSRFの概要

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

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

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

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

攻擊者側はこのCSRFの脆弱性を利用することで、ユーザーに高額の支払いやSNSへの投稿などの通信を送付させ、それを成立させることができます。また、アプリケーションユーザー側でこの攻撃を防御する手立ては無いため、この攻撃手法はリクエスト強要と呼称されることがあります。

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

CSRF攻撃の流れ

  1. 攻擊者はある金融機関のオンラインサイトにおいて、自身の口座に送金するリクエストを含んだURLを生成する

  2. 攻擊者は金融機関のサイトにログインしているユーザーAに対して、上記のURL を踏ませるような仕掛けを実行する(公開掲示板への書き込み、SNS経由、フィッシングメールなど)

  3. ユーザーがログインした状態で、該当のURLを踏むことで、ユーザーが気づかないうちに攻擊者が仕込んだリクエストが金融機関のオンラインサイトに対して送信される

  4. 金融機関のオンラインサイトの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を用いることで検出が可能です。ぜひ一度お試しいただければ幸いです。

オープンソース脆弱性管理ツール yamory

  • 利用中のOSSを抽出し
    脆弱性を自動スキャン
  • 脆弱性への対応優先度を自動で分類
  • 組織規模に合わせたプランを選択可能

フリー

¥0

個人向け

1チームまでの開発チーム作成

yamory を使いはじめる

プロ

有料料金はお問い合わせください

中〜大規模組織向け

無制限の開発チーム作成

開発チームを俯瞰できるセキュリティチーム機能

危険な脆弱性の Slack 連携通知機能

Jira Cloud と連携

シングル・サインオン(SSO)連携*

* SSO 連携は無料トライアルではご利用できません。プロプラン契約後からご利用できます。

30日間の無料トライアルを開始