個人的CSRFを見つけるためのtips

CSRFは他の脆弱性に比べて対策が容易にできる。そのためCSRFを見つけるのも割と簡単である。
脆弱性があるかどうかは、CSRF対策がなされているかを確認すればいい。(基本的には)
CSRF対策がなければ脆弱という判断ができるので、判断するためにCSRFの対策方法を知る必要がある。

CSRFの対策方法

CSRFの対策の目的は、webアプリが正規のユーザによる捏造されていないHTTPリクエストのみ受付ける仕組みを提供すること。
具体的な対策方法には、
1. ワンタイムトークン(CSRFトークン)の利用
2. リクエスト送信前にパスワードを入力させる
3. Refererヘッダーの検証

などがある。 一番ワンタイムトークンの利用が一般的だと思われる。
他の記事や書籍で丁寧に解説されているものを見ていたただければ対策の詳細がわかるので気になる方はそちらをどうぞ。

基本的なCSRFの見つけ方

具体的にCSRFを見つけるための手順をご紹介。

1.CSRFが起こりうるフォームを特定する

webアプリを探索して重要な処理を行っているフォームを確認する。チェックする場所としては、 ログインフォーム、ログアウトフォーム、パスワード変更フォーム、決済フォームなど。
他者に実行されたら困るようなフォームを探せばいい。

2.CSRF対策がされているかを確認する

まずはCSRFトークンがあるか、リクエスト送信前にパスワードを入力する画面があるかを確認する。

tipsの紹介

• CSRFトークンを消してリクエストを送信してみる。
  CSRFトークンがあるだけ処理されてないことがあるかもしれないので確認してみる。
• CSRFトークンの値を変更してリクエストを送信してみる。
  CSRFトークンの検証の実装が不適切な可能性があるため確認してみる。
• CSRF対策はないが、bodyにjsonを利用したリクエストがある場合
  ぶっちゃけ記事ここだけでよかった気がしてる。 重要な処理を行うリクエストにjsonを使うとContent-Typeヘッダーにapplication/jsonを指定する必要があるため、Same Origin Policyによって異なるオリジンからのリクエストが拒否される。
  そのため"原理上は"CSRFができない。
  しかし、
  Content-Typeがapplication/jsonでなくてもbodyがjson形式であれば,サーバ側のフレームワークが自動でjsonにパースしてくれることがよくある.
  Content-typeをシンプルリクエストに沿ってContent-Typeをtext/plain, application/x-www-form-urlencoded, multipart-/form-dataのいずれかに変更したリクエストを送れば、Same Origin PolicyをバイパスしてCSRFができる。