¿Cómo mitiga vulnerabilidades un WAF?

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

En nuestro próximo informe State of Application Delivery 2018, señalamos que el uso de firewalls de aplicaciones web (WAF) lleva años aumentando de forma constante. Es algo positivo, porque hoy en día las aplicaciones son la puerta de acceso a los datos de clientes y empresas, y los métodos tradicionales para controlar el acceso en la capa de red no son suficientes. Esto se debe a que cada vez más actores maliciosos atacan las identidades y las propias aplicaciones para hacerse con ese oro digital.

Entonces, ¿cómo mitiga exactamente un WAF todas esas vulnerabilidades que no dejan de aparecer como malas hierbas en el jardín? Un WAF utiliza tres métodos principales para detectar y prevenir ataques web: denegar o permitir solicitudes, inspeccionar y rechazar, y usar firmas.

Veamos cada uno de ellos, ¿de acuerdo?

Denegar/permitir solicitudes

El método de denegación/autorización de solicitudes es muy similar al modelo tradicional de puerta de entrada utilizado por los cortafuegos de red. Las solicitudes se deniegan o se autorizan en función de la información disponible. Esta información puede ser sencilla, como una dirección IP, o más compleja y específica de HTTP, como OPTIONS o METHODS.

• Listas de bloqueo y autorización
  Si sabe que un actor malicioso procede de una dirección IP o un intervalo de direcciones IP concretos, bloquéelo. Si sabe que una aplicación solo está autorizada a recibir solicitudes de una dirección IP o un intervalo de direcciones IP concretos, permita únicamente esas solicitudes. Este es el método de protección más sencillo y se basa en un conjunto de información bastante estático: las direcciones o los intervalos de IP desde los que deben o no deben proceder las solicitudes.
  
  Quizá esté pensando: ¿por qué no utilizar simplemente un cortafuegos de red para hacerlo? Al fin y al cabo, esa es su función. En entornos locales, funciona muy bien. Sin embargo, si tiene aplicaciones que debe proteger en la nube pública, puede que no sea una opción. Y si forma parte del 59 % de los encuestados en nuestro informe State of Application Delivery 2018 que ya han invertido en entre 2 y 6 proveedores de nube distintos, no puede dar por sentado que las políticas de los cortafuegos de red sean las mismas en todos ellos. Aunque puede implementar las mismas reglas en varias nubes, aplicarlas en un WAF le permite utilizar la misma política y el mismo WAF en varios entornos. La coherencia es fundamental para lograr una seguridad eficaz y escalable.
• Restricción de opciones
  HTTP utiliza un conjunto de cabeceras para indicar a la plataforma de aplicaciones (y a la aplicación) qué quiere hacer el usuario. Los MÉTODOS HTTP, por ejemplo, se pueden utilizar para obtener (GET), cargar (PUT), enviar (POST) y eliminar (DELETE) recursos. El campo OPTIONS también tiene un conjunto de valores restringido por una RFC que se puede controlar fácilmente mediante un WAF. Algunas vulnerabilidades, como Optionsbleed, aprovechan estos campos. Para impedir que se exploten dichas vulnerabilidades, puede utilizar el WAF para restringir los valores posibles únicamente a aquellos que necesite permitir para que la aplicación funcione correctamente. En algunos casos, el WAF restringe estos valores de forma predeterminada. Por ejemplo, BIG-IP ASM (WAF de F5) no permite de forma predeterminada el método HTTP OPTIONS.

Firmas

Las firmas son otro método de protección habitual en muchas soluciones de seguridad. Los servicios antivirus y antimalware se basan en firmas que les permiten buscar rápidamente indicios de virus y malware y marcarlos como amenazas. Los sistemas IPS/IDS también dependen en gran medida de este método, al igual que los WAF. Existen dos tipos de firmas: las definidas por el usuario y las gestionadas por el proveedor.

• Gestionadas por el proveedor
  Las firmas gestionadas por el proveedor suelen almacenarse en una «base de datos» que este mantiene automáticamente. Esto incluye la actualización de la base de datos cuando se detectan nuevas vulnerabilidades que pueden identificarse mediante una firma digital única. Un WAF compara las solicitudes entrantes con la base de datos y actúa en consecuencia si encuentra una coincidencia con alguna de sus firmas. Las firmas pueden ser simples cadenas de texto sin formato, aunque suelen consistir en combinaciones complejas de cadenas difíciles de interpretar que representan código malicioso capaz de activar la ejecución remota o de dañar la plataforma de la aplicación para obtener acceso o provocar una denegación de servicio.
• Definidas por el usuario
  Las firmas definidas por el usuario permiten a los operadores añadir rápidamente una firma a la base de datos. Esta capacidad es importante para garantizar una respuesta rápida (en muchos casos, ante vulnerabilidades de día cero) a nuevas vulnerabilidades, así como para mitigar aquellas para las que aún no se haya publicado una firma gestionada por el proveedor.

Inspección

Por último, se incluye la inspección para garantizar un control total sobre las solicitudes (y las respuestas). La inspección de las solicitudes permite al WAF comparar la información de la solicitud con cadenas y valores conocidos como válidos o maliciosos para determinar si la solicitud es maliciosa o legítima. En las aplicaciones HTTP (es decir, la mayoría de las que existen actualmente en Internet), esta es la funcionalidad más importante que debe ofrecer un WAF. Si un WAF no permite programar la inspección, conviene reconsiderar esa elección. Dado que HTTP se basa en texto y es extensible, resulta prácticamente imposible ofrecer una lista exhaustiva de opciones y métodos con casillas de verificación que puedan utilizarse para inspeccionar las solicitudes. Muy pocas cabeceras HTTP tienen opciones restringidas, por lo que resulta muy difícil limitar qué se puede incluir en ellas y qué no. Esto significa que, a menudo, es necesario realizar una inspección para detectar código malicioso incrustado en las cabeceras o en la propia carga útil. La inspección puede utilizarse de dos formas: mediante cabeceras conocidas y mediante la carga útil.

• Cabeceras conocidas
  Existe un conjunto de cabeceras bien definidas que se incluyen en todas las solicitudes HTTP. Host, User-Agent, Content-Type, etc. son prácticamente omnipresentes. Cada una es poco más que una cadena de texto, con una variedad de combinaciones tan amplia que resulta difícil incluir sus valores en una lista de permitidos, por lo que deben analizarse individualmente en busca de valores que parezcan maliciosos. Por lo general, un WAF puede analizar rápidamente las cabeceras HTTP y permitir su inspección. Se encuentran al principio de cada solicitud y se sabe que se han utilizado para llevar a cabo diversos ataques contra plataformas de aplicaciones: ApacheKiller, Optionsbleed y Apache Struts son algunas de las vulnerabilidades más conocidas.
• Inspección de la carga útil
  La inspección de la carga útil consiste precisamente en eso: examinar toda la carga útil —desde el primer byte hasta el último— en busca de combinaciones conocidas de datos alfanuméricos que indiquen un intento de explotar una vulnerabilidad. La inspección de la carga útil permite a los operadores examinar tanto las cabeceras HTTP personalizadas como el cuerpo de una solicitud para detectar indicios específicos de actividad maliciosa. Para ello, el WAF debe almacenar primero todo el contenido de la solicitud. Esto es necesario porque los paquetes solo pueden contener una cantidad limitada de datos y, si los datos maliciosos abarcan dos paquetes, pueden pasar inadvertidos para los servicios que se limitan a inspeccionarlos uno por uno. Al examinar toda la carga útil, un WAF garantiza que, independientemente de dónde se encuentren los datos maliciosos, puedan detectarse y evitar que lleguen a su objetivo.

Un WAF puede hacer mucho más que mitigar vulnerabilidades para proteger las aplicaciones. Muchos también incluyen detección de bots, limitación de solicitudes, prevención de ataques DDoS y otras funciones. Sin embargo, el objetivo principal de un WAF es proteger las aplicaciones mediante la mitigación de vulnerabilidades. Aunque suelen mencionarse la inyección SQL (SQLi), el XSS y el CSRF, a estas alturas ya son problemas de sobra conocidos. Los actores maliciosos han dejado atrás las vulnerabilidades más evidentes de las aplicaciones y han empezado a atacar las plataformas porque ofrecen un conjunto mucho mayor de víctimas potenciales que explotar. Las vulnerabilidades de las plataformas —las presentes en HTTP y sus frameworks— son una fuente creciente de brechas de seguridad que pueden prevenirse gracias a la protección que ofrece un WAF de nivel empresarial.

Al combinar los métodos tradicionales de denegación/autorización y los análisis basados en firmas con la capacidad de inspeccionar una solicitud completa (y su respuesta), un WAF proporciona la protección que las empresas necesitan hoy en día para garantizar tanto su propia seguridad como la de sus clientes.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie