CSRF攻撃対策について

Question

前提

CSRF攻撃対策について調べています。

前提として以下を仮定します

• a.com は攻撃者の管理下にあるWebサイト
• b.com は攻撃対象の掲示板Webサイト

攻撃シナリオ

1. 攻撃者が a.com に以下スクリプトを追加する

const formData = new FormData();
formData.append("message", "hello");

await fetch('https://b.com/post', {
  metho: 'post',
  data: formData
})

2 ユーザーがa.comにアクセスする
3. (1)のスクリプトが実行される
4. b.comにhelloが書き込まれる

質問

画像引用元: https://tech.basicinc.jp/articles/231

上記画像について、「攻撃者はトークンを知ることができない」と書いています。
しかし、攻撃シナリオの1を以下の様に変更した場合、トークンを知ることが可能になり、攻撃が成立するのではないでしょうか？

該当のソースコード

// トークンを取得する
const response = await fetch('https://b.com/')
const html = await response.text()
// 正規表現やDOMセレクタを利用してトークンを取得する
const csrfToken = html.getCSRFToken()

const formData = new FormData();
formData.append("message", "hello");
// CSRFトークンを追加する
formData.append("csrfToken ", csrfToken);

await fetch('https://b.com/post', {
  metho: 'post',
  data: formData
})

試したこと

a.com を localhost:80、b.com を localhost:81 としてローカル環境で試してみました。
しかし、Google ChromeではCORSの問題が発生して実際に攻撃は成功しませんでした。
（こちらはまた別問題な気がするので、質問が複雑にならないように今は問題を保留します。）

本来であれば「単純リクエスト」に該当するので、GETでCSRFトークンが取得できてしまうと思います。
https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#%E5%8D%98%E7%B4%94%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88

補足情報（FW/ツールのバージョンなど）

• Google Chrome 121.0.6167.161

Answer 1

Google ChromeではCORSの問題が発生して実際に攻撃は成功しませんでした。
（こちらはまた別問題な気がするので、質問が複雑にならないように今は問題を保留します。）

いえ、それが本題です。CORSでクロスオリジンからの情報取得を禁止することで、無関係な箇所でのトークン取得を防止しています。

Comments

[hupyaginu]

HTMLだけを取得するGETリクエストは単純リクエストの条件を満たしているので単純リクエストに該当すると考えています。

MDNには単純リクエストはCORSのプリフライトが発生しないと書かれていますが、MDNの内容は間違いで、単純リクエストがCORSで拒否されるので攻撃が成立しないという事でしょうか？

それであれば、そもそも今の時代CSRF対策としてのCSRFトークン生成は不要で、CORSだけ適切に設定すれば良いという事でしょうか？

単純リクエストがCORSで拒否されるなら、以下記事の「CSRFが成功してしまう例」の(3)がそもそもプリフライトリクエストで失敗して、POSTリクエストは送信されないので、以下の記事もCSRFが成立しないので「誤り」という事でしょうか？
（実際私も質問時の内容で再現できず失敗しているわけですが。）
https://qiita.com/netebakari/items/41baa7e1d0b8d89f9d12

MDNは信頼できる情報だと考えていましたが、MDNも間違いということでしょうか？

時代の流れとしては以下のような感じでしょうか？
4の時代が来るまで全てのWebサイトがCSRF攻撃に対して脆弱だったのでしょうか？
1. CSRF攻撃という手法が何者かによって発見された
2. Webブラウザ側の対応ができていない（当時はCSRF攻撃対策トークン、CORSがなかった）
3. Webアプリケーション開発者がCSRFトークンを用意して対策した
（しかし、実際は対策したつもりになっていて、実際はXHR(fetch)でトークンを取ることができていた時代がある？）
4. Webブラウザ側でCORSが実装された

[maisumakun]

> 単純リクエストがCORSで拒否されるので攻撃が成立しないという事でしょうか？

違います。クロスオリジンの単純リクエストの場合、リクエストを飛ばすことはできますが、（サーバサイドでAccess-Control-Allow-Originにより許可しない限り）結果をJavaScript から取得できません。

なお、単純リクエストを飛ばすだけなら<img>や<script>のsrcに書き込む、というような手法もありえます。

[maisumakun]

> 時代の流れとしては以下のような感じでしょうか？

これも違います。最初にJavaScriptで行えるようになったXHRでは、そもそもクロスオリジンでの通信機能がなく、それを「セキュリティ上の問題がないように」実現するための仕組みとしてCORSが作られました。

[hupyaginu]

自分でimgやscriptからhtmlが取れるか色々試しましたがやはり無理でした！
他にも、教えていただいたことを確認するように自分で試すことでCSRF攻撃について理解を深めることができました！
ありがとうございます！

[maisumakun]

> そもそも今の時代CSRF対策としてのCSRFトークン生成は不要で、CORSだけ適切に設定すれば良いという事でしょうか？

これも違います。トークンがなかった場合、JavaScriptなしで単にフォームから送信するだけでもCSRFは成立します。

[otn]

なんかこう、JavaScriptを使わないとCSRF攻撃できないと思うって、時代の変化ですかね。
xhrrequestが出来たのより CSRF攻撃のほうが古いはず。

Answer 2

CORSが発生しない ことと プリフライトリクエストが発生しない ことを混同されているように感じます。

GET のような単純リクエストは安全であるはずなので、ブラウザはクロスオリジンであるかどうかを確認せずに（つまりプリフライトリクエストを実行せずに）いきなりサーバーに要求を出します。ただし、返ってきた結果に、適切な Access-Control-Allow-Origin ヘッダー が設定されていなかった場合、ブラウザはスクリプトに結果を読み取ることを許可しません。そのため、攻撃者はトークンを読み取ることはできません。

単純じゃないメソッドの場合、そもそもサーバーがリクエストを処理すること自体を防ぎたい可能性があるので、ブラウザはいきなり正規の要求を投げる代わりに、まずはプリフライトリクエストを投げて Access-Control-Allow-Origin ヘッダー を確認します。ここで適切な Access-Control-Allow-Origin ヘッダー が返ってきた際に初めて正規の要求を出します。

おそらく MDN の記述に間違いはなく、結果を読み取られなければいいだけの単純リクエストと、実行そのものを阻止したい POST などのリクエストで手順が違うということですね。

Comments

[maisumakun]

自分の回答にも補足しましたが、単純リクエストを「投げるだけ」なら、<img src>や<script src>を使う手段が昔から存在します。

Answer 3

基本的にはすでにサーバーBにログイン中で、セッション情報がクッキーに格納されている前提、サーバーBではサーバーA(クロスオリジン)からのリクエストがなぜかピンポイントで許可されてて、クッキーも送れる前提の話かと思います。

以下は

• unix系OSのnode.jsサーバーAを http://localhost:3000/
• unix系OSのnode.jsサーバーBを http://localhost:3001/

で動かす想定の実験コードです。

npm init -y
npm i express
cat >server_a.js <<EOF
const express = require('express')
const app = express()
app.get('/', (req, res) => {
  res.send(\`
<script>
(async ()=>{
    try {
        const formData = new FormData()
        const res = await fetch('http://localhost:3001/buy', {
            method: 'get',
            credentials: 'include',
            data: formData
        })
        console.log(await res.json())
    }
    catch(e) {
        console.log(e)
    }
})()
</script>
\`)
})
app.listen(3000, ()=>{})
EOF
cat >server_b.js <<EOF
const express = require('express')
const app = express()
app.use((req, res, next)=>{
  res.header('Access-Control-Allow-Origin', 'http://localhost:3000')
  res.header('Access-Control-Allow-Credentials', 'true')
  res.cookie('session', 'something_id')
  next()
});
app.get('/', (req, res) => {
  res.send('商品 ¥500<form action="/buy"><input name="csrf" type="hidden" value="something_token"><input type="submit" value="購入する"></form>');
})
app.get('/buy', (req, res) => {
  res.json({message: (req.query.csrf == 'something_token') ? 'お買い上げありがとうございました' : '攻撃してませんか？'});
})
app.listen(3001, ()=>{})
EOF
node server_a.js&
node server_b.js&
wait

ブラウザで http://localhost:3001/ を開いて購入ボタンを押すと、購入できた風のJSONが返ってきます(フォームsubmitでJSON返るのも気持ち悪いですが)。
次に http://localhost:3000/ を開くと行儀悪くいきなりfetchしに行ってくれるので、そこでCSRFトークンみたいな何かで弾かれてるのが分かると思います。

最後に一言忘れてました。既にサーバーBで取得されたトークンはクッキーにないので、サーバーAからは取れないですよね？

あと、Access-Control-Allow-Origin, Access-Control-Allow-Credentialsはとても危険なので原則分からないのにいじらない方がいいです。