2022.12.19

CSRF（クロスサイトリクエストフォージェリ）の仕組みと対策

サイバーセキュリティ

こちらの記事では、Webアプリケーションの脆弱性を利用したサイバー攻撃の一種である、CSRF(Cross Site Request Forgeries)について解説します。CSRFとはどういったものなのか、CSRFによってどのような被害が発生してしまうのか、またどういった対策を行えば良いのかを解説します。

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

CSRF(Cross Site Request Forgeries)は、Webシステムの脆弱性を利用したサイバー攻撃の一つで、クロスサイト(Webサイトをまたぐ)という意味と、リクエスト・フォージェリ(リクエストの偽造)という2つの意味からCSRFと呼ばれています。

CSRFは、攻撃者が罠として用意したWebサイト内で、ユーザーがリンクを踏むなどの操作を行うことで、ユーザーが全く意図していない偽造されたリクエストが強制的に正規のWebサイトへ送られてしまい、ユーザーの身に覚えのない書き込みがされてしまったり、ログイン中のサービスの強制退会などが行われてしまいます。前述した通り、Webサイトをまたいで偽造したリクエストが実行されてしまうため、Webサービスを利用する私たちにとって脅威のある攻撃になります。

CSRFの呼び名は複数あり、「シーサーフ」、「XSRF」、「リクエスト強要」、「セッションライディング」などと呼ばれます。

CSRFでの被害

CSRFの被害を受けてしまうと、サービスの提供者側とサービスの利用者側ともに大きな被害を受ける場合があります。ここから、どのような被害が実際に起こり得るのかをご説明します。

ログイン中のユーザーを狙った攻撃

CSRFの主な被害として、ユーザーがサービスにログインした状態を狙った攻撃があります。ユーザーがSNSや掲示板などのサービスにログインした状態であれば、ログインしているユーザーだけが利用可能な機能(画像や文章の投稿など)を使える状態になります。

ここで悪意のある攻撃者が、罠サイトへのリンクを含んだなりすましのメールなどをログイン中のユーザーへ送り、用意した罠サイトへユーザーを誘導します。そして罠サイト内のリンクやボタンをクリックさせる、もしくはスクリプトを実行させることで、ユーザーが全く意図していない投稿や情報がログインしていた正規のサービスへ送信されてしまいます。

万が一、送信されてしまった内容が個人への誹謗中傷や何かの犯罪の犯行予告だった場合には、投稿させられてしまったユーザーが加害者になってしまう場合にもなりかねません。

また、オンラインバンキングにログインした状態で攻撃者の用意した罠サイトへ誘導されてしまった場合、送金とは関係のないリンクやボタンをクリックしたはずが、勝手に送金処理が行われてしまうといった被害も考えられます。

このように、CSRFの被害では全く意図しないリクエストを強要させられてしまうため、リクエスト強要とも呼ばれています。

ログイン状態を利用しない攻撃

CSRFはログイン中のユーザーを狙った攻撃のイメージが強いですが、ログインしていない状態のユーザーを対象に攻撃が行われてしまう場合もあります。有名な事件として知られているのは、2012年に発生したパソコン遠隔操作事件です。

この事件では、匿名掲示板などを利用して複数人のパソコンが遠隔操作され、襲撃や殺人などの犯罪予告が行われました。悪意ある攻撃者が、ユーザーに興味を持たせて開きたくなるような言葉を使ったリンクを作成し、このリンクをクリックさせることで最終的にパソコンが遠隔操作され、掲示板に意図していない投稿が行われる仕組みでした。

このように、ログイン状態でない場合にも、意図していない投稿などが実行されてしまい、被害を受けてしまう場合があります。

XSSとCSRFの違い

CSRFと似ているサイバー攻撃として良く挙げられるのが、XSS(Cross Site Scripting)です。どちらもユーザーが意図しない動作を悪意を持った攻撃者が実行させる、といった点では同じように感じますが、その仕組みを見ると大きく違いがあります。

XSS(Cross Site Scripting)

XSSは、ユーザーがWebページにアクセスすることで、ブラウザ上で不正なスクリプトが実行されてしまう脆弱性、またはその攻撃手法のことです。

ユーザーが掲示板などに埋め込まれたURLをクリックしたり、入力フォームに入力し送信ボタンを押した際に、攻撃者が用意した不正なスクリプトをブラウザ上で実行させられてしまうことが特徴的です。

XSSの仕組みについてもっと知りたい方は、以下の「XSSの仕組みと対策について」をご覧ください。 https://envader.plus/article/13
CSRF(Cross Site Request Forgeries)

XSSが不正なスクリプトをブラウザ上で実行させられてしまうことに対して、CSRFはユーザーがWebサイトへログイン状態である事を利用し、ユーザー自身が意図しない処理が実行されてしまう脆弱性、または攻撃手法のことです。攻撃者が用意したWebサイトなどから、標的のWebサイトへ不正な(偽造した)リクエストを送信してしまうことが特徴的です。

攻撃者が用意した偽造したリクエストを、あたかもWebサイトを利用している本人がサーバーに送信しているように見えてしまうため、Webサイトに登録していたパスワードが勝手に変更されてしまったり、利用していたサービスを退会させられてしまう、非公開にしておきたかった情報を公開されてしまうなどの被害が発生してしまいます。

CSRFの仕組み

ここまでどういった被害が発生するのかをご説明してきましたが、次はどういった仕組み、流れでCSRFの被害を受けてしまうのかを具体的にご説明します。CSRFにはセッションも深く関わってくるため、セッションについても理解しましょう。

セッションとは

CSRFの仕組みを理解する上で、リクエストと同様に大切になってくるのがセッションに対する理解です。セッションとは、ユーザーがログインしてからログアウトするまでの一連の操作や通信のことを指します。

HTTPでの通信はステートレスなため、リクエストを送った相手が誰かをサーバーは毎回意識していません。つまり、ログイン操作を行ったとしても、それだけではサーバーは相手が誰なのかを識別していないのです。この状況を改善し、通信しているユーザーを識別するために、セッションIDをサーバーが発行し、Cookieに保存するようクライアントに依頼します。クライアントは受け取ったセッションIDをCookieに保存し、以降の通信のたびにクライアントからセッションIDを含めたCookieを送ることでサーバーは通信相手が誰なのかを識別することができるようになります。

CSRFの仕組み - 1 Webサイトへのログイン

ユーザーが、悪意のある攻撃者が標的としている仮のWebサイトAサイトへログインします。Aサイトのサーバーは利用者が入力したIDとパスワードが正しいかチェックし、正しければセッションIDを発行し、ログインが成功したレスポンスと共にクライアントへセッションIDを送信します。受け取ったセッションIDをクライアントは自身のブラウザのCookieへ保存します。

CSRFの仕組み - 2 意図していないリクエストの送信

ユーザーはAサイトのセッションIDをCookieに保持した状態で、攻撃者が用意した罠サイトへのリンクを含んだなりすましメールなどから、罠サイトへアクセスしてしまいます。

アクセスした罠サイトには、ユーザーが意図していない不正なリクエストをAサイトへ送信する仕掛けがリンクやボタンなどに配置されており、それらをユーザーがクリックしてしまう、またはスクリプトを実行してしまうことで、Aサイトへユーザーの意図していない不正なリクエストが送信されてしまいます。(リンクやボタンをクリックせずに不正なリクエストを送信する方法として、見えないフォームを用意して勝手にリクエストが送信されるようにする、といった方法も存在します。)

CSRFの仕組み - 3 意図していないリクエストの受理

Aサイトは、罠サイトから送られてきたセッションIDと不正なリクエストを確認します。送られてきたセッションIDはログインしていたユーザーのものであるため、Aサイトはユーザーから送られてきた正規のリクエストであると判断します。

結果、Aサイトはリクエストを受理してしまい、ユーザーの意図していない不正なリクエスト（偽造された投稿、不正送金、強制退会処理など）が実行されてしまいます。

CSRFへの対策

CSRFを防ぐためには、サービスを利用するユーザー側の対策と、サービスを提供する側の対策が存在します。

ユーザー側のCSRF対策

身に覚えのない送金や情報発信があった場合にはすぐに運営へ連絡する

身に覚えのない送金や情報発信などは、すぐに自分で気づくことが正直難しいでしょう。身に覚えのない送金であれば、利用しているクレジットカードの請求が来てからしか気付くことはできず、不正な投稿であればフォロワーなどの第三者から指摘を受けるまで気付かないといったケースがほとんどです。

ただ、即座に対応できなかったとしても、身に覚えのない内容であれば、諦めることはせずに利用するサービスの運営へすぐに連絡して対応を相談することで、被害を防ぐように取り組むことはとても大切です。
Webサービスの利用後のログアウト

私たちは普段たくさんのサービスを利用してますが、ログインを必要とするサービスを利用する場合には、利用を終えた時点でログアウトをしましょう。CSRFでは多くの場合、ログイン状態を狙って攻撃されてしまうため、ログアウトすることでCSRFの被害の多くを避けることができます。

サービス提供者側のCSRF対策

処理を実行する直前でパスワードを再確認する

一つは、クライアントからサーバーへ投稿や変更処理など何かの状態を更新するリクエストが送信された場合に、パスワードの入力を求める方法です。

CSRFでは偽造されたリクエストがサーバーへ送信され、そのままリクエストが実行されてしまうことで被害が発生してしまいます。この偽造されたリクエストをサーバーが受け取った時点でユーザー本人しか知らないパスワードの入力を求める、というワンクッションを置くことで、偽造されたリクエストをそのまま実行してしまうという事態を防ぐことができるようになります。
トークンを利用したリクエストのチェック

トークンを、入力フォームなどを表示する時にサーバーがセッションIDとは別に生成し、表示した入力フォームのhiddenパラメータで保持しておきます。

hiddenパラメータとは、HTMLのinputタグで使用する属性のことで、これを使用することでデータを画面には表示せずに保持しておくことができます。

ユーザー側がリクエストを送信する際に、送信する内容とセッションID、トークンをサーバーへ送信するようにします。サーバーでは送られてきたユーザーのセッションIDと共に自身が生成したトークンの内容を確認し、セッションIDと受け取ったトークンが保持していた内容と一致すればリクエストの処理を実行します。

送られてきたトークンの値が、サーバーが生成した値と異なる場合や空の場合にはエラーとして処理を実行しないようにすれば、CSRFの被害を防ぐことができます。
HTTPリクエストヘッダーのRefererの確認

HTTPリクエストを送信する際、ヘッダーに含まれる内容の一つにRefererという項目があります。このRefererには、どのURLからリクエストが来たかの情報が書かれています。

データの投稿や変更処理などのリクエストをサーバーが受け取った際に、Refererを確認して正しい遷移元かどうかを判断し、正しい遷移元だった場合にのみリクエストの処理を実行するようにすれば、攻撃者が用意した罠サイトからの攻撃を防ぐことができます。
CAPTCHA(画像認証)の利用

CAPTCHAとは、フォームなどの内容を送信する際に、表示させているランダムな文字列をユーザーに入力させ、ボットからの投稿などを防ぐように設計された機能です。表示させている文字列はボットに識別させないよう歪みなどの工夫がされています。CAPTHAが利用される場面として、Webシステムのアカウント作成する時が挙げられます。

この機能を利用することで、ユーザー自身が直接入力しないといけない場面を作り出し、ボットなどを通じて自動的に意図しない投稿をされてしまうことを防ぐことができます。

CSRFの対策としての有効性は高くないかも知れませんが、最低限の効果は発揮できるでしょう。
ライブラリやツールを常に最新版にしておく

Webサイトなどを開発する際に、ライブラリやフレームワークを使用する場面は必ずあると思います。CSRFの対策としてトークンの生成などを行ってくれるライブラリやフレームワークも存在していますが、脆弱性が発見されることも否定できません。

日頃から使用しているライブラリ、フレームワークの情報にもアンテナを張っておき、脆弱性が発見された場合にはすみやかにアップデートを実施するといったことも重要になってきます。