Lab: CSRF vulnerability with no defenses
ログインして、メール変更のリクエスト
POST /my-account/change-email
を、右クリックで、Engagement tool – Genarate CSRF Poc 選択 (pro版)
emailのvalueを少し変更して
Test in browser – copy
内臓ブラウザのURLにはりつけ
submit requestを押すと
メールアドレスが変更されていた
この時点で、CSRF脆弱性あり
今回は、エクスプロイトサーバーを使うとのことなので、
もう一回、Genarate CSRF Pocを開いて、
options include auto-submit scriptにチェックを入れ
Regenerate
このHTMLをエクスプロイトサーバーページのBodyにはりつけ
Deliver exploint to victim
をクリック
クリアしていた
エクスプロイトサーバーっていうのは、
ハッカーのサーバーに、複製したフォームHTMLをアップして、被害者に踏んでもらう（メールでリンクなどを送って）工程を、この作業で短縮しているみたい。
＊サーバー立てることのない人は、最初はピンとこないかも。
CSRFの確認は、ややこしそうだけど、
要は、同じフォームページ作って、そこから変更などの大事なアクションできたらアウトという話。
診断では、重要なアクションページ（フォームがあるからといって全てCSRFチェックするわけでもない）に、csrf-tokenらしいものが渡っているかリクエスト見て、なければCSRF確定だから、検証用のHTML作る流れ。
あっても、毎回、トークンはランダムか、推測できないかなどのチェックは必要だけど。
あと、実際の危険度は、
iframeやxssとの合わせ技だったり、
cookieの防御（httponly/secure付いてるか samesiteはnone以外か CSP使ってる？）などで変わってくる
ブラウザ防御、xss、クリックジャッキングなど関係して、危険性の判定は、多角的に考える項目だと思います。
最後にアクティブスキャン
Tentative(多分)で検出
リファラーがでたらめでも、アクション（変更）が成功しているから？
CSRFは、ツールでは精度低そうなので、手動診断が欠かせないようです。
–)v
コメント