Hello there, ('ω')ノ
重要なIDORへの偶発的な観察を。
脆弱性：
IDOR
記事：
https://infosecwriteups.com/accidental-observation-to-critical-idor-d4d910a855bf
安全でない直接オブジェクト参照は、OWASP TOP 10（2017 Edition）による。
壊れたアクセス制御のカテゴリに分類されて。
この問題は通常、識別子またはオブジェクトを特定のアセットにリンクする。
アプリケーションのアクセス制御ロジックの実装が弱いために発生して。
たとえば、user_idパラメータはどのユーザのデータを更新するかを定義して。
IDORはサーバ側の問題と比較され、広く観察されており、簡単に識別できて。
ただし、多くの場合、IDORは扱いにくい場合があって。
非常に堅牢に見えるアプリケーションにもIDORが含まれている場合があって。
今回は、興味深いIDORの脆弱性に遭遇したことについて説明することに。
古いターゲットの子会社、たとえばtargetsub.comで問題を探し始めますことに。
３～４か月後にアカウントにログインすると。
数か月ごとにパスワードをローテーションすることがポリシーなので。
パスワードを変更するように求められて。
パスワード変更ページでは、URLは次のようになって。
https://www.targetsub.com/change-password/?id=90
?id=のパラメーターを見て、値を変更しようとしたものの成功せず。
その後、通常のフローでパスワードを変更した後にアプリケーションにログインして。
パスワードの変更ページに戻るとURLは次のようになって。
https://www.targetsub.com/change-password/
今回は、?id=のパラメータが存在せず。
さて、同じエンドポイントを持つアプリケーションが。
２つの異なるフローを使用するのは少し奇妙で。
次に、アカウントページに移動すると、URLは次のようになって。
https://www.targetsub.com/myaccount/
さらに、?id=88のパラメータを追加してURLを変更すると。
新しいURLは、次のようになって。
https://www.targetsub.com/myaccount/?id=88
これで、id=88のユーザの詳細にアクセスできて。
この時点で、ユーザのメールアドレスを変更することができて。
さらに、別のアカウントを作成して、そのメールを攻撃者のメールに変更して。
これで、攻撃者が制御する電子メールでパスワードリセットリンクを。
呼び出すことができて、ユーザの操作なしで。
アカウントの完全な乗っ取りを実行できて。
要点：
すべてのエンドポイントで可能なすべてのフローを常に確認するように。
アプリケーションの他の場所で利用できる興味深いフローが。
見つかる場合があって。
ユーザの一意の識別子を参照していない/myaccount、または同様の。
エンドポイントが表示された場合は、uid、id、user_id、oidなどの。
一般的な識別子パラメータを使用するように。
Best regards, (^^ゞ
