hacktricks/pentesting-web/idor.md

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

• ¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!

• Descubre The PEASS Family, nuestra colección exclusiva de NFTs

• Obtén la oficial PEASS & HackTricks swag

• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.

• Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.

Publicación tomada de https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489

Lugares inesperados para buscar IDORs

No ignores los IDs codificados y hasheados

Cuando te enfrentes a un ID codificado, es posible que puedas decodificarlo utilizando esquemas de codificación comunes.

Y si la aplicación está utilizando un ID hasheado/aleatorio, verifica si el ID es predecible. A veces, las aplicaciones utilizan algoritmos que producen entropía insuficiente, y como tal, los IDs pueden ser predichos después de un análisis cuidadoso. En este caso, intenta crear algunas cuentas para analizar cómo se crean estos IDs. Es posible que puedas encontrar un patrón que te permita predecir los IDs pertenecientes a otros usuarios.

Además, es posible que puedas filtrar IDs aleatorios o hasheados a través de otro punto final de API, en otras páginas públicas de la aplicación (página de perfil de otros usuarios, etc.), o en una URL a través del referer.

Por ejemplo, una vez encontré un punto final de API que permite a los usuarios recuperar mensajes directos detallados a través de un ID de conversación hasheado. La solicitud se parece un poco a esto:

GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

Esto parece estar bien a primera vista ya que el conversation_id es una secuencia larga, aleatoria y alfanumérica. Pero más tarde descubrí que en realidad se puede encontrar una lista de conversaciones para cada usuario simplemente usando su ID de usuario.

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

Esto devolvería una lista de conversation_ids pertenecientes a ese usuario. Y el user_id está disponible públicamente en la página de perfil de cada usuario. Por lo tanto, puedes leer los mensajes de cualquier usuario obteniendo primero su user_id en su página de perfil, luego recuperando una lista de conversation_ids pertenecientes a ese usuario, y finalmente cargando los mensajes a través del punto final de la API /api_v1/messages!

Si no puedes adivinarlo, intenta crearlo

Si los IDs de referencia de objeto parecen impredecibles, intenta ver si hay algo que puedas hacer para manipular el proceso de creación o vinculación de estos IDs de objeto.

Ofrece una ID a la aplicación, incluso si no la solicita

Si no se utilizan IDs en la solicitud generada por la aplicación, intenta agregarla a la solicitud. Intenta agregar id, user_id, message_id u otros parámetros de referencia de objeto y ve si hace alguna diferencia en el comportamiento de la aplicación.

Por ejemplo, si esta solicitud muestra todos tus mensajes directos:

GET /api_v1/messages

¿Y este? ¿Mostraría los mensajes de otro usuario en su lugar?

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

HPP (HTTP parameter pollution)

Las vulnerabilidades de HPP (suministro de múltiples valores para el mismo parámetro) también pueden llevar a IDOR. Las aplicaciones pueden no anticipar que el usuario envíe múltiples valores para el mismo parámetro y al hacerlo, es posible que pueda evitar el control de acceso establecido en el punto final.

Aunque esto parece ser raro y nunca lo he visto antes, teóricamente, se vería así. Si esta solicitud falla:

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

Insecure Direct Object Reference (IDOR)

La vulnerabilidad de Insecure Direct Object Reference (IDOR) ocurre cuando una aplicación web permite a un usuario acceder a recursos o funcionalidades que no debería tener acceso. Esto se debe a que la aplicación no valida adecuadamente los identificadores de objeto directo (por ejemplo, un ID de usuario o un número de pedido) antes de permitir el acceso a los recursos correspondientes.

Un ejemplo común de IDOR es cuando una aplicación web permite a un usuario acceder a los detalles de una orden simplemente cambiando el número de orden en la URL. Si la aplicación no valida adecuadamente el número de orden, un usuario malintencionado podría acceder a los detalles de cualquier orden simplemente cambiando el número de orden en la URL.

Para encontrar vulnerabilidades de IDOR, se puede utilizar una técnica llamada "secuenciación de objetos". Esto implica enviar solicitudes repetidas con diferentes valores de identificación de objeto directo para ver si se puede acceder a recursos o funcionalidades que no deberían estar disponibles para el usuario.

Es importante tener en cuenta que las vulnerabilidades de IDOR pueden ser especialmente peligrosas en aplicaciones que manejan información confidencial, como datos de tarjetas de crédito o información médica. Por lo tanto, es importante que los desarrolladores validen adecuadamente los identificadores de objeto directo y limiten el acceso del usuario solo a los recursos y funcionalidades que deberían estar disponibles para ellos.

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

Claro, ¿qué necesitas que traduzca?

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

Lo siguiente es el contenido de un libro de hacking sobre técnicas de hacking de plataformas en la nube, SaaS, CI/CD... El siguiente contenido es del archivo /hive/hacktricks/pentesting-web/idor.md. Traduzca el texto relevante al español y devuelva la traducción manteniendo la sintaxis de markdown. No traduzca cosas como código, nombres de técnicas de hacking, nombres de plataformas en la nube/SaaS (como Workspace, aws, gcp...), la palabra 'leak' y las etiquetas de markdown. Además, no agregue nada aparte de la traducción y la sintaxis de markdown.

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

Blind IDORs

A veces, los endpoints susceptibles a IDOR no responden directamente con la información filtrada. En su lugar, pueden hacer que la aplicación filtre información en otro lugar: en archivos de exportación, correos electrónicos y tal vez incluso alertas de texto.

Cambiar el método de solicitud

Si un método de solicitud no funciona, hay muchos otros que se pueden probar en su lugar: GET, POST, PUT, DELETE, PATCH...

Un truco común que funciona es sustituir POST por PUT o viceversa: ¡es posible que no se hayan implementado los mismos controles de acceso!

Cambiar el tipo de archivo solicitado

A veces, cambiar el tipo de archivo solicitado puede hacer que el servidor procese la autorización de manera diferente. Por ejemplo, intente agregar .json al final de la URL de solicitud y vea qué sucede.

Cómo aumentar el impacto de IDORs

IDOR críticos primero

Siempre busque IDORs en funcionalidades críticas primero. Tanto los IDOR basados en escritura como los basados en lectura pueden tener un alto impacto.

En términos de IDORs que cambian el estado (escritura), los IDORs de restablecimiento de contraseña, cambio de contraseña, recuperación de cuenta a menudo tienen el mayor impacto comercial. (Por ejemplo, en comparación con un IDOR de "cambiar la configuración de suscripción por correo electrónico".)

En cuanto a los IDORs que no cambian el estado (lectura), busque funcionalidades que manejen información sensible en la aplicación. Por ejemplo, busque funcionalidades que manejen mensajes directos, información de usuario sensible y contenido privado. Considere qué funcionalidades en la aplicación utilizan esta información y busque IDORs en consecuencia.