Hello there, ('ω')ノ
興味深いアカウント乗っ取りの脆弱性を。
脆弱性：
IDOR
アカウントの乗っ取り
記事：
https://avanishpathak.medium.com/an-interesting-account-takeover-vulnerability-a1fbec0e01a
ログイン機能がバイパスされて、興味深いアカウントの乗っ取りにつながることに。
今回、アプリケーションの任意のユーザ／従業員のアカウントにアクセスできて。
アカウント乗っ取りの脆弱性とは。
攻撃者がアプリケーションに存在する認証の欠陥を悪用することで。
資格情報を必要とせずに被害者のアカウントを。
不正に完全に制御できるようにする脆弱性の一種で。
攻撃シナリオ：
アプリケーションには、OTP機能を備えたログインがあって。
ユーザは、認証フローで登録された電子メールに。
送信された4桁のOTPを入力することでログインできて。
最初に頭に浮かんだのは4桁の短いOTPだったので。
OTPをブルートフォースして、被害者のアカウントにログインを試行すると。
アプリケーションが10回の間違った試行の後に。
HTTP 429 Too Many Requestsの応答を返していることに気付いて。
レート制限メカニズムが設定されていることを意味しており。
応答でOTPが見つけることができず。
これをさらに深く掘り下げて、認証フローを詳しく調べることに。
正しいOTPを入力すると。
/login/signinで発行されたPOSTリクエストは、下記のとおりで。
POSTリクエストは2つのパラメータで構成されていて。
{“ email ”:“usermail@gmail.com”,“code”:<正しい4桁のOTP> }
1つはユーザのメールアドレスで。
OTPはそのメールアドレスに送信されて。
アカウントに正常にログインできるようになっていて。
さっそく、/login/signinリクエストをキャプチャして。
emailパラメータを既存より高い特権のユーザのメールアドレスに変更して。
攻撃者のメールアドレスに送信された正しい4桁のOTPを組み合わせて実行すると。
{“ email ”:“admin@example.com”,“code”:<正しい4桁のOTP> }
アプリケーションの有効なユーザのアカウントにログインできて。
これは、メールとOTPの結合が緩いわけで。
Best regards, (^^ゞ
