Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/idor.md
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +00:00

12 KiB
Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

投稿元 https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489

IDORを見つけるための予想外の場所

エンコードされたIDとハッシュ化されたIDを無視しないでください

エンコードされたIDがある場合、一般的なエンコーディング方式を使用してエンコードされたIDをデコードすることができるかもしれません。

そして、アプリケーションがハッシュ化/ランダム化されたIDを使用している場合、そのIDが予測可能かどうかを確認してください。アプリケーションが不十分なエントロピーを生成するアルゴリズムを使用している場合、慎重な分析の後、実際に予測できるIDが生成されることがあります。この場合、いくつかのアカウントを作成して、これらのIDがどのように作成されるかを分析してみてください。他のユーザーに属するIDを予測することができるパターンを見つけることができるかもしれません。

さらに、他のAPIエンドポイント、アプリケーション内の他の公開ページ（他のユーザーのプロフィールページなど）、またはリファラーを介したURLでランダムまたはハッシュ化されたIDを漏洩させることができるかもしれません。

例えば、私は以前、ハッシュ化された会話IDを介して詳細なダイレクトメッセージを取得することができるAPIエンドポイントを見つけました。リクエストは次のようになります：

GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

最初は問題なさそうです。なぜなら、_conversation_id_は長いランダムな英数字のシーケンスだからです。しかし、後で気づいたのですが、実際にはユーザーIDを使用することで、各ユーザーの会話リストを見つけることができます！

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

これにより、そのユーザーに所属する_conversation_ids_のリストが返されます。そして、_user_id_は各ユーザーのプロフィールページで公開されています。したがって、ユーザーのプロフィールページで彼らの_user_id_を取得し、それに所属する_conversation_ids_のリストを取得し、最後にAPIエンドポイント/api_v1/messagesを介してメッセージを読み込むことで、任意のユーザーのメッセージを読むことができます。

推測できない場合は、作成してみてください

オブジェクト参照IDが予測不能な場合、オブジェクトIDの作成またはリンクプロセスを操作できるかどうかを確認してください。

アプリケーションにIDを提供する

アプリケーション生成のリクエストでIDが使用されていない場合、リクエストに追加してみてください。_id, user_id, message_id_または他のオブジェクト参照パラメータを追加して、アプリケーションの動作に違いがあるかどうかを確認してください。

例えば、このリクエストはすべてのダイレクトメッセージを表示します：

GET /api_v1/messages

これについてはどうですか？別のユーザーのメッセージが表示されますか？

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

HPP（HTTPパラメータ汚染）

HPPの脆弱性（同じパラメータに複数の値を提供する）もIDORにつながる可能性があります。アプリケーションは、ユーザーが同じパラメータに複数の値を送信することを予期していないかもしれません。そのようにすることで、エンドポイントに設定されたアクセス制御を回避することができるかもしれません。

これは珍しいことのように思われますし、私はこれが起こったことを見たことがありませんが、理論的には次のようになります。もし、このリクエストが失敗する場合：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

以下は、ハッキング技術に関する本の内容です。以下の内容は、/hive/hacktricks/pentesting-web/idor.mdというファイルからのものです。

IDOR (Insecure Direct Object Reference)

IDOR（Insecure Direct Object Reference）は、アプリケーションのセキュリティ上の脆弱性の一つです。この脆弱性は、アプリケーションが直接オブジェクトへの参照を許可している場合に発生します。攻撃者は、他のユーザーのデータにアクセスしたり、機能を悪用したりすることができます。

IDORの検出方法

IDORを検出するためには、以下の手法を使用することができます。

  1. ユーザーのアカウントやデータに関連するIDを特定します。
  2. ユーザーのIDを変更して、他のユーザーのデータにアクセスできるかどうかを確認します。
  3. リクエストパラメータやURLのパスにIDを変更して、他のユーザーのデータにアクセスできるかどうかを確認します。

IDORの悪用方法

IDORを悪用することで、以下のような攻撃が可能になります。

  1. 他のユーザーの個人情報や機密データにアクセスする。
  2. 他のユーザーのアカウントを操作したり、権限を昇格させたりする。
  3. アプリケーションの機能を悪用して、不正な操作を行う。

IDORの防止方法

IDORを防止するためには、以下の対策を実施することが重要です。

  1. セッションやアクセス制御を適切に実装する。
  2. ユーザーのデータへの直接参照を避ける。
  3. ユーザーのアクセス権限を適切に管理する。
  4. リクエストのバリデーションやエスケープ処理を行う。

以上がIDORに関する基本的な情報です。この脆弱性を理解し、適切な対策を実施することで、アプリケーションのセキュリティを向上させることができます。

GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

または、これ:

GET /api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID

または、パラメータをリストとして提供します：

GET /api_v1/messages?user_ids[]=YOUR_USER_ID&user_ids[]=ANOTHER_USERS_ID

盲目的IDORs

時にはIDORに対して脆弱なエンドポイントは、直接漏洩情報を返さないことがあります。代わりに、エクスポートファイル、メール、そしてテキストアラートなど、他の場所でアプリケーションが情報を漏洩させる可能性があります。

リクエストメソッドの変更

1つのリクエストメソッドが機能しない場合、代わりに試すことができる多くの他のメソッドがあります。GET、POST、PUT、DELETE、PATCHなど...

よく効く一般的なトリックは、POSTをPUTに置き換えるか、その逆を試すことです。同じアクセス制御が実装されていない可能性があります！

要求されたファイルタイプの変更

時には、要求されたファイルのファイルタイプを切り替えることで、サーバーが認可を異なる方法で処理する可能性があります。例えば、リクエストURLの末尾に.jsonを追加してみて、何が起こるか確認してみてください。

IDORの影響を増やす方法

まずは重要なIDOR

常に重要な機能でのIDORを探してください。書き込みベースのIDORと読み取りベースのIDORの両方が高い影響を持つ可能性があります。

状態を変更する（書き込み）IDORの場合、パスワードリセット、パスワード変更、アカウントの回復などが最もビジネスへの影響が大きい場合があります。（例えば、「メールの購読設定の変更」のIDORと比較して）

読み取り専用（読み取り）IDORの場合、アプリケーション内で機密情報を処理する機能を探してください。例えば、ダイレクトメッセージ、機密ユーザー情報、プライベートコンテンツを処理する機能を探してください。この情報を使用するアプリケーションの機能を考慮し、それに応じたIDORを探してください。

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥