CSRFは、利用者のブラウザから、本人が望まない操作の要求をサイトへ送らせる攻撃です。ログイン中の状態が悪用される場合があり、攻撃者がパスワードを知らなくても成立することがあります。
「本人としてログインできている」と「本人がその変更を頼んだ」は、同じではありません。この違いが、CSRFを理解する入口になります。
CSRFとはログイン中の権限を悪用する仕組み
CSRFは「クロスサイト・リクエスト・フォージェリ」の略で、シーエスアールエフと読みます。リクエストは、ブラウザからサイトへ送る要求です。ページを見せてほしいという要求も、設定を変更してほしいという要求もあります。
サイトにログインすると、次のページへ進んでもログイン状態が続くことがあります。Cookieを使う仕組みでは、ブラウザが、送信先や設定などの条件に合う通信へCookieを付けます。サイト側は、その情報を使って利用者を識別します。
便利な働きですが、別のページをきっかけに送られた通信にも、条件によってはそのCookieが付きます。攻撃者は、この性質とサイト側の確認不足を組み合わせて悪用します。
自分では頼んでいない変更が送られる
仮に、あるサービスへログインしたまま、攻撃者が仕掛けたページを開いたとします。そのページをきっかけに、元のサービスへ「設定を変更する」という要求が送られる場合があります。
元のサービスが、ログイン済みという情報だけを見て処理を通すと、利用者が本来の設定画面で選んでいない変更まで受け付けてしまうことがあります。
利用者のブラウザに、ログイン状態が残っている
仕掛けをきっかけに、意図しない変更が送られる
本人の操作かを確かめず、対象サイトが処理してしまう
Cookieが送られる条件と、サイト側の確認不足がある場合の例です。別のページを開けば必ず起きるわけではありません。
これは典型的な仕組みを示す仮の例です。別ページを開くだけで、どのサービスでも勝手に変更されるわけではありません。Cookieが送られる条件や、サイト側の対策などによって、攻撃が成立するかは変わります。
IPAのCSRF解説は、利用者の意図した要求かを区別する仕組みがない場合に、外部経由の悪意ある要求を受け入れる問題を説明しています。起こり得る被害には、不正な設定変更や投稿、本人が望まない処理などがあります。
パスワードやCookieを盗むことが必須ではない
CSRFでは、攻撃者が利用者のパスワードを解読したり、Cookieの中身を盗んだりすることが、必ずしも必要ではありません。利用者自身のブラウザに要求を送らせるからです。
また、CSRFだけで、返ってきたページの内容を攻撃者が自由に読めるとは限りません。典型的には「本人として操作を送らせる」ことが問題になります。ほかの不備と組み合わさる場合まで、同じものとして扱わないようにします。
CSRFとXSSはどこが違う？
XSSは、Webページに混ざった不正なスクリプトが、閲覧者のブラウザで動く攻撃です。CSRFでは、本人が望んでいない要求を、ブラウザから対象サイトへ送らせます。
| 比べる点 | XSS | CSRF |
|---|---|---|
| 中心となる問題 | 表示する内容に、実行される処理が混ざる | ログイン済みでも、要求が正当か確かめられていない |
| 何をさせるか | 対象ページの処理として、不正なスクリプトを動かす | 対象サイトへ、意図しない操作の要求を送る |
| 対策の主眼 | 外部の内容を、安全に表示・処理する | 変更の要求が、認められた経路や手順から来たか確認する |
「XSSは情報を盗み、CSRFは変更する」とだけ分けるのも不十分です。XSSでも操作を送れる場合があり、結果に重なる部分があるからです。何を悪用して、その結果へ至るのかで区別します。
どちらも、利用者がリンクに注意すればサイト側の修正は不要、という問題ではありません。サイトの作りに合わせた対策が必要です。
CSRF対策で操作の正当性を確認する
MDNのCSRF対策では、CSRFトークンなどの方法により、状態を変更する要求を保護する考え方が説明されています。
CSRFトークンは、サイトが用意して検証する、第三者に予測されにくい値です。画面などへ渡した値が操作の要求とともに返るようにし、サーバー側で正しさを確かめます。利用者が毎回覚えて入力するパスワードとは異なります。
外部のページから変更の要求を送れても、攻撃者が必要な値を用意できなければ、処理を通さない。そのための確認材料です。
確認画面があるだけで、対策になる？
「本当に変更しますか」という画面を一枚追加しただけでは、十分とは限りません。画面を飛ばして送られた要求も、サーバー側で拒否できる必要があります。
同じように、通信の送り方をPOSTという形式へ変えただけで、CSRFがなくなるわけではありません。外部のページからも送れる要求があるため、トークンなどの検証を合わせて行います。
ログインは「誰として利用しているか」の確認です。それに加えて「この変更を受け付けてよいか」を確かめる、と捉えると役割が分かれます。
Cookieの設定や重要操作の再確認も組み合わせる
Cookieには、別のサイトをきっかけにした通信へ付けるかを制限するSameSiteという設定があります。CSRFを防ぐ助けになりますが、サービスの構成や通信の条件が関わるため、これだけですべての対策を済ませるとは限りません。
大切な変更を行う前に、改めて本人確認を求める方法もあります。ただし、見知らぬ画面が突然「安全のため」と入力を求めてきたら、従う前に公式の操作画面かを確かめます。確認のための案内を装う別の攻撃も考えられるからです。
利用者ができることと、運営側に必要なことを分けると、次のようになります。
| 立場 | できること・必要なこと |
|---|---|
| サイトを作る・運用する側 | 変更を受け付ける箇所で、トークンや通信の情報を適切に検証し、必要なCookie設定を行う |
| サービスを使う側 | 不審な誘導で操作せず、身に覚えのない変更は公式窓口で確認する。重要な利用を終えたら、必要に応じてログアウトする |
ログアウトは、ログイン状態を利用する攻撃の機会を減らす助けにはなります。ただし、利用中のCSRFを修正する手段ではありません。タブを閉じることとログアウトすることも同じではないため、サービスの操作に沿って行います。
CSRFを知ると、ログイン済みなのに重要な変更で再確認される理由が見えてきます。あなたとして届いた要求かに加え、その要求を受け付けてよいかを確かめている。その二段階が、意図しない操作を防ぐために必要なのです。
