Hello there, ('ω')ノ
パスワード変更機能の設定ミスがアカウントの乗っ取りにつながるを。
脆弱性：
IDOR、ロジックの欠陥、パスワードのリセットの欠陥、アカウントの乗っ取り
記事：
パスワード変更機能の設定ミスを使用して。
サイト上のアカウントを乗っ取る方法について説明することに。
今回は、ターゲットをsite.comと呼ぶことに。
テストをしているとサンドボックス環境（sandbox.site.com）で。
パスワードの変更機能に気付いたので。
Burb Suiteを開いてリクエストをインターセプトして。
このリクエストをキャッチして分析をすると。
下記のとおり、下記のリクエストで同じ値を持っていることをみつけて。
ヘッダ（X_auth_credentials）
パラメータ（‘currentPassword ‘）
これで、下記のことがわかって。
・現在のパスワードを変更する場合は、最初に現在のパスワードを入力してから。
新しいパスワードを入力する必要があるわけで。
そこで、下記の調査をはじめることに。
・このヘッダはどうですか？
・サーバはそれを検証しますか？
・削除するとどうなりますか？
・誰かのメールでメールを変更した場合、パスワードは変更されますか？
まず、リクエストで下記を削除してサーバにリクエストを送信すると。
レスポンスはエラーなしで、200 OKが得られたので。
サーバは、このヘッダを検証してないようで。
ヘッダ（X_auth_credentials）
パラメータ（‘currentPassword ‘）
・これで、リクエストに下記が必要ないことがわかって。
ヘッダ（X_auth_credentials）
パラメータ（‘currentPassword ‘）
どのアカウントでも乗っ取れるかを検証することに。
・まずは、別のアカウント（victim@mail.com）を作成して。
被害者の電子メールを電子メール（victim@mail.com）に変更して。
被害者と同じクレデンシャル（パスワード情報）を使用して。
サーバにリクエストを送信すると。
・応答は200 OKだったので、パスワード変更機能が完了したようなので。
・ログインページで変更された被害者の電子メール（victim@mail.com）を入れて。
被害者のアカウントで被害者に作成したクレデンシャル（test@1234）で。
正常にアクセスできて。
攻撃ワークフロー：
１．電子メールを被害者の電子メールに変更して。
２．ヘッダ（X_auth_credentials）とパラメータ（ ‘currentPassword‘）を削除して。
３．新しいパスワードを入力して。
４．リクエストを送信すると、レスポンスとして200 OKが返されて。
５．新しいパスワードを使用して被害者のアカウントにログインすると。
被害者のアカウントに正常にアクセスできて。
影響：
被害者からの介入なしに完全なアカウント乗っ取り。
再現する手順：
１．攻撃者アカウントでログインして。（test1）
Email = attacker@mail.com
Password = attackerpass@1234
２．被害者アカウントでログインして。（test2）
Email = victim@mail.com
Password = victimpass@1234
３．攻撃者アカウントでパスワードの変更機能に移動して。
４．リクエストをインターセプトし、リクエストをRepeterに送信して。
５．リクエストから下記を削除して。
ヘッダ（X_auth_credentials）
パラメータ（‘currentPassword ‘）
６．リクエスト本文で、攻撃者の電子メールを被害者の電子メールに変更して。
７．必要な新しいパスワード（newpass@1234）を入力して。
８．次に、被害者アカウントからログアウトして。
被害者アカウントと新しいパスワード（newpass@1234）でログインすることで。
９．被害者の完全なアカウント乗っ取りが可能になって。
Best regards, (^^ゞ
