> For the complete documentation index, see [llms.txt](https://chubu.gitbook.io/chubu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chubu.gitbook.io/chubu/vulnerabilidades-en-web-apps/insecure-direct-object-reference-idor.md). # Insecure Direct Object Reference (IDOR) Un **IDOR** ocurre cuando una aplicación permite acceder o modificar un objeto (usuario, archivo, pedido, registro, etc.) simplemente referenciando su identificador (ID) de forma directa, sin verificar que el usuario autenticado tenga realmente permiso para acceder a ese recurso. Es una de las vulnerabilidades **más reportadas** en programas de bug bounty porque suele tener **alto impacto** (información sensible, modificación de datos, escalada de privilegios). **Ejemplo 1: IDOR en Perfil de Usuario (Cambio de Parámetro Simple)** **Escenario Realista:** Muchas aplicaciones móviles o APIs modernas tienen un endpoint para ver/editar el perfil: {% code expandable="true" %} ```http GET /api/v3/user/profile?user_id=87291 ``` {% endcode %} #### Explotacion: * Creas dos cuentas de prueba (tu cuenta y una cuenta “víctima”). * Con tu cuenta, interceptas la request con Burp Suite. * Cambias el parámetro user\_id=87291 por el ID de la otra cuenta. * Observas si puedes ver datos sensibles (email, teléfono, dirección, DNI, historial de pedidos, etc.). #### HTTP Parameter Pollution: {% code expandable="true" %} ```http user_id=MI_ID&user_id=VICTIMA_ID ``` {% endcode %} #### Array Wrapping: {% code expandable="true" %} ```json {"user_id": 87291} → {"user_id": [87291, 1337]} ``` {% endcode %} #### JSON Object Wrapping: {% code expandable="true" %} ```json {"user_id": 87291} → {"user_id": {"value": 1337}} ``` {% endcode %} El impacto común: Robo de información personal, suplantación de identidad, o modificación de datos ajenos. ### **Ejemplo 2: IDOR en Gestión de Órdenes / Documentos (Cambio de Versión de API)** **Escenario:** Una fintech o e-commerce tiene endpoints separados por versión: {% code expandable="true" %} ```http POST /api/v2/orders/confirm ``` {% endcode %} Pero la versión antigua (v1) tiene menos controles de autorización. **Explotación:** 1. Encontras un endpoint que devuelve tu propio pedido: {% code expandable="true" %} ```http GET /api/v2/orders/45678 ``` {% endcode %} Probas bajar de versión: {% code expandable="true" %} ```http GET /api/v1/orders/45678 ← Tu pedido GET /api/v1/orders/99999 ← Pedido de otra persona ``` {% endcode %} #### Otras técnicas útiles: * Agregar .json al final: /api/v2/orders/45678.json * Cambiar método: GET en lugar de POST * Agregar parámetros extras: ?id=99999\&user\_id=99999 **Impacto Potencial:** * Ver pedidos ajenos * Cancelar/modificar órdenes de otros usuarios * Acceder a facturas o datos de pago de terceros #### Metodología para Encontrar IDOR 1. **Mapping** → Identifica todos los endpoints que usan IDs (user\_id, order\_id, file\_id, document\_id, etc.). 2. **Cuentas de Prueba** → Siempre usa mínimo 2-3 cuentas controladas por ti. 3. **Pruebas Sistemáticas**: * Cambiar ID numérico (+1, -1, valores grandes, 0, negativos) * Probar UUIDs si la app los usa * Probar las técnicas del repo (array, object, parameter pollution, .json, versiones antiguas) 4. **Automatización Ligera** → Burp Intruder con cluster bomb o Turbo Intruder #### **IDOR en Perfiles de Usuario / Exposición de Emails (Bugcrowd)** **Programa:** globe.gov (Bugcrowd) **Reporte:** {% embed url="" %} **Explicación del Exploit:** * Endpoint vulnerable: /api/teams/members o similar. * Un usuario autenticado podía modificar el parámetro orgId (o teamId). * Al cambiar el ID de la organización, accedía a emails privados, roles y datos de miembros de **cualquier equipo** al que no pertenecía. **Impacto:** * Exposición masiva de PII (Personally Identifiable Information). * Posible phishing dirigido o ingeniería social. * Severidad: **P3** #### **Ejemplo 2: IDOR en Acceso a Perfiles y PII (Bugcrowd - FCC)** **Programa:** DIRS (FCC - Federal Communications Commission) **Reporte:** {% embed url="" %} **Explicación:** * Endpoint: /users/{userid} (ID numérico predecible). * Un usuario de bajo privilegio podía cambiar el userid en la URL y obtener perfiles completos + datos de empresa de cualquier otro usuario. * **Broken Object Level Authorization (BOLA)** clásico. **Impacto:** Acceso a información sensible de usuarios en entorno de producción gubernamental. Severidad **P1**. #### **Ejemplo 3: IDOR en Reddit - Modificación de Enlaces de Perfil (HackerOne)** **Programa:** Reddit **Reporte:** Reporte: {% embed url="" %} (por criptex) **Explicación del Exploit:** * Un usuario podía modificar el "custom profile link" de **cualquier otro usuario** cambiando el username o ID en la request GraphQL. * Payload ejemplo: {% code expandable="true" %} ```json {"id":"11a239b07f86","variables":{"username":"victima"}} ``` {% endcode %} **Impacto:** * Suplantación parcial de identidad. * Daño a la reputación de usuarios. * Recompensa: **$5,000** **Lección:** GraphQL es un lugar muy común para IDOR actualmente. Prueba manipular variables en queries/mutations. #### **Ejemplo 4: IDOR en Acceso a Resumes Privados (Bugcrowd - Indeed)** **Reporte:** {% embed url="" %} **Explicación:** * URL para descargar PDF de resume público: /resume/{id}/pdf * Cambiando el {id} se podía descargar resumes marcados como **privados**. * Solo hacía falta enumerar IDs de resumes. **Impacto:** * Exposición de CVs privados con datos personales y laborales. **Lección:** Agregar /pdf/ o cambiar extensiones/métodos es una técnica clásica para bypass. #### **Ejemplo 5: IDOR en HackerOne (Meta)** **Reporte:** {% embed url="" %} **Explicación:** * Request a /bugs.json permitía acceder a reportes privados cambiando el ID del reporte.