Foto de portada de IDOR

IDOR: referencia de objeto directo inseguro

Iinseguro Direct Oobjeto Rreferencia o IDOR sucede cuando una aplicación expone inadvertidamente objetos privados a través de la entrada del usuario. Por ejemplo, un sitio web puede permitirle acceder a perfiles de clientes privados ingresando ID de usuario únicos en la URL de esta manera:

https://example.com/account?id=32145

El peligro, por supuesto, es que un atacante pueda crear un bot que repita el número entero para extraer información confidencial. Este vector de ataque es especialmente destacado si el valor de ID es incremental, ya que se garantiza que cada número entero sucesivo es otra cuenta. En definitiva, este es un control de acceso vulnerabilidad, ya que un extraño sin privilegios puede usar la entrada del usuario para obtener acceso a cosas que no debería.

Carga útil Burp Intruder
(Carga útil de Burp Intruder para iterar sobre un parámetro de URL)

Tipos de IDOR

Los ataques de IDOR pueden presentarse de diferentes formas. Por lo general, un humano podría detectar fácilmente estas vulnerabilidades al inspeccionar el tráfico HTTP a través de apoderado, a veces, cuando la vulnerabilidad se transmite en la URL, un simple navegador haría el trabajo.

Una vez que se inspecciona el tráfico HTTP, se debe observar el efecto directo e indirecto de la entrada de un usuario en los objetos devueltos por el servidor. Las entradas de usuario más utilizadas son:

  • Entero incremental: como en el ejemplo anterior, cuando se puede acceder a los recursos a través de un parámetro de entero incremental, que suele ser una clave en una tabla, que se puede iterar fácilmente.
  • Fechas: Del mismo modo, las fechas también se pueden iterar.
  • Cadenas predecibles: archivos que almacenan información confidencial con nombres como “ID-” + nombre de usuario + “.txt”.

Técnicas de Mitigación

En última instancia, mitigar IDOR se reduce a tener un sistema de control de acceso sólido. Por ejemplo, un sitio web puede verificar en qué cuenta ha iniciado sesión un usuario antes de mostrar un perfil, o no permitir que los usuarios que no son administradores descarguen ciertos archivos. De esa forma, incluso si un atacante puede manipular parámetros para revelar objetos no públicos, se rechaza el acceso no autorizado.

Muchos recomiendan usar valores de parámetros difíciles de adivinar para que iterar a través de ellos sea difícil, si no completamente imposible, como UUID o cualquier hash de alta entropía. Si bien es importante hacerlo, esto podría abrir otros vectores de ataque cuando se filtren estos identificadores, como lo que fue descubierto en la aplicación móvil de Uber

Estas identificaciones generalmente se almacenan como "identificación de visualización", que es lo que la aplicación expone al usuario, mientras que internamente el backend aún usa la identificación normal para consultar la base de datos, unir tablas y más.

 Esta hoja de trucos de OWASP, sin embargo, sugiere otra solución: usar hashes salados para ocultar las referencias directas.

Detección de IDOR 

Existen múltiples formas de detectar una vulnerabilidad IDOR, algunas técnicas son mejores que otras. Con el tiempo, aprendemos que las pruebas manuales o híbridas para dicha vulnerabilidad son más precisas que las herramientas automáticas o de fuzzing.

Tradicional pelusa la prueba no está a la altura. Está diseñado para detectar fallas o fallas cuando un programa recibe una entrada mal formada. Pero con IDOR, uno quiere detectar casos en los que la entrada bien formada funciona pero no debería. Para aplicaciones que utilizan Pavonearse para definir sus API, año luz fuzz fue desarrollado.
Existen otras herramientas de detección de tiempo de ejecución automatizadas, pero las hemos visto fallar repetidamente, por lo que no podemos recomendar ninguna en particular.

Lo que encontramos que funciona mejor es hacer que su aplicación se someta a pruebas exhaustivas de penetración a través de una inspección cuidadosa. Un enfoque híbrido como usar Autorizar eructo es lo que usamos en nuestras pruebas de penetración que ayuda al probador.

Es importante probar las vulnerabilidades comunes como IDOR, ya que dejarlas en entornos de producción conduce a graves filtraciones de datos.

Ir al contenido