Ciberprotección en Infraestructuras Críticas y OT
Cuando un parche puede parar una fábrica La transformación de la industria conectada Durante años, muchas infraestructuras industriales vivieron prácticamente...
Read More →
La API que confiaba demasiado en el frontend
Cuando la seguridad parece correcta...
pero no lo es
En una reciente auditoría de ciberseguridad, analizamos una aplicación web empresarial con una arquitectura aparentemente sólida. A primera vista, todo indicaba un nivel de madurez alto: WAF implantado, auditorías periódicas, controles activos…
Sin embargo, bastaron unos minutos de análisis para comprometer la confidencialidad de todos los usuarios.
¿Podíamos ver información de
otros usuarios?
Durante las pruebas, accedimos al perfil del usuario que se nos había facilitado para el análisis y hacer las pruebas de roles correspondientes. Luego, interceptamos dicha petición y modificamos algunos parámetros con la intención de ver si era posible obtener información de otros usuarios que estuviesen registrados en la plataforma y…
¡PREMIO! El resultado fue inmediato, la API devolvía información de otros usuarios sin aplicar controles de autorización adecuados.
¿Y qué podíamos ver en estos perfiles? Pues había un poco de todo…desde ID de usuario, nombre, apellidos, dirección física y de correo electrónico, DNI, foto de perfil … Y lo mejor de todo, dentro del perfil existía una opción para cambiar de contraseña sin validación intermedia de la empresa que estábamos auditando.
¿Podríamos modificar las contraseñas? La respuesta es: SI, podíamos hacerlo y el cómo lo hicimos, os lo enseñaremos en el próximo artículo.
Lo importante ahora es entender cómo en una empresa con un alto nivel de madurez, había sido posible romper la seguridad en RGPD con tanta facilidad y es que no se trataba de un fallo técnico complejo, era un error de confianza en el modelo de interacción.
Este tipo de comportamiento es característico de vulnerabilidades de tipo IDOR (Insecure Direct Object Reference), aunque en este caso el problema raíz era más profundo:
La lógica de autorización no estaba implementada en el servidor.
La aplicación validaba correctamente las acciones desde el frontend (que es la parte visible para el usuario cuando entra en una web desde el navegador).
Pero el backend (que son los sistemas que procesan y controlan la información desde el servidor de dicha web), asumía que esas validaciones no serían manipuladas. En otras palabras, la seguridad estaba implementada en la parte visual del aplicativo que usamos todos día a día, pero si bajas un nivel y trabajas desde las peticiones interceptadas, no se había aplicado ningún tipo de validación ni seguridad.
¿Cuál es el impacto real para el negocio?
Este tipo de vulnerabilidad IDOR tiene implicaciones muy críticas como:
- Exposición de datos personales de clientes
- Riesgo de incumplimiento de normativas como RGPD
- Pérdida de confianza y daño reputacional
- Posible uso malicioso para fraude o suplantación
¿Por qué ocurre este tipo de fallo?
En entornos empresariales, es habitual encontrar este tipo de errores y es porque se asume que el cliente no manipulará las peticiones y esta suposición es incorrecta. La realidad es que cualquier persona con conocimientos básicos puede manipular este tipo de peticiones.La moraleja de esto es que: “El frontend nunca debe ser considerado una capa de seguridad. Recuerda: el frontend muestra y el backend decide.”
¿Cómo se soluciona?
A partir de este caso, destacan varias conclusiones:
- La autorización debe implementarse siempre en backend
- Cada petición debe validar explícitamente el contexto del usuario y la cadena de autenticación en capas más bajas como las APIs
- Es necesario un control de acceso granular en todas las peticiones realizadas desde el aplicativo al servidor. No basta con autenticación
Además, las pruebas automatizadas no detectan fácilmente este tipo de fallos. Este tipo de vulnerabilidades no suele aparecer con herramientas automatizadas.
Se detecta cuando se analiza:
- Cómo interactúan los componentes
- Cómo fluye la lógica de negocio
- Qué se ha asumido en el diseño
Y esto solo puede descubrirse si se hacen análisis manuales y con personal experimentado.
La seguridad no se rompe por un gran fallo, sino por pequeñas decisiones mal conectadas.
Y esto es solo el principio ¡Recuerda, que este hackeo no se queda aquí! En el próximo articulo os contaremos como continuó nuestra historia y cómo modificamos la contraseña de otros usuarios hasta llegar a ser Administradores.
En 4Elitech, realizamos evaluaciones orientadas a identificar este tipo de riesgos, que van más allá de vulnerabilidades técnicas evidentes. Analizamos cómo se comporta realmente una aplicación frente a escenarios de abuso y aunque los Pententers somos conocidos por romper la seguridad, todos nuestros trabajos los realizamos con mucho cuidado y delicadeza.
Porque los fallos más críticos no suelen estar en lo evidente, sino en lo que nadie cuestiona.
Y nosotros estamos para eso.
