En esta serie de artículos vamos a analizar el contexto de seguridad de las aplicaciones web, así como también las herramientas que podremos utilizar para auditarlas y protegerlas. Como parte inicial, vamos a analizar las particularidades de seguridad de las aplicaciones web, el OWASP Top 10 2013 y la importancia de la validación de datos.
El problema principal de las aplicaciones web, que lo diferencia de las aplicaciones “convencionales” es que en las aplicaciones web tenemos involucradas a una gran cantidad de tecnologías, y cada una de ellas puede contener o introducir vulnerabilidades.
Por ejemplo, en una típica aplicación LAMP (Linux, Apache, MySQL, PHP), ya tenemos cuatro tecnologías que son de suma importancia y cada una de ellas puede introducir diferentes vulnerabilidades, a saber:
Tanto el Sistema Operativo (GNU/Linux), como el Servidor Web (Apache), como la Base de Datos (MySQL), como el Lenguaje de Programación (PHP) podrían estar mal configurados y/o contener errores en su código que permitiría a un atacante tomar control de la aplicación.
Aquí debemos notar que, si bien es responsabilidad del administrador del sistema configurar correctamente todos los componentes, éste no podrá solucionar vulnerabilidades que aún no se hayan hecho públicas y/o para las cuales no haya parches disponibles. Dicho esto, SI es reponsabilidad del administrador del sistema que todos los componentes se encuentren debidamente actualizados.
Hasta aquí, hemos notado que hay cuatro componentes de sistema que podrían introducir vulnerabilidades, y aún no hemos empezado a hablar del código propio de la aplicación que, en este caso, estará escrita en PHP. En esta área, necesitamos hablar de las metodologías de programación segura, que muchos desarrolladores, ya sea por falta de tiempo o de experiencia, no siguen. Esto probablemente introduzca vulnerabilidades del estilo OWASP Top 10 (que analizaremos en breve).
Sumado a todo esto, debemos considerar que, las aplicaciones actuales, suelen depender de ciertas tecnologías adicionales a las listadas con anterioridad como, por ejemplo, JavaScript, ActionScript, HTML5 y CSS3. Todas ellas, en mayor o menor medida podrían contener vulnerabilidades o incluir nuevos vectores de ataque.
Consideremos que, en este ejemplo, hablamos de una aplicación del tipo “LAMP”, pero este análisis aplica a cualquier aplicación web, por ejemplo “Windows Server + MS SQL Server + Internet Information Services + ASP.net”.
Por último, destaquemos que, algunas aplicaciones web, utilizan un “mix” de tecnologías, en el cual podemos ver, por ejemplo, una base de datos SQL y una base de datos NoSQL. O más de un lenguaje de programación, lo cual agrega aún más complejidad y posibles vectores de ataque.
Todo esto hace que las aplicaciones web no sean nada sencillas de proteger, aunque veremos que es posible y perfectamente realizable si trabajamos con criterio.
OWASP – Open Web Application Security Project (www.owasp.org) es un proyecto dedicado a determinar y combatir las causas que hacen que las aplicaciones web sean inseguras.
La comunidad OWASP está formada por empresas, organizaciones educativas y particulares de todo mundo. Juntos constituyen una comunidad de seguridad informática que trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.
Uno de los proyectos más reconocidos de esta organización es el OWASP Top 10, que es, básicamente, la lista de las diez vulnerabilidades más frecuentes y peligrosas en las aplicaciones web.
OWASP Top 10 fue lanzado por primera vez en 2004, y están disponibles las versiones 2007, 2010 y 2013. A partir de la versión 2010, se da prioridad al riesgo, no sólo a la prevalencia de las vulnerabilidades.
A continuación podemos ver la lista de vulnerabilidades OWASP Top 10 2013:
Si hacemos un breve análisis de las vulnerabilidades aquí listadas, podremos observar que muchas de ellas se deben a no validar correctamente los datos de entrada de las aplicaciones web. Esto es, básicamente, por un mal concepto de lo que son “datos fiables” y “datos no-fiables”.
Datos Fiables: Son los datos sobre los cuales tenemos total control y que no pueden ser modificados por terceros ajenos a la aplicación. Por ejemplo, la hora del sistema, las configuraciones internas de la aplicación, las variables de entorno, etc.
Datos No-Fiables: Todos los otros datos.
Si, es verdad que los “datos no-fiables” son algo bastante amplio, pero es preferible identificar prácticamente cualquier dato como “no-fiable”, salvo que tengamos la certeza de que dicho dato no puede ser alterado por ningún tercero. Esto es así porque los controles de seguridad y validación de datos nunca están de más (no hay problema si un dato fiable es validado como si fuera no-fiable), pero puede ser muy peligroso para una aplicación manipular un dato como fiable cuando verdaderamente no lo es.
Existen dos casos muy habituales que ejemplifican los errores que suelen cometer los desarroladores con respecto a la validación de datos:
Tipos de Dato Esperados: Por ejemplo, en un campo de formulario en el que se le está pidiendo a un usuario que introduzca su año de nacimiento. Obviamente, podemos esperar que el valor de este campo va a ser numérico (p. ej: 1985). Pero, ¿qué sucede si la aplicación recibe valores alfanuméricos o caracteres especiales?
Es muy habitual encontrar aplicaciones que nos devuelven un mensaje de error interno, el cual nos hace pensar que el desarrollador no consideró la posibilidad de que, por error o de forma malintencionada, un usuario introdujera datos de un tipo no esperado en el formulario.
Este tipo de errores podría llegar a introducir vulnerabilidades serias en una aplicación, como Cross-Site Scripting (OWASP Top 10 2013 – A3) o SQL Injections (OWASP Top 10 2013 – A1).
Datos Supuestamente No-Modificables: Es muy común encontrar aplicaciones que consideran ciertos datos como de “sólo lectura”, cuando verdaderamente son datos fácilmente modificables por un atacante.
El ejemplo más habitual de esto son las cabeceras HTTP, como “User-Agent” y “Referer”. Dichas cabeceras pueden ser modificadas en cualquier navegador web y, si no son correctamente validadas por la aplicación, podrían llegar a existir serias vulnerabilidades.
Volviendo a la temática de “Datos No Validados”, aquí podemos ver qué elementos del OWASP Top 10 2013 podrían estar asociados con datos que no han sido validados correctamente:
A1 – Inyección
A2 – Pérdida de Autenticación y Gestión de Sesiones
A3 – Secuencia de Comandos en Sitios Cruzados (XSS)
A4 – Referencia Directa Insegura a Objetos
A6 – Exposición de Datos Sensibles
A7 – Ausencia de Control de Acceso a las Funciones
A8 – Falsificación de Peticiones en Sitios Cruzados (CSRF)
A10 – Redirecciones y Reenvíos No-Validados
Como podemos observar, ocho de las diez vulnerabilidades más críticas de las aplicaciones web podrían estar relacionadas con una pobre validación de datos. Esto hace que la validación de datos tenga que ser nuestra prioridad número 1 al hablar de seguridad en aplicaciones web.
Queda en las particularidades de cada lenguaje el cómo se van a validar los datos, por ejemplo, en PHP podemos utilizar la función “htmlentities” para escapar caracteres especiales HTML y la función “mysqli_real_escape_string” para escapar caracteres especiales en consultas a bases de datos MySQL.
Para más información, podemos consultar la documentación de cada lenguaje, y la guía rápida para las mejores prácticas de programación segura de OWASP:
www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
En la próxima parte de esa serie de artículos haremos un repaso por las herramientas que podemos utilizar para auditar la seguridad de una aplicación web.
Fabian Portantier
Consultor en Seguridad Informática
www.portantier.com
www.twitter.com/portantier
