Coders Conquer Security: Serie de aprendizaje y uso compartido: Referencia directa a objetos insegura

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

En este artículo aprenderemos:

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

Comprender IDOR

Una referencia directa a objetos ocurre 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, es posible que notes 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 no existe un control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Es un tipo de ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos 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 pertenecientes a ese registro.

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

Conoce por qué 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 significativa, especialmente cuando hay datos confidenciales o información de identificación personal (PII) involucrados.

La Oficina Australiana de Impuestos creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, venía con la función no deseada de una vulnerabilidad IDOR. Un usuario curioso se dio cuenta de que las URL dentro del sitio contenían su Número de Negocio Australiano (ABN). Resulta que este es un número fácil de descubrir para cualquier empresa registrada. Este usuario decidió introducir los números de otras empresas en la URL. ¡Fue recompensado con sus datos bancarios e información personal!

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

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

Desafortunadamente, estos identificadores eran simplemente números enteros secuenciales y, por lo tanto, fáciles de adivinar. Los atacantes iteraron a través de los identificadores y robaron las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T intentó "asegurar" el servicio devolviendo la dirección de correo electrónico solo si la cabecera user-agent de la solicitud indicaba que provenía de un iPad. El user-agent es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades IDOR pueden ser sutiles y engañosas. Analicemos cómo derrotarlas.

Cómo vencer a IDOR

El control de acceso es la clave para resolver IDOR. Cuando un usuario solicite un registro específico, asegúrese de que esté autorizado para verlo.

Utilizar módulos de autorización centralizados es la mejor forma de lograrlo. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.

En resumen: cuente con un único módulo del que dependa todo el 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 asignen a los registros reales.

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

Por último, no confíe en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó usar la cabecera user-agent para autorizar su servicio. No dependa de cabeceras HTTP, cookies ni parámetros GET y POST.

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

Proteja sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No permita que le sorprendan cuando menos lo espere. Compruebe siempre que los usuarios estén autorizados. No utilice identificadores reales de base de datos. No dependa de datos controlados por el usuario para la autorización.

Domine la materia consultando nuestros Recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades IDOR en el lenguaje de su elección, no tendrá problemas 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 entrena a equipos de ciberseguridad para convertirse en los mejores ciberguerreros. Para obtener más información sobre cómo vencer esta vulnerabilidad y otras amenazas, visite el blog de Secure Code Warrior.

¿Listo para defenderse de los ataques IDOR ahora mismo? Diríjase a la plataforma y acepte el reto de forma gratuita: [Empiece aquí]