CSRF対策についての疑問

Question

例としてPHPのフレームワークになりますが、CSRF対策として
入力フォームのViewのhiddenにトークンを埋め込んでおくような対策方法があるかと思います。

疑問なのですが、攻撃スクリプトがPOSTする前にいったん入力フォームにリクエストを行ってレスポンスからトークンを取得。
またその際にクッキーからセッションIDを取得。その後、リクエストヘッダに取得したセッションIDを埋め込んでトークンをPOSTした場合、
攻撃が可能な気がするのですが、どうなんでしょうか。

Answer 1

ご指摘の攻撃を行う場合、クッキーを被害者のブラウザにセットするという行為が必要になります。それは特定の環境では可能です。代表的なものとしては下記があります。

• クッキーモンスターバグを使う（地域型JPドメイン名や都道府県型JPドメイン名を使っいるサイトで、かつ被害者がIEユーザの場合のみ）
• HTTPS接続された環境で、通信経路上の攻撃者がHTTP通信でクッキーをセットする（参考情報）

以上のようにして攻撃はできるのですが、その場合ログインユーザーはあくまで攻撃者のものであり、被害者のアカウントではありません。
なので、被害者のアカウントを悪用するという意味での攻撃はできません。
一方、ログインは不要であるケースや、「なりすまし犯行予告」のように、投稿者のIPアドレスが問題になるようなケースでは一定の攻撃価値があると思います。

結論として、特定の状況・環境では、ご懸念のような問題はありえます。

Comments

[redara]

回答ありがとうございます。
質問の趣旨として、ここまで高度な回答をいただくレベルの質問ではなかったのですがｗ
リンク先のクッキー改変の手法など勉強になり、対策しておきたいと思います。

Answer 2

クッキーやトークンを能動的に盗むような攻撃は、CSRFとは別物ですので、それはそれで対策が必要になります（HTTPS化で盗聴を防ぐ、クッキーにHttpOnlyやSecureを付けることで流出経路を減らす、重要な情報の変更に際してはパスワードを入力させることで、ページ内のトークンのみに頼らずに認証するなど）。

CSRFは、あくまで「ユーザーのログイン状態だけで認証する」というのを利用した攻撃です。

Comments

[redara]

『あくまで「ユーザーのログイン状態だけで認証する」というのを利用した攻撃』に対する対策という点で釈然としました。ログイン認証のブルートフォースアタック対策などにも代用できるのかと考えたのですが、そういう用途では全く使えないということなんですね

Answer 3

クロスサイトリクエストフォージェリ（CSRF）の概要は以下のとおりです。

Webアプリケーションが、本来拒否すべき他サイトからのリクエストを受信し処理してしまいます。

つまり、自サイトを正当（？）にトレースし、エミュレートしたものを排除する機構ではありません。

これを排除するには他の手段が必要となります。

これらの手段は、一般的にセキュリティポリシーと密に関わるため、対策の実装内容が開示されるケースは稀です。

Comments

[redara]

「自サイトを正当（？）にトレースし、エミュレートしたものを排除する機構ではありません。」
この部分の認識がありませんでした。別途対応したいと思います。