Hello there, ('ω')ノ
非常に致命的なIDORの話を。
脆弱性：
XSS
IDOR
アカウントの乗っ取り
記事：
https://infosecwriteups.com/idor-that-allowed-me-to-takeover-any-users-account-129e55871d8
ターゲットをtarget.comと呼ぶことに。
基本的に多くの機能を備えたオンラインショッピングサイトで。
フェーズ１：
target.comにはたくさんの機能があるので、アカウントを作成して。
偵察を行わずにいくつかの基本的な脆弱性を見つけ始めることに。
そこで、Burpでリクエストを捕らえ始めたものの。
登録機能やログイン機能に興味深いものは何も見つからず。
ただ、パスワードのリセットやその他の機能は、レート制限攻撃に対して脆弱で。
アカウントを作成するときに、自分の名前を下記のように入力すると。
HTMLインジェクションとXSSを確認して。
<h1>tester</h1>
target.comでアカウントを作成時に、同じことを行ってログインして。
ダッシュボードにアクセスしましたが、残念ながらh1タグは実行されず。
プロファイルセクションで保存されているXSSを探したものの。
どのフィールドも脆弱ではなくて。
次にアドレスブックのセクションで、全フィールドに同じペイロードを入力すると。
今度はそれは名と姓のフィールドで実行できて。
次に、ペイロードを下記のXSSペイロードに変更して。
[変更を保存]をクリックすると、保存されたXSSが正常にトリガされて。
<svg onload = alert(document.cookie)>
次に、保存されているXSSをCSRF攻撃で悪用しようとしましたが機能せず。
フェーズ２：
保存されたXSSをあきらめて、他の脆弱性を探し始めて。
ほとんどすべての脆弱性をテストするものの、何も機能せず。
次に、アドレスブックのセクションに再度アクセスすると。
保存されたXSSが再度トリガされたため。
[アドレスの編集]をクリックしてそのXSSペイロードを削除して。
URLを確認すると下記のとおりで。
https://www.target.com/my/addressbook/30916
他の人のアドレスブックを見たいと思ってその番号を30916から30915に変更すると。
「このアクションを実行することは許可されていません」というメッセージが。
次にアドレスセクションを再度編集して、そのXSSペイロードを削除してから。
今回は、リクエストをインターセプトして。
下記のパラメータを確認して。
今回はIdパラメータを30916から30915に変更して、リクエストを転送すると。
アドレスが正常に変更されたというメッセージが表示されて。
しかし、保存されたXSSが再びトリガされて。
これが何が起こったのかを確認するために。
2番目のアカウントを作成してアドレスIDを取得することに。
最初のアカウントでアドレスセクションを編集して。
XSSペイロードをそのまま維持して変更を保存して。
リクエストを傍受し、IDを最初のアカウントIDから2番目のアカウントIDに変更して。
リクエストを転送すると、今回は機能して。
Idは簡単に推測できて、エンドポイントにレート制限がなかったので。
ユーザのアカウントを簡単に引き継ぐことができて。
自己保存されたXSS⇨IDOR⇨アカウントの乗っ取りの流れとなって。
Best regards, (^^ゞ
