26 agosto 2008

Por no hacer excesivamente ardua la lectura del análisis sobre los mecanismos que implementan los cortafuegos de aplicaciones web, decidí publicarlo en varias entregas. Así que aquí vamos con la parte que os debía.

Al hilo de lo que detallábamos en el post sobre los Modelos de Seguridad Positiva vs. Seguridad Negativa, los diversos motores de un WAF responden a estos mismos criterios. Así, podemos permitir todo el tráfico entrante excepto aquel que nosotros consideramos un ataque (modelo de seguridad negativa), o podemos definir que todo tipo del tráfico web está prohibido excepto aquel que nosotros permitamos expresamente (modelo de seguridad positiva).

De esta manera, los motores basados en lista negra o en lista ponderada podrían encuadrarse en el modelo de seguridad negativa, y los análisis basados en lista blanca pertenecerían indudablemente al modelo de seguridad positiva.

Las diferentes comprobaciones que los WAFs efectúan son las siguientes:

* Normalización de URL (modelo de seguridad positiva): controlar el tamaño de los nombres y de los valores de los parámetros y de las cabeceras, de manera que no excedan lo permitido en la RFC de HTTP. Permitir los métodos HTTP estándar (GET y POST) y prohibir los extendidos (HEAD, OPTIONS, métodos WebDav, etc...). Eliminar los diferentes posibles Encodings o Decodings de los parámetros (mecanismos de evasión ante IPS o WAF). Deshacer los posibles intentos de Directory Traversal eliminando las repeticiones de "..\..\", etc,...

* Lista Negra (Modelo de Seguridad Negativa): Si la petición llega siendo "sana", enfrentamos la petición contra una serie de expresiones regulares referidas a ataques conocidos contra aplicaciones comunes (OWA, Lotus Notes, SAP, Horde, etc,... ) de manera que si en algún caso hacen "pattern matching" contra alguna expresión de la lista se denegará dicha petición. Esto puede generar gran cantidad de falsos positivos debido a que aplicaciones que puede que no sean vulnerables al ataque de la lista pero que coincidan con una expresión regular, provoquen una denegación de servicio. Asimismo, las listas negras no son un mecanismo óptimo para detener ataques del tipo SQL injection, XSS (Cross-Site Scripting), command injection. Un ejemplo muy claro de esta limitación sería por ejemplo un parámetro en una GET de la manera "index.php&action=drop". En esta situación, una lista negra excesivamente estricta provocaría un bloqueo puesto que "drop" puede conllevar el borrado de una tabla de una base de datos, por lo que debería vetar el acceso.

* Lista Ponderada (o Scoring List): Este mecanismo de análisis de tráfico funciona de manera similar a un antispam. Pertenece al modelo de seguridad negativa. Asigna pesos a aquellas porciones de la petición web de manera según tenga definidos en una tabla de scoring. Finalmente si la suma de los diferentes pesos asignados a una petición supera un determinado umbral, la bloquea. En el caso anterior, si suponemos que el umbral de bloqueo es 1, y asignamos 0.30 a la cadena "drop", la dejaría pasar. Sin embargo, en una petición de la forma "index.php&action=';drop * from data;--" al asignar 0,30 a "drop", 0,50 a "*" y 0,30 a "from" y 0,20 a "-", tendríamos 0,3 + 0,5 + 0,3 + 0,2 + 0,2 = 1,5 > 1 por tanto bloquearía el intento de SQL injection. De esta forma tenemos una forma mucho más "inteligente" de bloquear este tipo de ataques. El único WAF que conocemos que incorpore este sistema de análisis es rWeb de DenyAll.

* Lista Blanca (modelo de seguridad positiva): Para determinado tipo de aplicaciones en las que el formato de los parámetros de entrada en las GET o POST no varíe muy a menudo, puede resultar interesante definir dicho formato a nivel de lista blanca, de manera que sólo aquellas peticiones que encajen ante dicha plantilla podrán acceder a la aplicación, denegándose todas las demás opciones.

Y hasta aquí puedo leer esta vez. En la siguiente entrega terminaré de contar otros mecanismos implementados para evitar ataques en aplicaciones web. Asímismo, haré una breve recopilación de los diferentes productos comerciales y libres expuestos en la entrega anterior, indicando las diferencias entre unos y otros.... Y que sea el lector quien elija en qué herramienta quiere confiar la seguridad de sus aplicaciones web (tanto las expuestas a Internet como las aplicaciones internas...no olvidéis que el principio de pareto tiene múltiples ejemplos en la naturaleza)