OWASP Top 10
En seguridad de aplicaciones, el OWASP Top 10 es un documento de concienciación que se actualiza cada cierto tiempo y que enumera las categorías de fallo de aplicación web que el proyecto considera más importantes. Es un conjunto de categorías que conviene conocer, publicado por una fundación sin ánimo de lucro. No es una norma, ni una certificación, ni un alcance de prueba.
Cómo funciona
El Open Worldwide Application Security Project arma la lista a partir de datos de vulnerabilidades aportados y de una encuesta a profesionales, agrupa los hallazgos en categorías amplias en vez de en fallos concretos, y la vuelve a publicar cada pocos años. Cada entrada describe una clase, como el control de acceso roto o la inyección, con escenarios de ejemplo y guía de prevención, y se corresponde con la CWE (Common Weakness Enumeration) subyacente, de forma que un hallazgo se puede atar a un tipo de defecto concreto.
El valor es el vocabulario compartido. Cuando un informe dice control de acceso roto, quien programa, quien lleva la seguridad y quien audita entienden más o menos lo mismo, y la correspondencia permite rastrear la categoría hasta un identificador CWE preciso cuando hace falta precisión.
Qué sale mal
El problema recurrente no es el documento. Es lo que la gente hace con él en una conversación de compras. Se repiten tres lecturas equivocadas.
Se toma como un alcance. Una prueba que cubre diez categorías y para ahí no ha probado la aplicación: los fallos de lógica de negocio por sí solos no van a aparecer en ninguna lista de categorías genéricas, porque son propios del sistema que se está probando. Se toma como una norma con la que cumplir, cosa que el propio proyecto no afirma; cuando lo que se quiere es un estándar de controles, el estándar de verificación de aplicaciones del mismo proyecto es el documento hecho para ese trabajo. Y se toma como una clasificación del riesgo de tu parque, cuando es una clasificación de prevalencia sobre datos aportados por muchos parques, que no es la misma pregunta.
El efecto de segundo orden es peor. Un escáner que informa de cobertura de las diez categorías puede ser técnicamente exacto y dejar aun así una aplicación con una ruta sin autenticar hasta los datos de otro tenant, porque la afirmación de cobertura va de categorías y no de tu modelo de control de acceso. La misma cautela vale para la lista de API, que va aparte.
Dónde aparece esto en una auditoría
Asociamos cada hallazgo a una categoría para que el informe se pueda comparar con trabajos anteriores y con la salida de un escáner, y después decimos claramente qué hallazgos no tenían ninguna categoría donde encajar. Los pliegos que nombran las diez categorías como alcance conviene renegociarlos antes de la prueba y no después. Confirma la edición vigente antes de citarla, porque las categorías se renombran y se fusionan entre versiones. Esto forma parte de lo que cubre de verdad una evaluación completa de aplicación web.