shikata ga nai

Private? There is no such things.

Accidental Observation to Critical IDORを訳してみた

Hello there, ('ω')ノ

 

重要なIDORへの偶発的な観察を。

 

脆弱性:

 IDOR

 

記事:

 https://infosecwriteups.com/accidental-observation-to-critical-idor-d4d910a855bf

 

安全でない直接オブジェクト参照は、OWASP TOP 10(2017 Edition)による。

壊れたアクセス制御のカテゴリに分類されて。

 

f:id:ThisIsOne:20211017081511p:plain

 

この問題は通常、識別子またはオブジェクトを特定のアセットにリンクする。

アプリケーションのアクセス制御ロジックの実装が弱いために発生して。

たとえば、user_idパラメータはどのユーザのデータを更新するかを定義して。

IDORはサーバ側の問題と比較され、広く観察されており、簡単に識別できて。

ただし、多くの場合、IDORは扱いにくい場合があって。

非常に堅牢に見えるアプリケーションにもIDORが含まれている場合があって。

 

今回は、興味深いIDORの脆弱性に遭遇したことについて説明することに。

古いターゲットの子会社、たとえばtargetsub.comで問題を探し始めますことに。

3~4か月後にアカウントにログインすると。

数か月ごとにパスワードをローテーションすることがポリシーなので。

パスワードを変更するように求められて。

パスワード変更ページでは、URLは次のようになって。

 

 https://www.targetsub.com/change-password/?id=90

 

?id=のパラメーターを見て、値を変更しようとしたものの成功せず。

その後、通常のフローでパスワードを変更した後にアプリケーションにログインして。

パスワードの変更ページに戻るとURLは次のようになって。

 

 https://www.targetsub.com/change-password/

 

今回は、?id=のパラメータが存在せず。

さて、同じエンドポイントを持つアプリケーションが。

2つの異なるフローを使用するのは少し奇妙で。

次に、アカウントページに移動すると、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, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain