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
コメント