OWASP Top Ten 2013 en Release Candidate

El proyecto OWASP Top Ten aglutina en una lista los 10 fallos de seguridad más comúnmente explotados en aplicaciones web. Anteriormente hemos tenido una recopilación en el año 2004, 2007 y 2010, y ahora, en 2013 tenemos la lista en versión Release Candidate, donde no hay grandes sorpresas, pero sí algunos cambios. Esta es la lista actual.

El Top 3

Los tres primeros fallos están encabezados una vez más por los fallos de inyección en el lado del servidor. Las técnicas más simples y las más avanzadas de SQL Injection siguen apareciendo sistemáticamente en ataques producidos contra sitios web - como el de Bit9 o el de los Premios Goya -, pero además en la lista aparecen los fallos de inyección de comandos de sistema operativo y los de LDAP Injection.

Figura 1: OWASP Top Ten 2013. Posiciones 1 a 3.

Los fallos de XSS pasan al tercer lugar - supongo que por la cantidad de filtros AntiXSS desplegados en navegadores y compiladores como Visual Studio, donde tener un bug de XSS es para merecer que te corten la mano. Sin embargo, la explotación ha evolucionado mucho, y desde que aparecieron las técnicas de ClickJacking o las inyecciones de código no basadas en JavaScript, estas vulnerabilidades client-side han crecido en explotabilidad. 

En segundo lugar se cuelan los fallos de gestión de la sesión y la autenticación rota. Ejemplos de ellos los hemos tenido con las cámaras de vigilancia que dieron origen al mapa del vouyer o el serio bug descubierto para Alejando Ramos que fue publicado en el libro de Hacker Épico. Otro ejemplo de esto fue el ejemplo de las cookies que almacenaban los usuarios sin validar la password.

Del 4 al 7

En la posición cuarta aparece "Insecure Direct Objet Reference" que hace referencia al descubrimiento de rutas a objetos internos que dan lugar a Path Disclosures, Path Transversals, acceso a ficheros de configuración, etcétera. Por ejemplo, el famoso robots.txt de RTVE, que muestra más rutas de las que debiera.

En la quinta posición queda "Security Missconfiguration" que habla de despliegues inseguros de aplicaciones web por falta de aplicación de configuraciones seguras. El ejemplo más claro de esto es el de la web del Senado de los 500.000 € con el acceso anónimo al panel de control publicado, pero también valdrían los sitios con contraseñas por defecto.

Figura 2: OWASP Top Ten 2013. Posiciones 4 a 7.

Por supuesto, en este punto yo englobaría el uso de sistemas de criptografía insegura o ausencia de ellos, que todavía tenemos sitios que aún no implementan la sesión de usuarios con cifrado de cookies, por ejemplo.

En la sexta posición han situado "Sensitive Data Exposure" donde se dan sitio aquellas webs que dan más información de la debida y que pueden llevar al robo de identidad. Caso de ejemplo típico sería el de Amazon y Apple este verano, que entre ambas permitieron, por no proteger bien los datos de usuario, que el periodista Mat Honan fuera brutalmente hackeado. César Cerrudo en Ekoparty dio una charla fantastica sobre esta problemática. No entran en este grupo los usuarios que publican sus tarjetas de crédito en redes sociales o sus Pasaportes en cualquier web.

En el séptimo lugar queda "Missing Function Level Access Control" en el que se habla de los bugs que hay en ciertas aplicaciones que ocultan funciones del interfaz cuando el usuario no tiene acceso, pero que si éste es capaz de acertar en las llamadas a las funciones puede hacer uso de ellas. Esto es típico en aplicaciones basadas en Webservices o en aquellas en los que el interfaz de usuario se pinta en el cliente mediante un componente Active X.

Los tres últimos: 8, 9 y 10

Para las últimas posiciones nos han quedado los bugs CSRF en la octava posición, el uso de componentes con bugs conocidos en la novena y el uso de redirects inseguros en aplicaciones web que pueden llevar a usuarios a páginas inseguras. Fallos muy comunes y bien conocidos.

Figura 3: OWASP Top Ten 2013. Posiciones 8 a 10.

Aquí solo hay una lista que debes tener en cuenta a la hora de hacer tu aplicación web, pero no te olvides que el número de fallos que puede tener un sitio es mucho mayor y deberías auditar tu  sitio siempre antes de ponerlo en producción en el duro mundo de Internet.

Saludos Malignos!