ソース：
脆弱性：IDOR
訳：
IDORとは何ですか?
IDOR (間接オブジェクト参照) は、あらゆるアプリケーションで最も一般的な脆弱性の 1 つですが、非常に危険であり、あらゆるビジネスに最も大きな影響を与え。 IDOR は、ユーザー X がユーザー Y であることを適切に検証せずにユーザー Y のデータにアクセスし、ユーザーに代わってアクティビティを実行できるようにする単なる脆弱性で。
脆弱性の概要：
Impact: User Financial + Personal Data Leakage
Target: Undisclosed
Bounty: Undisclosed
Date Reported: 05/12/2022
Severity: Critical
調査結果：
「今すぐ購入、後払い」バナーの下でユーザーにインスタント クレジットを提供します。 この特定のターゲットは、 これは本質的に、電話番号に直接リンクされた固定クレジット限度額を毎月提供することを意味し、さまざまなアプリやストア内での支払いに直接使用でき。
彼らはあなたの財務データから引き出した信用スコアに基づいた、あらゆるカードを必要とせずに。
ユーザーは毎月複数のトランザクションを行う可能性があります。 月末に、 名前、電子メール、電話番号、期日、前回の期日金額、 ベンダーとのその月のすべての取引のリストを含むその月の明細書が提示され。
名前、トランザクション ID、およびそれに対応する支出額、この情報はモバイル アプリケーションと Web アプリケーションの両方に自由に表示されます。
各取引明細書が特定のstatementIdにリンクされている他の銀行と同じように、これらの取引明細書のPDFを生成する興味深い機能があり、これによりその場で取引のPDFが生成され。
これは、この PDF がサーバーに保存されることはなく、ユーザーが要求するたびに常に動的に生成されることを意味し。
POST https://api.redacted.com/api/redacted/statements/downloadStatementPdf/{statementId}
ここで、{ statementId} はさまざまなユーザーのステートメント ID にマップされ、単純なすべて数字の 10 桁の推測可能な数字で。
驚いたことに、この値を 1 ずつ増減すると、その月の別のユーザーの明細が返されることになり。
このエンドポイントでは、現在の認証済みユーザー = ステートメントの所有者ユーザーであることを確認するためのチェックが行われていなくって。
私は今、何百万ものユーザーの財務情報や取引、さらにはトランザクション保管庫にリンクされている個人の機密情報にアクセスできるようになり。
これは、ユーザー ベース全体のデータが侵害されたことを意味し。
その後、対象企業に直ちに報告され、バグ報奨金プログラムに基づいて修正され。
結論：
IDOR は、次のメカニズムのいくつかを使用することで簡単に防止でき。
- 推測不可能な UUID: 特に機密データが存在することが保証されている場所では、推測不可能な UUID を使用してくだ。 これにより、アプリケーションが IDOR に対して脆弱である場合でも、攻撃者が別のユーザーの UUID を推測することはほぼ不可能になり。
- 統合認証: プラグ可能でオプションではない認証を利用し。 これらのリクエストを処理する実際のコントローラにリクエストを直接送信するのではなく、ID を検証してトークン ユーザーにマッピングし直し。
ほなほな。
