La mayoría de las intrusiones en aplicaciones web no empiezan con un exploit exótico. Empiezan con una petición que la aplicación debería haber rechazado: la factura de otro cliente, un precio modificado por el camino, un restablecimiento de contraseña que confía en la cabecera equivocada. Los escáneres no detectan estos fallos porque no saben para qué sirve la aplicación.
Probamos como usuarios autenticados de cada rol, trazamos el mapa de lo que puede alcanzar cada rol y después intentamos cruzar cada límite entre ellos. Las herramientas automáticas cubren las clases conocidas. El tiempo de los especialistas se dedica a la lógica, al control de acceso y a las cadenas de pequeñas debilidades que, sumadas, llevan a comprometer el sistema.
01Alcance
Qué ponemos a prueba
Autenticación, sesiones, recuperación de contraseña y autenticación multifactor
Control de acceso horizontal y vertical, aislamiento entre inquilinos
Lógica de negocio: pagos, descuentos, límites, flujos de trabajo, condiciones de carrera
Inyección: SQL, NoSQL, de comandos, de plantillas, entidades externas XML
Lado del cliente: cross-site scripting, CSRF, CORS, postMessage, almacenamiento del navegador
Lado del servidor: SSRF, deserialización, subida de archivos, path traversal, request smuggling
Inicio de sesión único: flujos SAML, OAuth 2.0 y OpenID Connect
Tokens y URL firmadas: gestión de JWT, caducidad, revocación
Configuración: cabeceras de seguridad, TLS, gestión de errores, interfaces expuestas
02Enfoque
Cómo se realiza el trabajo
01
Mapeo
Construimos un mapa de roles, funciones, flujos de datos y puntos de entrada, incluidas las partes de la aplicación a las que la interfaz no enlaza.
02
Base automatizada
Los escáneres y nuestras propias herramientas cubren las clases de vulnerabilidades conocidas, para que el tiempo manual no se dedique a lo que puede encontrar una máquina.
03
Pruebas manuales
Cada función se prueba a mano con los casos de prueba de OWASP WSTG que le corresponden, con énfasis en el control de acceso y la lógica de negocio.
04
Explotación y encadenamiento
Una debilidad se explota hasta la profundidad acordada para demostrar el impacto real y se combina con otras cuando eso permite llegar más lejos.
Clase de debilidad que hay detrás de cada hallazgo.
The MITRE Corporation
06Preguntas
Preguntas sobre este servicio
¿Caja negra, caja gris o caja blanca?
Caja gris por defecto: trabajamos con cuentas y documentación, porque así se encuentra más en el tiempo disponible. La caja negra es adecuada cuando quiere medir lo que consigue alguien externo sin ninguna información. La caja blanca añade el código fuente y se describe en el servicio «Revisión de seguridad del código».
¿Hacen pruebas en producción?
Preferimos un entorno equivalente a producción. Cuando solo existe producción, acordamos ventanas de pruebas, evitamos las acciones destructivas y trabajamos con nuestros propios datos de prueba.
¿No basta con un escáner de vulnerabilidades?
Un escáner encuentra patrones conocidos en peticiones individuales. No sabe que un cliente no debe ver los pedidos de otro ni que un descuento no debe aplicarse dos veces. Esos fallos los encuentran personas que entienden la aplicación.