Limitaciones de los Escaners de Vulnerabilidades para Aplicaciones Web.

Un típico error de las empresas con sus propios equipos de desarrollo o las empresas de desarrollo específicamente, es la tendencia a creer que las aplicaciones web pueden ser convertidas en fortalezas impenetrables con un simple Pen-testing realizado mediante el uso de un programa de escaneo de vulnerabilidades especializado para la web.

Existen muchos de estos programas en formatos diferentes y  la intención de estos (al menos la mayoría) es ayudar al experto en seguridad a realizar una serie de pruebas que permitirán conseguir vulnerabilidades para pasar de inmediato a corregirlas. Sin embargo estos programas, tienen muchas limitaciones:

• Debido a la gran cantidad de vulnerabilidades posibles, y a sus cientos de variantes toman horas en realizar un análisis exhaustivo de la aplicación web, consumen una gran cantidad de recursos y someten a la misma a un "stress" indebido para entornos de producción. Aunque la práctica recomienda tener un entornos independientes de desarrollo y control de calidad, en muchos casos estos no existen.
• Cualquiera que los haya utilizado sabe que producen una gran cantidad de "falsos negativos" y "falsos positivos".
• Necesitan de constante actualización, cada día se descubren nuevas formas de penetrar aplicaciones y por tanto nuevas vulnerabilidades afloran.
• Producen un falso sentido de seguridad web.
• Normalmente no explican la razón por la cual se considera una vulnerabilidad como tal, y menos aún dan al programador y su equipo tips para corregirla, por lo que las vulnerabilidades tienden a quedar sin arreglo.

Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.

En un estudio realizado por David Shelly, Randy Marchany, Joseph Tront  - Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners - que fue presentado en el evento OWASP AppSec DC 2010, utilizando una aplicación en la que se implementaron una serie de vulnerabilidades premeditamente, demostraron  que 6 diferentes escaners de vulnerabilidades detectaron entre todos de la serie de vulnerabilidades implantadas los siguientes porcentajes:

• 59.7% de las vulnerabilidades de SQL Injection por formulario. 
• 6.3% de las vulnerabilidades de SQL Injection por Cookies
• 43.3% de las vulnerabilidades por Reflected XSS
• 11.1% de las vulnerabilidades por Stored XSS
• 0% de las vulnerabilidades por DOM based XSS
• 20% de las vulnerabilidades de Predictable SID en manejo de Sesión.
• 4.4% de variables de Sesión Inseguras por Cookies.

Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.

Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:

• 12% en SQL Injection.
• 13.9% en XSS

Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!

Esto no significa que los escaners de vulnerabilidades para aplicaciones web no sean útiles, claro que lo son y mucho, pero lo son solamente en manos de personal especializado que tenga la capacidad de dicernir entre la realidad y lo que reportan. Si el personal que los va a utilizar no tiene bases sólidas de Seguridad de Aplicaciones Web no podrá obtener de ellos una gran parte lo que pueden ofrecer. En definitiva, son las herramientas de pen-testing que nos dan indicios sobre "como abrir la lata" pero hacerlo y obtener su contenido son asuntos más complejos.

OWASP Cheat Sheets Series - Hojas de Trucos de OWASP

A veces es necesario tener a mano soluciones rápidas y eficientes para evitar tener que releer todo un libro buscando aquel truco que sabemos que hemos leído pero que no recordamos a perfección como era  o dónde fué exactamente que lo leímos. Por otro lado si bien "googlear" es a veces la solución más rápida, tratándose de prevención y seguridad pudieran existir diferentes "soluciones" o puntos de vista, y tratando se escoger las apropiadas podríamos perder un tiempo preciado.

Cuando se trata de seguridad de aplicaciones, tener a mano una lista de trucos eficientes que nos ayuden a prevenir ataques a la hora de generar código o plantear soluciones integradas de protección puede ser una ayuda invaluable.

Pensando precisamente en lo anterior, la gente de OWASP ha creado las listas u hojas de trucos o "cheat sheets", para tener a mano de forma rápida la información de seguridad necesaria para aplicar las técnicas correctas cuando estemos ensamblando y programando las rutinas esenciales de nuestras aplicación.

Estas hojas de trucos  o "cheat sheets" son varias, y a continuación les muestro los enlaces de las más conocidas y útile a mi parecer:

• Authentication Cheat Sheet
• Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
• Cryptographic Storage Cheat Sheet
• SQL Injection Prevention Cheat Sheet
• Transport Layer Protection Cheat Sheet
• XSS (Cross Site Scripting) Prevention Cheat Sheet

Sin duda como podrán apreciar al leerlas son documentos eficiente que van directo al grano en lo referente a explicar los procesos de los tipos de ataque pero sobretodo en lo que se refiere a las técnicas de prevención necesarias a la hora de ensamblar y crear código. Espero que les sean de utilidad.

Hasta la próxima...

Seguridad Web y Google: Gruyere

Es imposible pensar que Google podía faltar a la cita que tiene con todos los programadores a nivel mundial en lo referente a publicar algún tipo de documento para educar a los mismos en el proceso de generación de código seguro.

Pero Google no se conformó con hacer alguno que otro documento, sino creó toda una serie de cursos especializados en seguridad web en lo que se conoce como Google Code University , desarrollando toda una sección de cursos acerca de seguridad web a los que puedes acceder en http://code.google.com/edu/security/index.html

Una aplicación llena de agujeros

Entre estos cursos aparece una muy interesante aplicación llamada Gruyere hecha especialmente para que los programadores puedan aprender cómo son realizados los ataques  las aplicaciones y tomar las medidas pertinentes en su propio código.

Claro, ya se que algunos de ustedes dirán que han utilizado el  proyecto WebGoat de OWASP (Open Wen Application Security Proyect) a la que nos hemos referido en otros artículos pero este caso es algo diferente.

La diferencia primordial entre WebGoat y Gruyere, es que el segundo no necesita ser instalado en un equipo, ya que se puede ejecutar en línea sin necesidad de instalar la aplicación y ponerla en marcha, lo que es para muchos usuarios una ventaja, aunque para otros pudiera ser una limitación. 

La segunda diferencia es que WebGoat está desarrollada en JSP y Java bajo Tomcat, mientras Gruyere está hecha en Python. Esta puede ser una importante diferencia a la hora de tomar una decisión.

Sin embargo en ambos casos el lenguaje en que han sido desarrolladas no es lo importante a menos que quisiéramos ver el código de "como no debemos hacerlo", lo importante es su capacidad de explicarnos paso a paso como los errores o descuidos que comúnmente cometemos a la hora de programar pueden convertirse en nuestro peor enemigo.

Me gustó mucho la forma en que Gruyere explica el procedimiento del XSS en sus varias versiones aunque debo reconocer que WebGoat me pareció más completa y su interfaz es quizás más trabajada (posee incluso un instalador para Windows ). Sin embargo, la capacidad de que la aplicación pueda ser vulnerada directamente en línea le otorga a Gruyere un extra que no posee WebGoat. No se preocupen, la aplicación puede resetearse y además corre en un proceso de "sandbox" que no permite que puedan afectar a otros usuarios mientras ustedes cometen errores y dan sus primeros pasos, ya que cada usuario está ejecutando una copia personal.

Google al igual que OWASP no solo ha desarrollado esta aplicación sino muchas plantillas, presentaciones y otros tipos de material didáctico que valen la pena ser leidos, por lo que les recomiendo que visiten  http://code.google.com/edu/security/index.html y se pongan al tanto con lo que Google tiene que decirnos en cuanto a seguridad web, cuyo equipo seguramente algo de experiencia debe tener en el tema. ¿Cierto? ;)

Hasta la próxima!

¿Qué son los HTTPonly Cookies?

Como ya es sabido una de las mayores amenazas que rondan las aplicaciones web es el XSS o Cross Site Scripting, y algunas de sus múltiples variantes basan su operatividad en la modificación o lectura de los cookies generados por la aplicación en el navegador del usuario.

Si bien un buen sistema de desinfección de parámetros de entrada desde y hacia la aplicación es siempre la mejor solución ante este tipo de ataques, una técnica muy útil que existe desde hace tiempo en el navegador Internet Explorer 6 SP1 y adoptada por todas las nuevas versiones de otros navegadores (Firefox desde 3.01, Opera desde 9.5 )  consiste en declarar los cookies como HTTPonly, protegiéndolos de lectura y escritura por parte de scripts del lado del usuario. De esta forma solo el servidor y el navegador tendrán acceso a la información guardada en los mismos.

La solución es en realidad muy simple en algunos casos, por ejemplo en ASP.NET solo tendrá que agregar un parámetro a la línea de configuración "httpCookies" al archivo de configuración web.config:

<httpCookies httpOnlyCookies = "true"... />

En PHP el proceso es parecido, añada la siguiente línea al archivo php.ini:

session.cookie_httponly = True

En Java EE desde la versión 6, se soporta la propiedad o flag HttpOnly en la interfaz Cookie y esta puede modificarse a true o false con los métodos setHttpOnly y getHttpOnly.
En Tomcat 6 puede colocar la línea del archivo context.xml . Esto es válido para cualquier framework basada en Tomcat como por ejemplo JBoss.

useHttpOnly = True

Como cualquier programador web podrá apreciar el proceso es muy simple, sin embargo esto no es la panacea anti-XSS, recuerde que para estar seguro ante ataques de este tipo de amenaza y otras como el SQL injection, la única solución eficiente proviene de una desinfección a conciencia de los parámetros de entrada hacia a la aplicación.

La importancia de la desinfección de parámetros para evitar ataques en la web

La razón más frecuente por la cual los sitios web sufren ataques de XSS (Cross Site Scripting), SQL inyection así como de otros tipos, se debe primordialmente a la falta de previsión por parte de los programadores a la hora de “Desinfectar los datos recibidos” desde la web o de terceros que pudieran sufrir del mismo problema.

La primordial razón para que un hacker pueda generar un ataque de este tipo a nuestra base de datos y a nuestros usuarios se debe primordialmente a lo anteriormente expuesto y la aceptación de parámetros infectados a su vez se debe a causas como:

Exceso de confianza: El programador no cree que su sitio por diversas razones amerite ser atacado por con alguno de estos métodos debido a que es un sitio común, no transaccional y que no mueve dinero. Lo anterior es falso, ningún sitio está a salvo actualmente debido a que si bien su sitio puede no ser blanco directo de una estafa, puede ser utilizado como redirección confiable de la misma o peor aún como distribuidor de la misma.

Inocencia a la hora de desinfectar los datos: Un desconocimiento de las técnicas básicas de XSS y “SQL Inyection” en la mayoría de los casos es el culpable de esta “inocencia” que genera sistemas de desinfección ineficientes.

Aumento de las rutinas de interacción con el usuario: Los programadores están acostumbrados a recibir datos por el URL o por un formulario. Si bien las técnicas AJAX y los componentes WEB 2.0 utilizan los mismos sistemas de paso de parámetros, como han sido creados por terceros se pudiera llegar a la falsa idea de que tratan el problema por defecto, lo cual en la gran mayoría de los casos es falso. Cualquier procedimiento que tome parámetros bien sea del usuario o de otras fuentes como bases de datos de terceros y servicios web, debe desinfectar dichos datos.

Grandes volúmenes de código y la carencia de rutinas centralizadas para el tratamiento de los datos: Cundo se generan cientos de páginas web, una gran mayoría de estas recibe parámetros. La falta de una rutina que centralice todas las solicitudes y redirija las mismas a las rutinas correspondientes, es la razón por la cual siempre escapa una rutina en la cual los datos no son validados correctamente. Bien sea por descuido o intervención de varios programadores en un mismo proyecto, a medida que una aplicación tiene más rutinas tiene más entradas de datos y por consiguiente más problemas de desinfección.

Creer que solo los campos de texto son vulnerables: En manos de personas expertas, todo parámetro o campo es vulnerable a infección. En un formulario forjado, lo que para nosotros es un “checkbox”, para un hacker es una entrada más de información en la que puede incluir código infectado. Lo mismo va para las listas y otros campos con entradas predefinidas.

Confiar en la validación del lado cliente en Javascript: Esto es un error muy común, basta solo desactivar el javascriopt para hacer que un formulario de datos se comporte de forma completamente impredescible para el sistema.

Para no entrar en detalle y aburrir, vamos a dejar las causas y entremos en las posibles soluciones:

• Estudio por parte del programador de las técnicas básicas de XSS y SQL Inyection (y otras): Una de las mejores fuentes de aprendizaje para un programador web es el OWASP (Open Web Application Security Proyect) http://www.owasp.org/index.php/Main_Page . Allí encontrará libros y artículos de seguridad web así como el proyecto WebGoat que consiste en una aplicación web auto instalable en su equipo, que deberá ser atacada por usted mediante técnicas que aprenderá paso a paso.

• Uso de APIs y librerías de desinfección de código:
  Para disminuir el esfuerzo requerido en grandes proyectos en referencia a la desinfección y control de parámetros, existen proyectos interesantes entre los cuales caben destacar los proyectos AntiSamy de OWASP para diferentes plataformas, que son simplemente APIS que permiten asegurar que los datos recibidos desde el cliente no contienen código maligno. Para aquellos que programen en ASP.NET , Microsoft pone gratis a disposición del programador la librería Microsoft Anti-Cross Site Scripting Library

• Centralización de las rutinas de recolección de desinfección de parámetros: Si su proyecto es razonablemente grande y debe evolucionar en manos de varios programadores, entonces debería empezar a pensar en generar una rutina única de recepción de parámetros. Esta rutina debe recoger los parámetros recibidos y enviarlos a las rutinas correspondientes ya depurados, así usted dejará de preocuparse por la desinfección de parámetros y otros asuntos de seguridad para los cuales tendrá que hacer revisiones en una sola rutina centralizada.

Espero que estos consejos les sean útiles para prevenir ataques de varios tipos de ahora en adelante, sin embargo recuerde un último consejo: No asuma absolutamente en cuanto a la desinfección de los datos, los atacantes se basan precisamente en vulnerar las posiciones comúnmente asumidas por los programadores.