Hello there, ('ω')ノ
IDORで最初の報奨金を獲得することについてのすべてを。
脆弱性：
IDOR
記事：
https://infosecwriteups.com/all-about-getting-first-bounty-with-idor-849db2828c8
IDORについて読んで、DVWA、bWAPP、およびPortswiggerAcademyで練習して。
OWASPによると「安全でない直接オブジェクト参照は。
アプリケーションがユーザ指定の入力に基づいてオブジェクトへの。
直接アクセスを提供する場合に発生して。
この脆弱性の結果として、攻撃者は認証をバイパスして。
データベースレコードやファイルなどのシステム内のリソースに。
直接アクセスする可能性があって。
安全でない直接オブジェクト参照を使用すると。
攻撃者は、オブジェクトを直接指すために使用されるパラメータの値を。
変更することで、承認をバイパスしてリソースに直接アクセスできて。
このようなリソースには、他のユーザに属するデータベースエントリや。
システム内のファイルなどがあって。
今回は、プログラムに報告したシナリオのいくつかを共有することに。
同じ役割と権限を持つUser_1、User_2、User_3の３人のユーザを。
Webサイトに作成することに。
シナリオ＃1：
ユーザが投稿を作成して、誰かがその投稿を自分のプロファイルで。
高く評価、コメント、共有できる機能があって。
しかし、この機能を確認していると、他のユーザはコメントで。
その投稿の作成者にしか言及できず。
言及された人は同じ通知を受け取ることに気付いて。
詳細な攻撃シナリオ：
１．User_1が投稿を作成して。
２．User_2がその投稿にコメントすると。
その投稿の作成者（この場合はUser_1）のみに言及できることに気付いて。
３．したがって、コメント（”Please check @[User_1 name]”）リクエストを。
Burpでキャプチャすると、JSONデータは次のように渡されていて。
４．{“text”:”Please check @[User_1 name]”,
”mentions”:[{“uid”:”random 9 digits",”key”:”User_1 name"}],
”message_id”:random 9 digits}
５．上記のJSONデータでは、uidはUser_1のものであり。
User_3のプロファイルにアクセスして。
User_3のプロファイル画像で「要素の検査（inspect element）」を実行することで。
user_3のuidを取得できて。
６．そのため、JSONデータで、両方の値でUser_1 nameをUser_3 nameに変更して。
User_1のuidをUser_3のuidに置き換えて。
７．最後に、その投稿で他のユーザ（User_3）について言及することができて。
言及されたユーザはその通知を受け取って。
シナリオ＃2：
グループに参加するか、グループを作成する機能があって。
グループを作成した後、ユーザは他のユーザと共有できるgroup_codeを取得して。
その参照されたユーザは、グループの所有者の承認なしにグループに追加されて。
詳細な攻撃シナリオ：
１．User_1は「グループの作成」を選択して。
名前を付けてグループに説明を追加した後に。
User_1はグループのrefer_code（ランダムな6ワード（例：pgytsd））を取得して。
２．ここで、User_2は「グループに参加」を選択して。
コードにpgytsdを入力して、このリクエストをキャプチャすることに。
３．すると、「グループに参加」リクエストでは。
JSONデータは次のように渡されていて。
４．{“membership”:{“access_code”:”pgytsd”}}
５．access_codeを変更またはブルートフォースする必要があって。
６．Any usersグループに追加されたaccess_codeを変更すると。
Burp応答で、User_2はそのグループの名前と説明、および。
そのグループの所有者の名前とuidを確認できて。
Best regards, (^^ゞ
