Introducción al Firewall de aplicaciones web de Citrix

El Web App Firewall de Citrix evita las brechas de seguridad, la pérdida de datos y las posibles modificaciones no autorizadas en los sitios web que acceden a información confidencial de la empresa o de los clientes. Para ello, filtra tanto las solicitudes como las respuestas, las examina en busca de indicios de actividad maliciosa y bloquea las solicitudes que muestran dicha actividad. Su sitio está protegido no solo contra los tipos de ataques más comunes, sino también contra ataques nuevos, aún desconocidos. Además de proteger los servidores web y los sitios web del acceso no autorizado, el Web App Firewall protege contra las vulnerabilidades en el código o los scripts CGI antiguos, los marcos web, el software de los servidores web y otros sistemas operativos subyacentes.

El Citrix Web App Firewall está disponible como dispositivo independiente o como función en un dispositivo virtual Citrix ADC (VPX). En la documentación de Web App Firewall, el término Citrix ADC hace referencia a la plataforma en la que se ejecuta el Web App Firewall, independientemente de si esa plataforma es un dispositivo de firewall dedicado, un Citrix ADC en el que también se han configurado otras funciones o un Citrix ADC VPX.

Para usar el Web App Firewall, debe crear al menos una configuración de seguridad para bloquear las conexiones que infrinjan las reglas que estableció para los sitios web protegidos. La cantidad de configuraciones de seguridad que desee crear depende de la complejidad de su sitio web. A veces, basta con una sola configuración. En otros casos, especialmente aquellos que incluyen sitios web interactivos, sitios web que acceden a servidores de bases de datos, almacenes en línea con carritos de compra, es posible que necesite varias configuraciones diferentes para proteger mejor los datos confidenciales sin desperdiciar un esfuerzo significativo en contenido que no es vulnerable a ciertos tipos de ataques. A menudo, puede dejar sin cambios los valores predeterminados de la configuración global, que afectan a todas las configuraciones de seguridad. Sin embargo, puede cambiar la configuración global si entra en conflicto con otras partes de la configuración o si prefiere personalizarla.

Seguridad de aplicaciones web

La seguridad de aplicaciones web es la seguridad de red para equipos y programas que se comunican mediante los protocolos HTTP y HTTPS. Se trata de un área amplia en la que abundan las fallas y debilidades de seguridad. Los sistemas operativos de los servidores y los clientes tienen problemas de seguridad y son vulnerables a los ataques. El software de servidor web y las tecnologías habilitadoras de sitios web, como CGI, Java, JavaScript, PERL y PHP, tienen vulnerabilidades subyacentes. Los navegadores y otras aplicaciones cliente que se comunican con aplicaciones habilitadas para la web también presentan vulnerabilidades. Los sitios web que utilizan cualquier tecnología que no sea el HTML más simple, incluido cualquier sitio que permita la interacción con los visitantes, suelen tener sus propias vulnerabilidades.

En el pasado, una violación de la seguridad solía ser solo una molestia, pero hoy en día rara vez es así. Por ejemplo, solían ser frecuentes los ataques en los que un pirata informático accedía a un servidor web y realizaba modificaciones no autorizadas en un sitio web (lo desfiguraba). Por lo general, los lanzaban piratas informáticos que no tenían ninguna motivación más allá de demostrar sus habilidades a otros piratas informáticos o avergonzar a la persona o empresa objetivo. Sin embargo, la mayoría de las brechas de seguridad actuales están motivadas por el deseo de dinero. La mayoría intenta lograr uno o ambos de los siguientes objetivos: obtener información privada confidencial y potencialmente valiosa, u obtener el acceso no autorizado y el control de un sitio web o servidor web.

Ciertas formas de ataques web se centran en obtener información privada. Estos ataques suelen ser posibles incluso contra sitios web que son lo suficientemente seguros como para evitar que un atacante tome el control total. La información que un atacante puede obtener de un sitio web puede incluir nombres de clientes, direcciones, números de teléfono, números de seguro social, números de tarjetas de crédito, registros médicos y otra información privada. A continuación, el atacante puede utilizar esta información o venderla a otros. Gran parte de la información obtenida mediante estos ataques está protegida por la ley, y toda por las costumbres y las expectativas. Una violación de este tipo puede tener graves consecuencias para los clientes cuya información privada se ve comprometida. En el mejor de los casos, estos clientes tienen que estar atentos para evitar que otros abusen de sus tarjetas de crédito, abran cuentas de crédito no autorizadas a su nombre o se apropien directamente de su identidad (robo de identidad). En el peor de los casos, es posible que los clientes se enfrenten a una mala calificación crediticia o incluso que se les culpe de actividades delictivas en las que no participaron.

Otros ataques web tienen como objetivo obtener el control de (o comprometer) un sitio web o el servidor en el que opera, o ambos. Un hacker que se haga con el control de un sitio web o un servidor puede utilizarlos para alojar contenido no autorizado, actuar como proxy del contenido alojado en otro servidor web, proporcionar servicios SMTP para enviar correo masivo no solicitado o proporcionar servicios de DNS para apoyar dichas actividades en otros servidores web comprometidos. La mayoría de los sitios web que están alojados en servidores web comprometidos promueven negocios cuestionables o abiertamente fraudulentos. Por ejemplo, la mayoría de los sitios web de suplantación de identidad y de explotación infantil están alojados en servidores web comprometidos.

Proteger sus sitios web y servicios web contra estos ataques requiere una defensa de varios niveles capaz de bloquear los ataques conocidos con características identificables y de proteger contra los ataques desconocidos, que a menudo se pueden detectar porque tienen un aspecto diferente al del tráfico normal de sus sitios web y servicios web.

Para obtener más información sobre las comprobaciones de seguridad, consulte Descripción general de las comprobaciones de seguridad.

Ataques web conocidos

La primera línea de defensa de sus sitios web es la protección contra la gran cantidad de ataques que se sabe que existen y que han sido observados y analizados por expertos en seguridad web. Los tipos más comunes de ataques contra sitios web basados en HTML incluyen:

• Ataques de desbordamiento de búfer. El envío de una URL larga, una cookie larga o información larga a un servidor web provoca que el sistema se bloquee, se bloquee o proporcione acceso no autorizado al sistema operativo subyacente. Se puede utilizar un ataque de desbordamiento de búfer para obtener acceso a información no autorizada, comprometer un servidor web o ambas cosas.
• Ataques de seguridad de cookies. Enviar una cookie modificada a un servidor web, normalmente con la esperanza de obtener acceso a contenido no autorizado mediante el uso de credenciales falsificadas.
• Navegación forzada. Acceder directamente a las URL de un sitio web, sin tener que ir a las URL con hipervínculos en la página principal ni a otras URL de inicio comunes en el sitio web. Los casos individuales de navegación forzada pueden indicar que un usuario ha marcado una página de tu sitio web como favorita, pero los intentos repetidos de acceder a contenido inexistente o al que los usuarios nunca deben acceder directamente suelen representar un ataque a la seguridad del sitio web. La navegación forzada normalmente se utiliza para acceder a información no autorizada, pero también se puede combinar con un ataque de desbordamiento de búfer para intentar comprometer el servidor.
• Ataques a la seguridad de formularios web. Envío de contenido inapropiado a su sitio web en un formulario web. El contenido inapropiado puede incluir campos ocultos modificados, HTML o código en un campo destinado únicamente a datos alfanuméricos, una cadena demasiado larga en un campo que solo acepta una cadena corta, una cadena alfanumérica en un campo que solo acepta un número entero y una gran variedad de otros datos que su sitio web no espera recibir en ese formulario web. Un ataque a la seguridad de un formulario web se puede utilizar para obtener información no autorizada de un sitio web o para poner en peligro el sitio web de forma directa, normalmente cuando se combina con un ataque de desbordamiento de búfer.

Dos tipos especializados de ataques a la seguridad de los formularios web merecen una mención especial:

• Ataques de inyección SQL. Enviar uno o varios comandos SQL activos en un formulario web o como parte de una URL, con el objetivo de hacer que una base de datos SQL ejecute el comando o los comandos. Los ataques de inyección de SQL se utilizan normalmente para obtener información no autorizada.
• Ataques de secuencias de comandos entre sitios. Usar una URL o un script en una página web es infringir la directiva del mismo origen, que prohíbe a cualquier script obtener propiedades de un sitio web diferente o modificarlo. Dado que los scripts pueden obtener información y modificar los archivos de un sitio web, permitir que un script acceda al contenido de otro sitio web puede proporcionar a un atacante los medios para obtener información no autorizada, comprometer un servidor web o ambas cosas.

Los ataques contra servicios web basados en XML normalmente se incluyen en al menos una de las dos categorías siguientes: intentos de enviar contenido inapropiado a un servicio web o intentos de infringir la seguridad de un servicio web. Los tipos más comunes de ataques contra los servicios web basados en XML incluyen:

• Código u objetos maliciosos. Solicitudes XML que contienen código u objetos que pueden obtener directamente información confidencial o dar a un atacante el control del servicio web o del servidor subyacente.
• Solicitudes XML mal formadas. Solicitudes XML que no se ajustan a la especificación XML del W3C y que, por lo tanto, pueden infringir la seguridad de un servicio web inseguro
• Ataques de denegación de servicio (DoS). Solicitudes XML que se envían repetidamente y en grandes volúmenes, con la intención de sobrecargar el servicio web objetivo y denegar a los usuarios legítimos el acceso al servicio web.

Además de los ataques estándar basados en XML, los servicios web XML y los sitios Web 2.0 también son vulnerables a los ataques de inyección de SQL y de secuencias de comandos entre sitios, como se describe a continuación:

• Ataques de inyección SQL. Enviar uno o más comandos SQL activos en una solicitud basada en XML, con el objetivo de hacer que una base de datos SQL ejecute ese comando o comandos. Al igual que con los ataques de inyección SQL HTML, los ataques de inyección SQL XML se utilizan normalmente para obtener información no autorizada.
• Ataques de secuencias de comandos entre sitios. El uso de un script incluido en una aplicación basada en XML infringe la directiva del mismo origen, que no permite que ningún script obtenga propiedades de ninguna aplicación diferente ni modifique ningún contenido de ella. Dado que los scripts pueden obtener información y modificar archivos mediante una aplicación XML, permitir que un script acceda al contenido que pertenece a otra aplicación puede proporcionar a un atacante los medios para obtener información no autorizada, comprometer la aplicación o ambas cosas.

Por lo general, los ataques web conocidos se pueden detener filtrando el tráfico del sitio web en función de características específicas (firmas) que siempre aparecen en un ataque específico y nunca deben aparecer en el tráfico legítimo. Este enfoque tiene las ventajas de requerir relativamente pocos recursos y presentar un riesgo relativamente bajo de falsos positivos. Por lo tanto, es una herramienta valiosa para combatir los ataques a sitios web y servicios web y configurar la protección básica de firmas.

Ataques web desconocidos

La mayor amenaza contra los sitios web y las aplicaciones no proviene de los ataques conocidos, sino de los ataques desconocidos. La mayoría de los ataques desconocidos se dividen en dos categorías: los ataques recién lanzados para los que las empresas de seguridad aún no han desarrollado una defensa eficaz (ataques de día cero) y los ataques dirigidos cuidadosamente a un sitio web o servicio web específico, en lugar de a muchos sitios web o servicios web (ataques con lanza). Estos ataques, al igual que los ataques conocidos, tienen por objeto obtener información privada confidencial, comprometer el sitio web o el servicio web y permitir que se utilice para otros ataques, o ambos objetivos.

Los ataques de día cero son una amenaza importante para todos los usuarios. Estos ataques suelen ser del mismo tipo que los ataques conocidos; los ataques de día cero suelen incluir SQL inyectado, un script entre sitios, una falsificación de solicitudes entre sitios u otro tipo de ataque similar a los ataques conocidos. Por lo general, se centran en vulnerabilidades que los desarrolladores del software, sitio web o servicio web objetivo desconocen o de las que se han enterado. Por lo tanto, las empresas de seguridad no han desarrollado defensas contra estos ataques y, aunque lo hayan hecho, los usuarios no han obtenido ni instalado los parches ni han adoptado las soluciones necesarias para protegerse contra estos ataques. El tiempo transcurrido entre el descubrimiento de un ataque de día cero y la disponibilidad de una defensa (la ventana de vulnerabilidad) se está reduciendo, pero los autores aún pueden contar con horas o incluso días en los que muchos sitios web y servicios web carezcan de una protección específica contra el ataque.

Los ataques con lanza son una amenaza importante, pero para un grupo más selecto de usuarios. Un tipo común de ataque con lanza, el spear phishing, se dirige a los clientes de un banco o institución financiera específicos o (con menos frecuencia) a los empleados de una empresa u organización específica. A diferencia de otros tipos de suplantación de identidad, que suelen ser falsificaciones escritas con crudeza que un usuario que esté familiarizado con las comunicaciones reales de ese banco o institución financiera puede reconocer, los spear phishes son perfectos y convincentes. Pueden contener información específica del individuo que, a primera vista, ningún extraño debe conocer o poder obtener. Por lo tanto, el suplantador de identidad puede convencer al objetivo de que proporcione la información solicitada, que luego puede utilizar para saquear cuentas, procesar dinero obtenido de forma ilegítima de otras fuentes o acceder a otra información aún más confidencial.

Ambos tipos de ataques tienen ciertas características que normalmente se pueden detectar, aunque no mediante el uso de patrones estáticos que busquen características específicas, como hacen las firmas estándar. La detección de este tipo de ataques requiere enfoques más sofisticados y que consumen más recursos, como el filtrado heurístico y los sistemas de modelos de seguridad positivos. El filtrado heurístico busca, no patrones específicos, sino patrones de comportamiento. Los sistemas con modelos de seguridad positivos modelan el comportamiento normal del sitio web o servicio web que protegen y, a continuación, bloquean las conexiones que no se ajustan a ese modelo de uso normal. Las comprobaciones de seguridad basadas en URL y formularios web perfilan el uso normal de sus sitios web y, a continuación, controlan la forma en que los usuarios interactúan con sus sitios web, utilizando tanto la heurística como la seguridad positiva para bloquear el tráfico anómalo o inesperado. Tanto la seguridad heurística como la seguridad positiva, si se diseñan e implementan correctamente, pueden detectar la mayoría de los ataques que las firmas no detectan. Sin embargo, requieren muchos más recursos que las firmas, y hay que dedicar algo de tiempo a configurarlas correctamente para evitar falsos positivos. Por lo tanto, no se utilizan como la principal línea de defensa, sino como copias de seguridad de las firmas u otros enfoques que consumen menos recursos.

Al configurar estas protecciones avanzadas además de las firmas, se crea un modelo de seguridad híbrido que permite que el Web App Firewall brinde una protección integral contra los ataques conocidos y desconocidos.

Cómo funciona el Firewall de aplicaciones web de Citrix

Al instalar el Web App Firewall, se crea una configuración de seguridad inicial, que consiste en una directiva, un perfil y un objeto de firmas. La directiva es una regla que identifica el tráfico que se va a filtrar y el perfil identifica los patrones y tipos de comportamiento que se permiten o bloquean cuando se filtra el tráfico. Los patrones más simples, que se denominan firmas, no se especifican en el perfil, sino en un objeto de firmas asociado al perfil.

Una firma es una cadena o un patrón que coincide con un tipo de ataque conocido. El Web App Firewall contiene más de mil firmas en siete categorías, cada una dirigida a ataques a tipos específicos de servidores web y contenido web. Citrix actualiza la lista con nuevas firmas a medida que se identifican nuevas amenazas. Durante la configuración, debe especificar las categorías de firmas adecuadas para los servidores web y el contenido que debe proteger. Las firmas proporcionan una buena protección básica con una baja sobrecarga de procesamiento. Si sus aplicaciones tienen vulnerabilidades especiales o detecta un ataque contra ellas para el que no existe ninguna firma, puede agregar sus propias firmas.

Las protecciones más avanzadas se denominan controles de seguridad. Una comprobación de seguridad es una inspección algorítmica más rigurosa de una solicitud para detectar patrones o tipos de comportamiento específicos que puedan indicar un ataque o constituir una amenaza para los sitios web y servicios web protegidos. Puede, por ejemplo, identificar una solicitud que intenta realizar un determinado tipo de operación que podría infringir la seguridad, o una respuesta que incluya información privada confidencial, como un número de seguro social o un número de tarjeta de crédito. Durante la configuración, debe especificar las comprobaciones de seguridad adecuadas para los servidores web y el contenido que debe proteger. Los controles de seguridad son restrictivos. Muchas de ellas pueden bloquear las solicitudes y respuestas legítimas si no agregas las excepciones (relajaciones) adecuadas al configurarlas. Identificar las excepciones necesarias no es difícil si utilizas la función de aprendizaje adaptativo, que sigue el uso normal de tu sitio web y crea excepciones recomendadas.

El Web App Firewall se puede instalar como un dispositivo de red de capa 3 o como un puente de red de capa 2 entre los servidores y los usuarios, normalmente detrás del enrutador o el firewall de la empresa. Debe instalarse en una ubicación donde pueda interceptar el tráfico entre los servidores web que quiere proteger y el hub o conmutador a través del cual los usuarios acceden a esos servidores web. A continuación, configure la red para enviar solicitudes al Web App Firewall en lugar de hacerlo directamente a sus servidores web, y las respuestas al Web App Firewall en lugar de hacerlo directamente a sus usuarios. El Web App Firewall filtra ese tráfico antes de reenviarlo a su destino final, utilizando tanto su conjunto de reglas internas como sus adiciones y modificaciones. Bloquea o hace inofensiva cualquier actividad que detecte como dañina y, a continuación, reenvía el tráfico restante al servidor web. La siguiente ilustración proporciona una descripción general del proceso de filtrado.

Nota:

La ilustración omite la aplicación de una directiva al tráfico entrante. Ilustra una configuración de seguridad en la que la directiva es procesar todas las solicitudes. Además, en esta configuración, se ha configurado y asociado un objeto de firmas con el perfil, y se han configurado comprobaciones de seguridad en el perfil.

Figura 1. Diagrama de flujo del filtrado del Web App Firewall

Como se muestra en la ilustración, cuando un usuario solicita una dirección URL en un sitio web protegido, el Web App Firewall examina primero la solicitud para asegurarse de que no coincide con una firma. Si la solicitud coincide con una firma, el Firewall de aplicaciones web de Citrix muestra el objeto de error (una página web ubicada en el dispositivo Web App Firewall y que puede configurar mediante la función de importación) o reenvía la solicitud a la URL de error designada (la página de error). Las firmas no requieren tantos recursos como las comprobaciones de seguridad, por lo que detectar y detener los ataques detectados por una firma antes de ejecutar cualquiera de las comprobaciones de seguridad reduce la carga en el servidor.

Si una solicitud supera la inspección de firmas, el Web App Firewall aplica las comprobaciones de seguridad de la solicitud que se han habilitado. Las comprobaciones de seguridad de la solicitud verifican que la solicitud es apropiada para su sitio web o servicio web y no contiene material que pueda representar una amenaza. Por ejemplo, las comprobaciones de seguridad examinan la solicitud de signos que indican que puede ser de un tipo inesperado, solicitar contenido inesperado o contener datos de formularios web inesperados y posiblemente malintencionados, comandos SQL o scripts. Si la solicitud no pasa una comprobación de seguridad, el Web App Firewall la desinfecta y, a continuación, la envía de vuelta al dispositivo Citrix ADC (o dispositivo virtual Citrix ADC) o muestra el objeto de error. Si la solicitud supera las comprobaciones de seguridad, se envía de nuevo al dispositivo Citrix ADC, que completa cualquier otro procesamiento y reenvía la solicitud al servidor web protegido.

Cuando el sitio web o el servicio web envían una respuesta al usuario, el Web App Firewall aplica las comprobaciones de seguridad de respuesta que se han habilitado. Las comprobaciones de seguridad de la respuesta examinan la respuesta para detectar filtraciones de información privada confidencial, señales de desfiguración del sitio web u otro contenido que no deba estar presente. Si la respuesta no pasa una comprobación de seguridad, el Web App Firewall elimina el contenido que no debe estar presente o bloquea la respuesta. Si la respuesta pasa las comprobaciones de seguridad, se envía de nuevo al dispositivo Citrix ADC, que la reenvía al usuario.

Funciones de Citrix Web Application Firewall

Las funciones básicas de Web App Firewall son directivas, perfiles y firmas, que proporcionan un modelo de seguridad híbrido tal como se describe en Ataques web conocidos, Ataques web desconocidosy Cómo funciona Web App Firewall. Cabe destacar la función de aprendizaje, que observa el tráfico de las aplicaciones protegidas y recomienda los ajustes de configuración adecuados para determinadas comprobaciones de seguridad.

La función de importaciones administra los archivos que se cargan en el Web App Firewall. A continuación, el Web App Firewall utiliza estos archivos en varias comprobaciones de seguridad o cuando responde a una conexión que coincide con una comprobación de seguridad.

Puede utilizar las funciones de registros, estadísticas e informes para evaluar el rendimiento del Web App Firewall e identificar las posibles necesidades de mayor protección.

Cómo el Firewall de aplicaciones web de Citrix modifica el tráfico de aplicaciones

El firewall de aplicaciones web de Citrix afecta al comportamiento de la aplicación web que protege al modificar lo siguiente:

• Cookies
• Encabezados HTTP
• Formularios/Datos

cookie de sesión de Citrix Web Application Firewall

Para mantener el estado de la sesión, Citrix ADC Web App Firewall genera su propia cookie de sesión. Esta cookie solo se pasa entre el explorador web y el Firewall de aplicaciones web Citrix ADC y no al servidor web. Si un pirata informático intenta modificar la cookie de sesión, Web App Firewall descarta la cookie antes de reenviar la solicitud al servidor y la trata como una nueva sesión de usuario. La cookie de sesión está presente mientras el explorador web esté abierto. Cuando se cierra el explorador web, la cookie de sesión de Application Firewall deja de ser válida. El estado de la sesión mantiene la información de las URL y los formularios visitados por el cliente.

La cookie de sesión configurable de Web App Firewall es citrix_ns_id.

A partir de las compilaciones 12.1 54 y 13.0 de Citrix ADC, la coherencia de las cookies no tiene sesión y no se exige agregar la cookie de sesión citrix_ns_id generada por el dispositivo. Para obtener más información sobre la configuración de las cookies, consulte Configuración del motor.

Cookies de Citrix Web App Firewall

Muchas aplicaciones web generan cookies para rastrear información específica del usuario o de la sesión. Esta información puede ser las preferencias del usuario o los artículos del carrito de compras. Una cookie de aplicación web puede ser de uno de los dos tipos siguientes:

• Cookies persistentes: Estas cookies se almacenan localmente en el equipo y se utilizan de nuevo la próxima vez que visite el sitio. Este tipo de cookie suele contener información sobre el usuario, como el inicio de sesión, la contraseña o las preferencias.
• Cookies de sesión o transitorias: Estas cookies se utilizan solo durante la sesión y se destruyen una vez finalizada la sesión. Este tipo de cookie contiene información sobre el estado de la aplicación, como los artículos del carrito de compras o las credenciales de sesión.

Los piratas informáticos pueden intentar modificar o robar las cookies de la aplicación para secuestrar una sesión de usuario o hacerse pasar por un usuario. El firewall de aplicaciones evita estos intentos al cifrar las cookies de la aplicación y, a continuación, agregar más cookies con las firmas digitales. Al rastrear las cookies, el Firewall de la aplicación garantiza que las cookies no se modifiquen ni se comprometan entre el navegador del cliente y el Firewall de la aplicación. El firewall de aplicaciones no modifica las cookies de la aplicación.

El Firewall de aplicaciones web de Citrix genera las siguientes cookies predeterminadas para rastrear las cookies de la aplicación:

• Cookies persistentes: citrix_ns_id_wlf. Nota: wlf significa vivirá para siempre.
• Cookies de sesión o transitorias: citrix_ns_id_wat. Nota: lo que significa actuará de forma transitoria. Para rastrear las cookies de la aplicación, el Firewall de aplicaciones agrupa las cookies de la aplicación persistentes o de sesión y, a continuación, codifica y firma todas las cookies juntas. Por lo tanto, el Firewall de aplicaciones genera una cookie wlf para rastrear todas las cookies persistentes de la aplicación y una cookie wat para rastrear todas las cookies de sesión de la aplicación.

La siguiente tabla muestra la cantidad y los tipos de cookies generadas por el Firewall de la aplicación en función de las cookies generadas por la aplicación web:

Citrix Web App Firewall permite cifrar la cookie de la aplicación. Application Firewall también ofrece la opción de enviar por proxy la cookie de sesión enviada por la aplicación, almacenándola con el resto de los datos de la sesión de Application Firewall y no enviándola al cliente. Cuando un cliente envía una solicitud a la aplicación que incluye una cookie de sesión de Application Firewall, Application Firewall vuelve a insertar la cookie enviada por la aplicación en la solicitud antes de enviarla a la aplicación de origen. El firewall de aplicaciones también permite agregar los indicadores HTTPOnly y/o Secure a las cookies.

Cómo afecta el firewall de la aplicación a los encabezados HTTP

Tanto las solicitudes HTTPs como las respuestas HTTPs utilizan encabezados para enviar información sobre uno o más mensajes de HTTP. Un encabezado es una serie de líneas en las que cada línea contiene un nombre seguido de dos puntos, un espacio y un valor. Por ejemplo, el encabezado Host tiene el siguiente formato:

Host: www.citrix.com

Algunos campos de encabezado se utilizan tanto en los encabezados de solicitud como en los de respuesta, mientras que otros solo son apropiados para una solicitud o una respuesta. El firewall de aplicaciones puede agregar, modificar o eliminar algunos encabezados de una o más solicitudes o respuestas HTTPs para mantener la seguridad de la aplicación.

El Firewall de aplicaciones web de Citrix ha eliminado los encabezados de las solicitudes

Muchos de los encabezados de solicitud relacionados con el almacenamiento en caché se eliminan para ver cada solicitud en el contexto de una sesión. Del mismo modo, si la solicitud incluye un encabezado de codificación para permitir que el servidor web envíe respuestas comprimidas, el Firewall de aplicaciones elimina este encabezado para que el Web App Firewall inspeccione el contenido de la respuesta del servidor sin comprimir para evitar cualquier filtración de datos confidenciales al cliente.

El firewall de aplicaciones elimina los siguientes encabezados de solicitud:

• Intervalo: se utiliza para recuperarse de una transferencia de archivos fallida o parcial.
• If-Range: permite a un cliente recuperar un objeto parcial cuando ya contiene una parte de ese objeto en su caché (GET condicional).
• If-Modified-Since: si el objeto solicitado no se modifica desde la hora especificada en este campo, el servidor no devuelve ninguna entidad. Aparece un error HTTP 304 no modificado.
• If-None-Match: permite actualizaciones eficientes de la información almacenada en caché con una sobrecarga mínima.
• Aceptar codificación: qué métodos de codificación están permitidos para un objeto determinado, como gzip.

Encabezado de solicitud modificado por el Firewall de aplicaciones web de Citrix

Si un explorador web usa los protocolos HTTP/1.0 o anteriores, el navegador abre y cierra continuamente la conexión del socket TCP después de recibir cada respuesta. Esto agrega sobrecarga al servidor web e impide mantener el estado de la sesión. El protocolo HTTP/1.1 permite que la conexión permanezca abierta durante la sesión. El Firewall de aplicaciones modifica el siguiente encabezado de solicitud para usar HTTP/1.1 entre el Firewall de la aplicación y el servidor web, independientemente del protocolo utilizado por el explorador web: Conexión: keep-alive

Encabezados de solicitud agregados por el Firewall de aplicaciones web de Citrix

El Firewall de aplicaciones actúa como un proxy inverso y reemplaza la dirección IP de origen original de la sesión por la dirección IP del Firewall de aplicaciones. Por lo tanto, todas las solicitudes registradas en el registro del servidor web indican que las solicitudes se envían desde el Firewall de la aplicación.

El Firewall de aplicaciones web de Citrix ha eliminado el encabezado de respuesta

El firewall de aplicaciones puede bloquear o modificar el contenido, por ejemplo, eliminar números de tarjetas de crédito o eliminar comentarios, y esto puede provocar una discordancia en el tamaño. Para evitar este caso, el Firewall de aplicaciones elimina el siguiente encabezado:

Longitud del contenido: indica el tamaño del mensaje enviado al destinatario. Encabezados de respuesta modificados por el firewall de la aplicación

Muchos de los encabezados de respuesta modificados por el Firewall de aplicaciones están relacionados con el almacenamiento en caché. Los encabezados del almacenamiento en caché de las respuestas HTTP (S) deben modificarse para obligar al explorador web a enviar siempre una solicitud al servidor web para obtener los datos más recientes y a no utilizar la memoria caché local. Sin embargo, algunas aplicaciones de ASP utilizan complementos independientes para mostrar contenido dinámico y pueden requerir la capacidad de almacenar los datos en caché temporalmente en el navegador. Para permitir el almacenamiento temporal de los datos en caché cuando las protecciones de seguridad avanzadas, como la FFC, el cierre de URL o las comprobaciones de CSRF, Application Firewall agrega o modifica los encabezados de control de caché en la respuesta del servidor mediante la siguiente lógica:

• Si el servidor envía Pragma: no-cache, el Firewall de la aplicación no realiza ninguna modificación.
• Si la solicitud del cliente es HTTP 1.0, Application Firewall inserta Pragma: no-cache.
• Si la solicitud de cliente es HTTP 1.1 y tiene el control de caché: sin almacenamiento, Application Firewall no realiza ninguna modificación.

• Si la solicitud del cliente es HTTP 1.1 y Server Response tiene un encabezado Cache-Control sin directiva de almacenamiento ni de caché, Application Firewall no realiza ninguna modificación.

• Si la solicitud del cliente es HTTP 1.1 y la respuesta del servidor no tiene ningún encabezado de control de caché o el encabezado de Cache-Control no tiene una directiva de almacenamiento o ausencia de caché, el firewall de aplicaciones realiza las siguientes tareas:

1. Inserta Cache-Control: max-age=3, must revalidate, private.
2. Inserta X-cache-Control-Orig = valor original del encabezado de Cache-Control.
3. Elimina el encabezado modificado por última vez.
4. Sustituye a Etag.
5. Inserta X-Expires-Orig=El valor original del encabezado de caducidad enviado por el servidor.
6. Modifica el encabezado de caducidad y establece la fecha de caducidad de la página web en el pasado, de modo que siempre se vuelva a consultar.
7. Modifica los rangos de aceptación y los establece en ninguno.

Para reemplazar los datos almacenados en caché temporalmente en el navegador del cliente cuando Application Firewall cambia la respuesta, por ejemplo, para StripComments, X-out/Remove SafeObject, xout o remove Credit Card o URL Transform, Application Firewall realiza las siguientes acciones:

1. Elimina la última modificación del servidor antes de reenviarla al cliente.
2. Reemplaza Etag por un valor determinado por Application Firewall.

Encabezados de respuesta agregados por el Citrix Web App Firewall

• Transfer-Encoding: En trozos. Este encabezado devuelve información a un cliente sin tener que conocer la longitud total de la respuesta antes de enviarla. Este encabezado es obligatorio porque se elimina el encabezado de longitud del contenido.
• Set-Cookie: Las cookies agregadas por el Firewall de la aplicación.
• Xet-Cookie: Si la sesión es válida y la respuesta no ha caducado en la memoria caché, puede servir desde la memoria caché y no es necesario enviar una cookie nueva porque la sesión sigue siendo válida. En tal caso, la cookie Set-Cookie se cambia a Xet-Cookie. Para el explorador web.

Cómo se ven afectados los datos del formulario

El firewall de aplicaciones protege contra los ataques que intentan modificar el contenido del formulario original enviado por el servidor. También puede proteger contra los ataques de falsificación de solicitudes entre sitios. El Firewall de aplicaciones lo hace insertando la etiqueta de formulario oculta as_fid en la página.

Ejemplo:<input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />

El campo oculto as_fid se utiliza para garantizar la coherencia del campo. Application Firewall utiliza este campo para rastrear todos los campos del formulario, incluidos los pares de nombre/valor de los campos ocultos, y para garantizar que ninguno de los campos del formulario enviados por el servidor cambie en el lado del cliente. La comprobación CSRF también utiliza esta etiqueta de formulario única as_fid para garantizar que los formularios enviados por el usuario se hayan entregado al usuario en esta sesión y que ningún pirata informático intente secuestrar la sesión del usuario.

Verificación de formularios sin sesión

El firewall de aplicaciones también ofrece una opción para proteger los datos de los formularios mediante la coherencia de campos sin sesión. Esto resulta útil para aplicaciones en las que los formularios pueden contener una gran cantidad de campos dinámicos ocultos, lo que hace que el firewall de aplicaciones asigne una gran cantidad de memoria por sesión. La comprobación de coherencia de los campos sin sesión se realiza insertando otro campo oculto como _ffc_field únicamente para las solicitudes POST o para las solicitudes GET y POST según la configuración configurada. El firewall de aplicaciones cambia el método GET a POST cuando reenvía el formulario al cliente. A continuación, el dispositivo invierte el método a GET al devolverlo al servidor. El valor as_ffc_field puede ser grande porque contiene el resumen cifrado del formulario que se está sirviendo. El siguiente es un ejemplo de la comprobación de formularios sin sesión:

<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />
<!--NeedCopy-->

Eliminación de comentarios HTML

El firewall de aplicaciones también ofrece la opción de eliminar todos los comentarios HTML de las respuestas antes de enviarlos al cliente. Esto afecta no solo a los formularios, sino a todas las páginas de respuesta. El firewall de aplicaciones localiza y elimina cualquier texto incrustado entre etiquetas de comentarios “<!-“ y “->”. Las etiquetas permanecen para indicar que existía un comentario en esa ubicación del código fuente HTML. Se ignora cualquier texto incrustado en cualquier otra etiqueta HTML o JavaScript. Es posible que algunas aplicaciones no funcionen correctamente si tienen JavaScript incrustado de forma incorrecta en las etiquetas de comentarios. Una comparación del código fuente de la página antes y después de que Application Firewall eliminara los comentarios puede ayudar a identificar si alguno de los comentarios eliminados tenía incrustado el JavaScript necesario.

Protección de tarjetas de crédito

El firewall de aplicaciones ofrece una opción para inspeccionar los encabezados y el cuerpo de la respuesta y eliminar o eliminar los números de las tarjetas de crédito antes de enviar la respuesta al cliente. Actualmente, Application Firewall ofrece protección para las siguientes tarjetas de crédito principales: American Express, Diners Club, Discover, JCB, MasterCard y Visa. La acción x-out funciona independientemente de la acción Bloquear.

Protección segura de objetos

Al igual que ocurre con los números de tarjetas de crédito, también se puede evitar la filtración de otros datos confidenciales mediante la comprobación de seguridad de objetos seguros de Application Firewall para eliminar o eliminar el contenido confidencial de la respuesta.

Las secuencias de comandos entre sitios transforman la acción

Cuando la transformación está habilitada para scripts entre sitios, Web App Firewall cambia "<" into "%26lt;" and ">" into "%26gt;" en las solicitudes. Si la configuración checkRequestHeaders del Web App Firewall está habilitada, el Web App Firewall inspecciona los encabezados de las solicitudes y también transforma estos caracteres en encabezados y cookies. La acción de transformación no bloquea ni transforma los valores enviados originalmente por el servidor. Hay un conjunto de atributos y etiquetas predeterminados para scripts entre sitios que permite Web App Firewall. También se proporciona una lista predeterminada de patrones de secuencias de comandos entre sitios denegados. Se pueden personalizar seleccionando el objeto de firmas y haciendo clic en el diálogo Administrar patrones de secuencias de comandos de SQL/Cross-Site de la GUI.

Transformación de caracteres especiales de SQL

Application Firewall tiene las siguientes reglas de transformación predeterminadas para los caracteres especiales de SQL:

Cuando la transformación de caracteres especiales está habilitada y el valor checkRequestHeaders está activado, la transformación de los caracteres especiales también se produce en los encabezados y las cookies. Nota: Algunos encabezados de solicitudes, como User-Agent y Accept-Encoding, suelen contener punto y coma y pueden verse afectados por la transformación de SQL.

Comportamiento del firewall de aplicaciones web de Citrix en el que corrompe el encabezado EXPECT

1. Cada vez que NetScaler recibe una solicitud HTTP con el encabezado EXPECT, NetScaler envía la respuesta EXPECT: 100 -continue al cliente en nombre del servidor de fondo.
2. Este comportamiento se debe a que las protecciones de Application Firewall deben ejecutarse en toda la solicitud antes de reenviarla al servidor; NetScaler debe obtener la solicitud completa del cliente.
3. Al recibir una respuesta 100 continue, el cliente envía la parte restante de la solicitud que completa la solicitud.
4. A continuación, NetScaler ejecuta todas las protecciones y, a continuación, reenvía la solicitud al servidor.
5. Ahora que NetScaler reenvía la solicitud completa, el encabezado EXPECT que se incluía en la solicitud inicial queda obsoleto y, como resultado, NetScaler corrompe este encabezado y lo envía al servidor.
6. El servidor al recibir la solicitud ignora cualquier encabezado que esté dañado.