Account Takeover
認証の問題
アカウントのメールアドレスを変更しようとし、確認プロセスを検証する必要があります。もし脆弱であることがわかれば、メールアドレスを意図した被害者のものに変更してから確認してください。
Unicode正規化の問題
意図した被害者のアカウント
victim@gmail.comUnicodeを使用してアカウントを作成する 例:
vićtim@gmail.com
詳細については、Unicode正規化に関するドキュメントを参照してください：
リセットトークンの再利用
対象システムがリセットリンクの再利用を許可する場合、gau、wayback、またはscan.ioなどのツールを使用してさらにリセットリンクを見つける努力を行う必要があります。
アカウント乗っ取りの前処理
被害者のメールアドレスを使用してプラットフォームにサインアップし、パスワードを設定します（被害者のメールにアクセスできない場合は不可能かもしれませんが、確認の試みを行う必要があります）。
被害者がOAuthを使用してサインアップし、アカウントを確認するまで待ちます。
通常のサインアップが確認されることを期待し、被害者のアカウントにアクセスできるようにします。
CORSミス構成によるアカウント乗っ取り
ページにCORSミス構成が含まれている場合、ユーザーから機密情報を盗み出してアカウントを乗っ取るか、同じ目的で認証情報を変更させる可能性があります：
pageCORS - Misconfigurations & BypassCsrfによるアカウント乗っ取り
ページがCSRFに対して脆弱である場合、ユーザーにパスワードの変更、メールの変更、または認証情報の変更を行わせることができるかもしれません：
pageCSRF (Cross Site Request Forgery)XSSによるアカウント乗っ取り
アプリケーション内でXSSを見つけると、クッキー、ローカルストレージ、またはWebページから情報を盗み出し、アカウントを乗っ取ることができるかもしれません：
pageXSS (Cross Site Scripting)Same Origin + Cookies
限られたXSSまたはサブドメインの乗っ取りを見つけた場合、クッキーを操作して（例：固定化）、被害者のアカウントを侵害しようとすることができます：
pageCookies Hackingパスワードリセットメカニズムへの攻撃
pageReset/Forgotten Password Bypassレスポンスの操作
認証応答が単純なブール値に縮小できる場合は、falseをtrueに変更してアクセスできるかどうかを確認してください。
OAuthによるアカウント乗っ取り
pageOAuth to Account takeoverホストヘッダーインジェクション
パスワードリセットリクエストの開始に続いてホストヘッダーが変更されます。
X-Forwarded-Forプロキシヘッダーがattacker.comに変更されます。ホスト、リファラー、およびオリジンヘッダーが同時に
attacker.comに変更されます。パスワードリセットを開始し、メールの再送を選択した後、上記の3つの方法がすべて使用されます。
レスポンスの操作
コードの操作：ステータスコードが
200 OKに変更されます。コードと本文の操作：
ステータスコードが
200 OKに変更されます。応答本文が
{"success":true}または空のオブジェクト{}に変更されます。
これらの操作技術は、データの送受信にJSONが使用されているシナリオで効果的です。
現在のセッションのメールアドレスを変更
このレポートから：
攻撃者は新しいメールアドレスにメールアドレスを変更するようリクエストします。
攻撃者はメールアドレスの変更を確認するリンクを受け取ります。
攻撃者は被害者にリンクを送信してクリックさせます。
被害者のメールアドレスが攻撃者が指定したものに変更されます。
攻撃者はパスワードを回復し、アカウントを乗っ取ることができます
これはこのレポートでも起こりました。
参考文献
Last updated