IDOR in APIs から学ぶ

Bug Bounty API

ソース：

medium.com

脆弱性：API, IDOR

 

訳：

API の IDOR

安全でない直接オブジェクト参照 (IDOR) は、攻撃者が Web アプリケーションの URL またはパラメーターで使用される識別子を操作することによってオブジェクトにアクセスまたは変更できる場合に発生する脆弱性で。
この問題は、ユーザーに特定のデータへのアクセスを許可するかどうかを確認できないアクセス制御チェックが欠落しているために発生して。

API エンドポイントは、次の場合に脆弱になって

  • 機密性の高いオブジェクトのプロパティを、アクセスすべきではないユーザーに公開し。
  • これにより、ユーザーはアクセスできない機密オブジェクトのプロパティの値を変更、追加、または削除できちゃったり。

一般的なセキュリティ問題は、次の場合に発生して。

  • ロールと同様に、アクセス制御権限はクライアントの HTTP リクエストに含まれており、クライアントの制御下にある可能性があって。
  • バックエンドのアクセス制御が不十分 -> ユーザー ロールの割り当て -> 権限の昇格。

インパクト

プライベートまたは機密オブジェクトのプロパティに不正にアクセスすると、次のような重大な結果が生じる可能性があり。

  • データ開示: 機密情報を権限のない者に公開すること。
  • データ損失: 機密データの意図しない削除または操作。
  • データ破損: 重要なデータが不正に変更され、整合性の問題が発生します。
  • 権限昇格: 不正アクセスにより、攻撃者がシステム内でより高いレベルのアクセス権や権限を取得できる可能性があります。
  • アカウントの乗っ取り: 場合によっては、不正アクセスによりユーザー アカウントが部分的または完全に制御され、重大なセキュリティ リスクが生じる可能性があります。

防止

  1. API エンドポイントは、ユーザーがアクセスできるオブジェクトプロパティのみを公開するようにします。
  2. to_json() や to_string() のような汎用メソッドは避けて。 代わりに、返すプロパティを選択して。
  3. クライアント入力の内部オブジェクトまたはプロパティへの自動バインドを回避することで、一括割り当てを防ぎ。
  4. クライアントの更新を、許可されたオブジェクト プロパティのみに制限して。
  5. セキュリティを強化するためにスキーマベースの応答検証を実装し。

サイドノート

  1. API で一般的に使用される HTTP メソッドは次のとおりで。
  • PUT -> アイテムの詳細を更新します。
  • POST -> 新しいアイテムを作成します。
  • DELETE -> 項目を削除します。
  • GET -> アイテムの詳細を取得します。

2. GET リクエストを使用して他のユーザーの詳細を取得して、IDOR 情報漏洩の脆弱性に対して API をテストしてみte。

シナリオ (ラボ): プロファイル更新関数の脆弱な API 呼び出し

脆弱な API の特定

  1. プロフィールの詳細を変更し、「プロフィールを更新」をクリックします。
  2. 更新リクエストをインターセプトします。
  3. /api/profile/1 への PUT リクエストには、uid、uuid、role などの隠しパラメータが含まれます。
  4. ロールが従業員に設定されていることを確認します。

 

では、他にどのような役割が存在するのかをどのようにして知ることができるでしょうか?

搾取

試してみることができることがいくつかあります。

  1. 自分の uid を別のユーザーの uid に変更します。
  2. 別のユーザーの詳細を変更します。
  3. 任意の詳細を使用して新しいユーザーを作成します。
  4. 既存のユーザーを削除します。
  5. ロールをより特権のあるロール (管理者など) に変更します。

ステップ

自分の uid を別のユーザーの uid に変更します。

私たちの (“uid”: 1) を別のユーザーの uid (例: “uid”: 2) に変更します -> uid が一致しません。

 

アプリはリクエストの uid を API エンドポイント (/1) と比較しているようです

別のユーザーの詳細を変更する:

API エンドポイントを /profile/2 に変更し、「uid」: 2 を変更して、以前の uid の不一致 -> uuid の不一致を回避し。

 

アプリは、送信している uuid 値がユーザーの uuid と一致するかどうかをチェックしているようです

POST リクエストを使用して新しいユーザーを作成する

uid を新しい uid (例: “uid”: 20 ) および API エンドポイント (/20) -> 管理者専用アクション に 変更し。

 

 

DELETE リクエストによる既存のユーザーの削除

uid を別の uid (例: “uid”: 20 ) および API エンドポイント (/20) -> 管理者専用アクション に変更して。

 

 

ロールをより特権のあるロール (管理者など) に変更します。

ロールを admin/administrator に変更して、より高い権限を取得します -> ロールが無効で。

 

 

私たちの試みはすべて失敗に終わったようで。

ただし、 他のユーザーの詳細を読み取ることを妨げる確実なアクセス制御 可能性があります がない場合は、 IDOR 情報開示を取得し 、この情報を使用して 関数呼び出しに対する IDOR 攻撃を完了できる 。

(/profile/10) で終わる API エンドポイントに get リクエストを送信します。

管理者の詳細を明らかにする情報漏洩の脆弱性を発見しましたが、これは重大な可能性があって。

 

IDORの情報開示
  1. この情報を使用して管理者の詳細を変更しましょう。

 

2. (/profile/10) で終わる更新された詳細 API エンドポイントに取得リクエストを再度送信します。 

 

 

管理スタッフの詳細が正常に更新されました。

ロール (“role”:”staff_admin”) を使用してアクセス制御権限をバイパスして、新しいユーザーを作成してみましょう。

POSTリクエストを「role」:「staff_admin」として使用して新しいユーザーを作成します

  1. uid を新しい uid (例: “uid”: 20 ) と API エンドポイント (/20) に変更します -> 200 OK!

管理者のみが新しい従業員を作成できるという制限を回避することに成功しました。

2. 新しいユーザーの役割と詳細を更新します。

 

 

3. 新しいユーザー (/profile/20) の更新された詳細を取得するために、API エンドポイントに GET リクエストを送信します。 

 

 

IDOR 情報漏洩と IDOR の安全でない関数呼び出しの脆弱性が連鎖することに成功し、不正なアクションが実行されるようになりました。

 

ほなほな。