Hello there, ('ω')ノ
パブリックレベルドメインでユーザの機密レポートを読むことができた方法を。
脆弱性：
IDOR
記事：
今回は、IDORとBACを連鎖させて、パブリックドメイン上のユーザの。
機密レポートを読み取る方法について。
redacted.comでテストするとき、Webサイトはユーザが自分のレポートを。
読むことができるようにGETリクエストを受け取っていて。
これで、レポート名のパラメータを取って。
このレポート名がユーザプロファイルで自分のものではないレポートに。
変更されたときはいつでも、403応答が満たされて。
404が見つからないため、これを使用して有効なレポート名を収集できて。
セッションIDは複雑すぎて、ブルートフォースや推測ができず。
比較すると、各セッション文字列は完全に異なっていて。
しかし、このWebサイトには、ユーザが既存のレポートを。
新しいレポートに複製できる機能があって。
レポートのクローンを作成するとき、クライアント側で自分が所有する。
レポートにしか見つからず。
レポートをクライアント側を通過してサーバに渡し。
クローンを作成するレポートを定義した非表示のパラメータを改ざんすると。
入力は完全に信頼され、要求元のユーザのIDがレポートへのアクセス許可を。
持っていることをサーバ側がチェックすることはほとんどなくて。
チェックの唯一の形式は、リファラヘッダにあって。
このヘッダは、ユーザが実際に要求したレポートIDから来ていることを保証して。
Burp Suiteで変更することに。
元のクローンを担当するパラメータを別のアカウントのレポートに変更し。
転送すると、クローンは、ユーザレポートから作成されて。
自分のプロファイルに直接追加されて。
また、別の機能が存在し、ユーザは編集または読み取り専用のアクセス許可の。
いずれかで、レポートに別のユーザを追加できて。
ここでレポートIDを改ざんした場合、別の403応答では、直接表示できず。
レポートIDを取得し、それを通過させ、外部ユーザを追加できる機能を。
インターセプトし、レポートを識別するパラメータが存在するため。
ここでレポートIDを変更し、リファラを変更して。
自分が所有していないレポートから来たふりをして。
別のユーザアカウントに外部のアカウントを追加して。
さらには、認証されていないときにユーザがレポートにアップロードした画像を。
直接表示し、これらを削除することもできて。
BACまたはIDORの問題が1つ見つかった場合は。
さらに多くの問題が発生する可能性があって。
Best regards, (^^ゞ
