Awesome WAF 
Todo sobre los cortafuegos de aplicaciones web (WAF) desde una perspectiva de seguridad. 🔥
Prólogo: Originalmente, esta era mi propia colección sobre WAF. La publico como código abierto con la esperanza de que sea útil para pentesters e investigadores. Como dice el refrán, "la comunidad solo aprende unos de otros".
Una definición concisa: Un cortafuegos es un punto de aplicación de políticas de seguridad situado entre una aplicación web y el cliente final. Esta funcionalidad puede implementarse en software o hardware, ejecutándose en un dispositivo appliance o en un servidor típico con un sistema operativo común. Puede ser un dispositivo independiente o estar integrado en otros componentes de red. (Fuente: PCI DSS IS 6.6)
Un cortafuegos de aplicaciones web se sitúa entre un usuario y una aplicación web y tiene la tarea de evitar que cualquier actividad maliciosa llegue a la aplicación. Un WAF filtra la parte maliciosa de la solicitud o simplemente la bloquea.
Siéntete libre de contribuir.
Contenido:
Introducción:
Cómo funcionan los WAF:
- Utilizando un conjunto de reglas para distinguir entre solicitudes normales y maliciosas.
- A veces utilizan un modo de aprendizaje para agregar reglas automáticamente mediante el aprendizaje del comportamiento del usuario.
Modos de funcionamiento:
- Modelo negativo (basado en listas negras) - Un modelo de listas negras utiliza firmas preestablecidas para bloquear solicitudes claramente maliciosas. Las firmas de los WAF que operan en modo negativo están diseñadas específicamente para prevenir ataques que explotan ciertas vulnerabilidades de aplicaciones web. Los cortafuegos de aplicaciones web de modelo de listas negras son una excelente opción para aplicaciones web expuestas a internet público y son muy efectivos contra vulnerabilidades principales. Por ejemplo, una regla para bloquear todas las entradas
<script>*</script> previene ataques básicos de cross-site scripting.
- Modelo positivo (basado en listas blancas) - Un modelo de listas blancas solo permite el tráfico web según criterios específicamente configurados. Por ejemplo, se puede configurar para permitir solo solicitudes HTTP GET desde ciertas direcciones IP. Este modelo puede ser muy efectivo para bloquear grandes ataques potenciales, pero también bloqueará mucho tráfico legítimo. Es probable que los cortafuegos de modelo de listas blancas sean mejores para aplicaciones web en una red interna diseñadas para ser utilizadas solo por un grupo limitado de personas, como empleados.
- Modelo mixto/híbrido (modelo inclusivo) - Un modelo de seguridad híbrido combina tanto listas blancas como listas negras. Dependiendo de las especificaciones de configuración, los cortafuegos híbridos podrían ser la mejor opción tanto para aplicaciones web en redes internas como para aplicaciones web en internet público. Un buen escenario puede ser cuando la aplicación web está orientada a internet público (usar listas negras) mientras que el panel de administración debe estar expuesto solo a un subconjunto de usuarios (usar listas blancas).
Metodología de prueba:
Dónde buscar:
- Busca siempre puertos comunes que expongan un WAF, específicamente los puertos
80, 443, 8000, 8080 y 8888. Sin embargo, es importante tener en cuenta que un WAF puede implementarse fácilmente en cualquier puerto que ejecute un servicio HTTP. Es recomendable enumerar primero los puertos de servicio HTTP y luego buscar WAF.
- Algunos WAF establecen sus propias cookies en las solicitudes (por ejemplo, Citrix Netscaler, Yunsuo WAF).
- Algunos se asocian con cabeceras separadas (por ejemplo, Anquanbao WAF, Amazon AWS WAF).
- A menudo, otros alteran cabeceras y mezclan caracteres para confundir al atacante (por ejemplo, Netscaler, Big-IP).
- Algunos se exponen en la cabecera
Server (por ejemplo, Approach, WTS WAF).
- Algunos WAF se exponen en el contenido de la respuesta (por ejemplo, DotDefender, Armor, Sitelock).
- Otros WAF responden con códigos de respuesta inusuales ante solicitudes maliciosas (por ejemplo, WebKnight, 360 WAF).
Técnicas de detección:
Para identificar WAF, necesitamos provocarlo (simuladamente).
- Realizar una solicitud GET normal desde un navegador, interceptar y registrar las cabeceras de respuesta (especialmente las cookies).
- Realizar una solicitud desde la línea de comandos (ej. cURL) y probar el contenido de la respuesta y las cabeceras (sin incluir user-agent).
- Realizar solicitudes GET a puertos abiertos aleatorios y capturar banners que puedan exponer la identidad del WAF.
- En páginas de inicio de sesión, inyectar payloads comunes (fácilmente detectables) como
" or 1 = 1 --.
- Inyectar payloads ruidosos como
<script>alert()</script> en barras de búsqueda, formularios de contacto y otros campos de entrada.
- Adjuntar un
../../../etc/passwd ficticio a un parámetro aleatorio al final de la URL.
- Agregar palabras clave llamativas como
' OR SLEEP(5) OR ' al final de las URLs en cualquier parámetro aleatorio.
- Realizar solicitudes GET con protocolos obsoletos como
HTTP/0.9 (HTTP/0.9 no admite consultas de tipo POST).
- En muchas ocasiones, el WAF varía la cabecera
Server según diferentes tipos de interacciones.
- Técnica de acción de caída: enviar un paquete FIN/RST crudo y modificado al servidor e identificar la respuesta.
Consejo: Este método se puede lograr fácilmente con herramientas como HPing3 o Scapy.
- Ataques de canal lateral: examinar el comportamiento temporal de la solicitud y el contenido de la respuesta.
Consejo: Se pueden encontrar más detalles en una entrada de blog aquí.
0xinfection/awesome-waf
