Coders Conquer Security: Serie Share & Learn: Insecure Direct Object Reference

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

En este post, aprenderemos:

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

Entender el IDOR

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta 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, hace referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando no existe el control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Se trata de un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos que un atacante cambia el ID de la URL a 12344. En una aplicación que sea vulnerable al IDOR, el atacante podría ver los datos relacionados con 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 los registros de las aplicaciones en varios lugares. Una violación de esta magnitud puede ser importante, especialmente cuando se trata de datos confidenciales o de identificación personal.

La Oficina de Impuestos de Australia configurar un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, 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 comercial australiano (ABN). Da la casualidad de que este es un número fácilmente reconocible para cualquier empresa registrada. Este usuario decidió poner los números de otras empresas en la URL. ¡Le regalaron la información de su cuenta bancaria y sus datos personales!

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

Verás, AT&T creó un servicio para admitir la conectividad 3G para iPads. El iPad envió un identificador almacenado en la tarjeta SIM al servicio de AT&T. Luego, el servicio devolvió la dirección de correo electrónico del usuario.

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

Otro error fue que el servicio de AT&T intentó «proteger» el servicio devolviendo la dirección de correo electrónico solo si la solicitud es encabezado de agente de usuario indicó que provenía de un iPad. El agente de usuario es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades del IDOR pueden ser sutiles y disimuladas. Hablemos de cómo derrotarlos.

Derrotar a IDOR

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

El uso de módulos de autorización centralizados es la mejor manera de hacerlo. Herramientas como Seguridad de primavera proporcionan autenticación y autorización sólidas y personalizables para las aplicaciones.

En pocas palabras: tenga un módulo en el que se basen todos los demás códigos para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores de registro de la base de datos reales 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 acceder a un registro con solo adivinar el siguiente identificador válido.

Y, por último, no confíe en nada que el usuario pueda manipular para proporcionar la autorización. AT&T intentó usar el encabezado usuario-agente para autorizar su servicio. No confíes en los encabezados HTTP, las cookies ni los parámetros GET y POST.

Con estas mitigaciones implementadas, el 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 dejes que se te acerquen sigilosamente cuando menos lo esperes. Comprueba siempre que los usuarios estén autorizados. No utilice identificadores de bases de datos reales. No dependa de los datos controlados por el usuario para obtener la autorización.

Desarrolla tu maestría consultando nuestra Recursos de aprendizaje. Si practicas cómo mitigar las vulnerabilidades del IDOR en el lenguaje que elijas, no tendrás problemas para encontrar y solucionar este problema en tus bases de código de producción. También puedes poner a prueba tus 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 ver la galería de otras amenazas de los delincuentes, visita Blog de Secure Code Warrior.

¿Estás listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate a ti mismo de forma gratuita: [Empieza aquí]