Podcast: Reproducir en una nueva ventana | Descargar
El tema del capítulo de hoy fue sugerido por nuestro compañero del grupo de Telegram Fran Andrades (@andradesfran en Twiter). Así que, a petición de los oyentes (al menos de uno), hoy hablaremos de OWASP.
Logo OWASP. Fuente imagen: OWASP.org
Empecemos por lo primero: OWASP son las siglas de Open Web Application Security Project, que se traduciría como Proyecto abierto de seguridad en aplicaciones web. Nació en 2001 y su misión es combatir las causas que hacen que el software sea inseguro. Para gestionar este proyecto se creó, ya en 2004, una entidad sin ánimo de lucro: la Fundación OWASP. Si bien dicha fundación es la responsable legal de la gestión del proyecto y de la infraestructura (tanto técnica como humana) necesaria para su funcionamiento, el trabajo es realizado por una comunidad de usuarios, organizaciones educativas y empresas que se coordinan en la denominada Comunidad OWASP.
Así pues, la Comunidad OWASP crea, adapta y traduce documentación, guías y consejos sobre el desarrollo de software seguro, que es la razón de ser del Proyecto, mientras que la Fundación se encarga de gestionar los trabajos administrativos y de infraestructura que permiten que todo funcione. Espero haber aclarado un poco qué hace quién 🙂
Los cuatro pilares del proyecto OWASP son:
- Abierto: Todo el resultado de la gestión es público
- Innovación: Se promulga la innovación y experimentación para buscar nuevas soluciones a los problemas del desarrollo seguro
- Global: Cualquier persona puede participar
- Integridad: La comunidad OWASP está formada por un gran número de personas y siempre propone soluciones independientes a cualquier fabricante garantizando así su independencia
OWASP busca como objetivo final el desarrollo seguro de aplicaciones, para lo cual desarrolla diferentes proyectos que buscan conseguir la seguridad en diferentes aspectos del desarrollo de aplicaciones web. Se han creado herramientas software que permiten detectar vulnerabilidades en el propio código (como WebScarab, DotNet…), guías sobre cómo programar de forma segura y que comprobaciones hacer; se han creado plataformas de formación (como webGoat), pero el proyecto más conocido de OWASP es Top10: el documento donde se identifican y explican las 10 vulnerabilidades más críticas en las aplicaciones web.
El documento OWASP Top10, que nació en 2003, se actualiza y presenta cada 3 años. Top10 se ha convertido en un estándar de facto utilizado por los desarrolladores para determinar y combatir las causas del software inseguro.
Fuente imagen:PerfectYourPodcast
Si bien las primeras versiones se daba prioridad a la prevalencia de las vulnerabilidades en 2010 se cambió el enfoque hacia la gestión de riesgos. La última actualización de Top10 aparece en 2017 y no en 2016 como era de esperar ya que se decidió realizar un cambio profundo en los procedimientos de elaboración de dicho documento y en la forma de recolectar la información de múltiples fuentes (voluntarios, empresas, entidades de seguridad oficiales…). Igualmente se ha cambiado el método de clasificación de las vulnerabilidades, por lo que no todas las categorías coinciden con la de los años anteriores.
Veamos pues un resumen del listado de las 10 vulnerabilidades más críticas en las aplicaciones web:
En primera posición desde 2010 (en 2007 estaba en segunda posición) se encuentra la vulnerabilidades por inyección de comandos. En los capítulos decimoséptimo y decimoctavo ya hablamos sobre las inyecciones SQL, si bien esta categoría no se limita únicamente a este lenguaje. La vulnerabilidad aparece cuando no se analiza correctamente la información recibida por la aplicación y permite la ejecución de código no deseado.
Las implementaciones incorrectas o incompletas de las funciones de autenticación y gestión de sesiones son las causantes de que en segundo lugar del Top10 tengamos la categoría Pérdida de autenticación. En este caso el riesgo principal es la suplantación de identidad de otro usuario al comprometerse contraseñas, tokens de usuarios o sistemas de recuperación de sesiones.
Si bien en el documento de 2013 la Exposición de datos sensibles se encontraba en sexta posición en la última versión sube hasta la tercera. La gran difusión de aplicaciones web que hacen uso de datos sensibles, hace que la no protección adecuada de esta información se convierta en uno de los riesgos más críticos. Los sistemas web deben asegurar que esta información sensible esté siempre cifrada tanto en almacenamiento como en transmisión.
En cuarta posición aparece una nueva vulnerabilidad: La gestión de Entidades Externas XML. Al parecer mucho procesadores XML antiguos permiten, de forma predeterminada, la llamada a funciones externas, así un atacante malicioso sólo debe enviar un fichero XML que haga referencia a una URL maliciosa para conseguir su ejecución en el servidor.
La categoría de Pérdida de control de acceso incluye todas las ocasiones en las que las restricciones a los usuarios autenticados no se aplican correctamente. Así un usuario podría llegar a ver o modificar información de otros, cambiar permisos de accesos, etc. Si en la posición dos nos centrábamos en debilidades en el acceso al sistema, aquí estaríamos hablando de las funcionalidades disponibles dentro del sistema.
Las aplicaciones web pueden ser vulnerables no por fallos en la programación sino por una Configuración de seguridad incorrecta. La falta de securización de la infraestructura; la permanencia de servicios no necesarios; la no actualización de versiones de aplicaciones vulnerables; o no cambiar las contraseñas por defecto son ejemplos de vulnerabilidades dentro de esta categoría.
En séptima posición nos encontramos las vulnerabilidades de Cross Site Scripting. Esto sucede cuando una aplicación toma datos no confiables y los entrega al navegador del usuario para que los ejecute. Así se permite la ejecución de comandos en el navegador de la víctima pudiendo modificar sitios web, redirigir al usuario a sitios maliciosos o secuestrar una sesión.
Cuando una aplicación debe convertir diferentes objetos de un formato a otro (p.e. de XML a JSON), debe estar preparada para tratar correctamente objetos manipulados, desordenados o repetidos para evitar caer en la deserialización insegura. Este tipo de ataques suelen buscar una ejecución de código en el servidor o la elevación de privilegios.
Teniendo en cuenta que muchos componentes (como bibliotecas, módulos o frameworks) se ejecutan con los mismos permisos que la aplicación a la que sirven, si estos elementos resultan ser vulnerables afectarán directamente a la seguridad de la aplicación. Así pues el uso de componentes con vulnerabilidades conocidas puede debilitar las defensas de las propias aplicaciones.
En la posición 10 se propone una de las vulnerabilidades más comentadas: el registro y monitoreo insuficiente. Los últimos estudios demuestran que el tiempo de detección de una brecha de seguridad es de cerca de 200 días y que generalmente son detectados por terceros y no por los propios sistemas internos. Uno de los motivos de esta alta permanencia de los ataques es la falta de un registro de acciones completo y una revisión y monitorización insuficiente.
OWASP Top10 2017. Fuente imagen: Dragonjar
Tras repasar el nuevo Top10 se puede ver que los cambios en la metodología de trabajo y toma de decisiones ha llevado a situaciones no acostumbradas: Por ejemplo podemos ver en la cuarta posición una vulnerabilidad por el uso de procesadores XML antiguos o malconfigurados; mientras que la vulnerabilidad de uso de configuraciones de seguridad incorrectas (más genérica que la específica de XML) se encuentra en sexta posición. Aunque inicialmente puede chocar esta clasificación los autores proponen destacar específicamente la vulnerabilidad de procesadores XML mal configurados por su especial ocurrencia frente a otros sistemas mal configurados. Se busca así destacar un problema específico con la intención de que sea corregido más rápidamente que si simplemente estuviera englobado en la problemática más general.
Igualmente la introducción del monitoreo insuficiente como una vulnerabilidad del Top10, aunque en última posición, genera algunas dudas ya que puede deducirse que no es una vulnerabilidad de las aplicaciones web en sí, sino más bien del entorno de gestión y administración de sistemas.
Aún con todas estas dudas sobre categorías específicas, OWASP Top10 es un estándar de facto para que los desarrolladores de aplicaciones web puedan determinar y combatir las causas que hace que sus aplicaciones sean inseguras.
Si quieres participar en la Comunidad OWASP y ayudar en cualquiera de sus proyectos, sólo debes solicitar una cuenta en www.owasp.org. Si no eres un gran programador siempre puedes ayudar con traducciones, guías de estilo, revisiones de documentos, etc.