Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

• Qué es IDOR y cómo lo utilizan los atacantes
• Por qué el IDOR es peligroso
• Técnicas que pueden solucionar esta vulnerabilidad

Entender IDOR

Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.

¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?

Sepa por qué el IDOR es peligroso

Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.

La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.

Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.

Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.

Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.

Derrotar a IDOR

El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.

La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.

En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.

El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.

Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.

Con estas medidas de mitigación, el IDOR será cosa del pasado.

Asegure sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.

Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]