utsuroi csrf labs 知識ベース 01 / 02 — Cookie の挙動
Cookies & Cross-Origin Requests · Knowledge Base
01

Cookie とブラウザのリクエスト送信

Why your browser sends authentication cookies even from attacker sites

CSRF を理解するには「ブラウザが Cookie をいつ送るか」のルールを正確に押さえる必要があります。あなたのブラウザはあなたが望まなくてもうつろい EC への Cookie を自動的に送信します。これが CSRF の前提です。

2. Cookie の自動送信ルール #auto-send

送信元のページが何であれ、Cookie はドメインごとに自動添付される。

ブラウザは「リクエスト先のドメイン」を見て、そのドメインに紐付く Cookie を全て自動的に添付します。リクエストを発行した HTML がどこにあったかは関係ありません。

example.com にあるページから shop.utsuroi.example.com へリクエスト
  → shop.utsuroi.example.com の Cookie が自動添付される

evil.example にあるページから shop.utsuroi.example.com へリクエスト
  → shop.utsuroi.example.com の Cookie が 同じく自動添付される
これが CSRF の前提

攻撃者の罠サイト(evil.example)が、被害者のブラウザに対して shop.utsuroi.example.com への HTTP リクエストを発行させると、被害者がうつろい EC にログイン中であれば、その認証 Cookie が自動的に添付されます。サーバは「正規のユーザからのリクエスト」と判断してしまう。

3. Cross-Origin リクエスト #cross-origin

Web では、別ドメインに対してリクエストを送ることができる。

HTML の中には、別オリジンへのリクエストを発行する要素が多数あります:

重要なのは、JavaScript なしでも HTML だけで cross-origin リクエストが発生すること。<img><form> はブラウザが古典的に許可している cross-origin リクエストです。

<form action="https://shop.utsuroi.example.com/account/email" method="POST">
  <input name="email" value="attacker@evil.example">
</form>
<script>document.forms[0].submit();</script>

上の HTML を攻撃者の罠サイトに置けば、訪問者のブラウザは自動的に shop.utsuroi.example.com へ POST します。被害者の認証 Cookie 込みで。

4. Same-Origin Policy の役割と限界 #same-origin-policy

「読めない」けれど「送れない」とは違う。

Same-Origin Policy(SOP)は、ブラウザの基本的なセキュリティ機構。「JavaScript は別オリジンのリソースのレスポンス内容を読めない」というルール。

これは XSS の文脈では「攻撃者サイトの JavaScript からは うつろい EC のページを読めない」と理解されますが、CSRF 文脈では別の側面が重要です:

CSRF と XSS の違い

XSS:被害者サイトの中で攻撃者の JavaScript を実行(被害者サイトのレスポンスを読める)
CSRF:攻撃者サイトから被害者サイトへリクエストを送るだけ(レスポンスは読めなくていい、副作用が起きれば成功)
→ 攻撃者は「なりすましでメール変更」「なりすましで送金」「なりすましで投稿削除」など、サーバ側の状態変更だけが目的。

5. SameSite Cookie 属性 #samesite

2020年以降、Chrome の挙動が変わった。

SameSite は Cookie に付加できる属性で、cross-site リクエスト時の Cookie 送信をブラウザレベルで制御します。

SameSite=Lax の登場で CSRF 攻撃面は縮小

Chrome のデフォルトが SameSite=Lax になったことで、POST フォームによる古典的 CSRF は攻撃が成立しにくくなりました。ただし、(a) 古いブラウザ、(b) サーバ側で SameSite=None を明示しているサイト、(c) GET リクエストで状態変更するアンチパターン、では依然として CSRF が成立します。SameSite に依存せず、Token による根本対策を併用するのが定石です。