Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
Este artículo presenta un análisis empírico a gran escala de 107 informes de recompensas por errores clasificados, que revela que la BOLA a nivel de acción es una familia de vulnerabilidades dominante pero subrepresentada y demuestra que la dependencia de las etiquetas de la plataforma exagera significativamente la prevalencia de la autorización de nivel de objeto rota.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que estás caminando por un complejo de apartamentos masivo y de alta tecnología. Tienes una tarjeta de acceso que te permite entrar al edificio (autenticación), pero la verdadera seguridad debería consistir en verificar a qué apartamento específico tienes permiso para entrar.
La Autorización de Objeto Roto (BOLA, por sus siglas en inglés) es lo que ocurre cuando el guardia de seguridad del edificio olvida verificar tu tarjeta de acceso contra el número de apartamento específico que intentas abrir. Podrías ser un residente válido, pero intentas abrir el apartamento 402, y el guardia simplemente dice: "Claro, adelante", sin verificar si el 402 te pertenece.
Este documento es una investigación masiva de 107 informes reales de seguridad de un programa de recompensas por errores (donde los hackers reciben pagos por encontrar estas vulnerabilidades). Los investigadores querían ir más allá del consejo de seguridad "teórico" y observar lo que realmente está sucediendo en el mundo real.
Aquí está el desglose de sus hallazgos, utilizando analogías simples:
1. El problema del "ruido en las etiquetas" (Las falsas alarmas)
Los investigadores comenzaron revisando 200 informes etiquetados como "IDOR" (un nombre común para este tipo de error) en HackerOne.
- El hallazgo: Solo el 42% de esos informes eran realmente lo que parecían.
- La analogía: Imagina un sistema de alarma contra incendios que se activa 200 veces. Los investigadores descubrieron que el 39% de las veces no había un incendio en absoluto; era simplemente alguien quemando tostadas, una ducha con mucho vapor o un sensor defectuoso.
- Conclusión: Solo porque un sistema esté etiquetado como "IDOR" no significa que tenga la vulnerabilidad específica y peligrosa de "Objeto Roto". Los equipos de seguridad a menudo sobreestiman el riesgo porque confían demasiado en las etiquetas.
2. Los dos principales villanos (La taxonomía)
Los investigadores clasificaron los errores reales en seis categorías. Dos de ellas fueron las claras ganadoras, representando casi el 80% de todos los casos:
Villano A: La "Referencia Directa a Objeto" (El truco del directorio telefónico)
- Qué es: Ves una URL como
website.com/factura/101. Cambias el número a102y, de repente, ves la factura de otra persona. - La analogía: Es como caminar hacia una fila de casillas de correo. Sabes que tu casilla es la #101. Intentas la #102, el candado está roto, así que la abres y lees el correo de tu vecino.
- Frecuencia: Esto ocurrió en el 37% de los casos.
- Qué es: Ves una URL como
Villano B: El "Objeto a Nivel de Acción" (El vándalo)
- Qué es: Esta es la gran sorpresa. No se trata solo de leer los datos de otra persona; se trata de cambiarlos o eliminarlos.
- La analogía: Caminas hacia la casilla de correo de tu vecino (a la que no se supone que debas tocar) y, en lugar de solo leer el correo, arrancas la casilla de la pared, borras sus correos electrónicos o transfieres su dinero.
- Frecuencia: Esto ocurrió en el 42% de los casos.
- Por qué importa: La mayoría de las guías de seguridad se centran en "leer" datos. Este documento dice: "Oye, los malos en realidad están destruyendo y modificando datos con más frecuencia de lo que solo están espiando".
3. Los otros villanos sigilosos
El 20% restante de los errores fue más complejo:
- Aislamiento de inquilinos: Estás en un edificio de oficinas compartido. Intentas abrir la puerta a la suite de oficinas de una empresa diferente y el candado falla.
- Contexto de flujo de trabajo: Fuiste despedido de una empresa, pero el sistema aún te permite acceder a los archivos "archivados" de un proyecto en el que solías trabajar porque el sistema olvidó actualizar tu estado.
- Divulgación encadenada: No puedes adivinar el ID, pero encuentras una lista de IDs en otra parte de la aplicación (como un recibo) y usas esa lista para entrar en las cuentas de otras personas.
- Vinculación de objetos: Engañas al sistema para que piense que tú eres el propietario del objeto cambiando un campo oculto en la solicitud (como cambiar el nombre del "Propietario" en un documento).
4. La sorpresa "Vertical" (El viaje en ascensor)
Normalmente, pensamos en estos ataques como "Horizontales" (el Usuario A robando al Usuario B).
- El hallazgo: El 12% de las veces, un usuario normal logró acceder o eliminar cosas que pertenecían a un Administrador.
- La analogía: Un residente normal del complejo de apartamentos logra entrar a la oficina privada del gerente del edificio y borrar las llaves maestras.
- Conclusión: Este es un riesgo enorme que la mayoría de las listas de verificación de seguridad ignoran porque asumen que "los administradores están seguros".
5. Los IDs "mágicos" no funcionan
Los desarrolladores a menudo piensan: "Si no usamos números simples como 1, 2, 3, sino que usamos códigos largos y aleatorios (UUID) o cadenas codificadas, estamos seguros".
- El hallazgo: El 39% de los ataques exitosos utilizaron estos IDs "complejos".
- La analogía: Los malos encontraron una manera de descifrar el "código secreto" en la casilla de correo, se dieron cuenta de que era solo un número oculto y luego simplemente incrementaron el número para llegar a la siguiente casilla.
- Conclusión: Ocultar el ID no soluciona el problema. El servidor aún necesita verificar si eres el propietario del objeto, independientemente de cómo se vea el ID.
6. La brecha de "GraphQL"
El documento encontró que muchas aplicaciones modernas utilizan un sistema llamado GraphQL. Estos sistemas utilizan "IDs globales" (como gid://hackerone/Report/123).
- El hallazgo: Los atacantes descubrieron que si descodificaban estos IDs, revelaban los números secuenciales subyacentes, lo que les permitía adivinar fácilmente el siguiente ID.
- Conclusión: Solo porque un ID parezca una cadena compleja de caracteres no significa que sea aleatorio.
Resumen para la persona común
Este documento nos dice que:
- No confíes en las etiquetas: Solo porque un sistema esté marcado como teniendo un error específico no significa que esté realmente roto de esa manera específica.
- Los malos son destructivos: No solo están robando datos; están eliminándolos y modificándolos con más frecuencia de lo que pensábamos.
- Los códigos secretos no son suficientes: Usar IDs complejos no detiene a los hackers si el servidor no verifica quién posee los datos.
- Los usuarios normales pueden dañar a los administradores: Una cuenta de usuario normal a veces puede romper el acceso a las cosas del "jefe".
El documento concluye que las pruebas de seguridad necesitan cambiar. Necesitamos dejar de verificar solo si puedes leer los datos de otra persona y comenzar a verificar si puedes eliminarlos o cambiarlos, y necesitamos probar si los usuarios normales pueden entrar (accidental o intencionalmente) en las cosas del administrador.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.