Hello there, ('ω')ノ
CSRFからフルアカウントの乗っ取りを。
脆弱性：
記事：
https://qotoz.medium.com/csrf-to-full-account-takeover-5196cef9d166
今回は、アカウントの乗っ取りにエスカレートできたCSRFの問題に関する記事を。
プライベートサイトをテストしていて、それをtarget.comと呼ぶことに。
サイトを介してフォームを送信すると、CSRF攻撃からの保護として。
`authenticity_token`と呼ばれるパラメータが本文に送信されて。
CSRFトークンに関する一般的な設定ミスは、サーバ側で検証されていないことで。
なので変更するか、リクエストから完全に削除してみると。
CSRFトークンには検証が存在せず、CSRFに対する保護として。
他の手段が使用されておらず。
Content-Typeが、application/x-www-form-urlencodedであるため。
CSRF攻撃としてこれを悪用することを妨げるものは何もなくて。
ただし、CSRF POCを構築するときは。
メール機能を変更するとアカウントの乗っ取りにつながったりとするので。
メール機能の変更：
メール機能の変更に対してCSRFをテストしたところ。
攻撃に失敗する可能性のあるいくつかの問題に気づいて。
１．アカウントにリンクされているメールアドレスを変更するには。
ユーザは現在のパスワードを入力する必要があって。
パラメータ値がサーバ側で検証され、検証されたことを確認するために。
無効なパスワードを試して。
もう１つの試みは、リクエストからパラメータを完全に削除し。
サーバの応答に注目して、どのリクエストが成功したかを推測することで。
２．リクエストヘッダは、CSRf攻撃に対する保護として存在して。
リクエストから削除しようとしましたが、承認され。
メールの変更が有効になったので。アカウントの乗っ取りができて。
CSRF POCを含むHTMLページにアクセスしたユーザのメールアドレスを変更し。
パスワードのリセット機能を使用してパスワードをリセットできて。
さらにパスワード変更機能を見ると、メール変更と同じで。
ユーザは現在のパスワードを入力する必要があり。
リクエストから現在のパスワードパラメータを削除しても成功して。
これで、HTML POCを作成して、悪意のあるページに１回アクセスするだけで。
被害者アカウントの電子メールとパスワードを変更できて。
最後の部分：
パスワードを変更した後、サイトがユーザをログアウトしなかったので。
コードに最後の部分を追加して、ユーザをログアウトし。
アクティブなセッションを終了することに。
HTMLエクスプロイトコード：
https://gist.github.com/qotoz0/bc7f5af1fc16ece558b20283450592f7#file-csrf_to_aot-html
ِ攻撃ワークフロー：
１．被害者のアカウントの電子メールを変更して。
toqotoz+attacker@wearehackerone.com
２．アカウントのパスワードをCsrfattack-00に変更して。
３．ユーザをログアウトして。
影響：
フルアカウントの乗っ取り。
Best regards, (^^ゞ
