Introducción a Citrix Web Application Firewall

Citrix Web App Firewall evita infracciones de seguridad, pérdida de datos y posibles modificaciones no autorizadas en sitios web que acceden a información confidencial de negocios o clientes. Lo hace filtrando tanto las solicitudes como las respuestas, examinándolas en busca de pruebas de actividad maliciosa y bloqueando las solicitudes que exhiben dicha actividad. Su sitio está protegido no solo de tipos comunes de ataques, sino también de ataques nuevos, aún desconocidos. Además de proteger los servidores web y sitios web del acceso no autorizado, Web App Firewall protege contra vulnerabilidades en códigos o scripts CGI heredados, marcos web, software de servidor web y otros sistemas operativos subyacentes.

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 Web App Firewall, independientemente de si esa plataforma es un dispositivo de firewall dedicado, un ADC de Citrix en el que también se han configurado otras funciones o un dispositivo Citrix ADC VPX.

Para utilizar el Web App Firewall, debe crear al menos una configuración de seguridad para bloquear las conexiones que infrinjan las reglas establecidas para los sitios web protegidos. El número de configuraciones de seguridad que puede desear crear depende de la complejidad de su sitio web. A veces, una sola configuración es suficiente. En otros casos, especialmente aquellos que incluyen sitios web interactivos, sitios web que acceden a servidores de bases de datos, almacéns 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 entran 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 ámbito amplio en el que abundan los defectos y debilidades de seguridad. Los sistemas operativos tanto en servidores como en clientes tienen problemas de seguridad y son vulnerables a 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 exploradores y otras aplicaciones cliente que se comunican con aplicaciones habilitadas para Web también tienen vulnerabilidades. Los sitios web que utilizan cualquier tecnología pero la más simple de HTML, incluyendo cualquier sitio que permite la interacción con los visitantes, a menudo tienen vulnerabilidades propias.

En el pasado, una violación de la seguridad era a menudo solo una molestia, pero hoy en día no es así. Por ejemplo, los ataques en los que un hacker obtuvo acceso a un servidor web e hizo modificaciones no autorizadas (desfiguradas) en un sitio web solían ser comunes. Por lo general, eran lanzados por hackers que no tenían más motivación que demostrar sus habilidades a compañeros hackers o avergonzar a la persona o empresa objetivo. Sin embargo, la mayoría de las infracciones de seguridad actuales están motivadas por el deseo de dinero. La mayoría trata de lograr uno o ambos de los siguientes objetivos: obtener información privada sensible y potencialmente valiosa, u obtener acceso no autorizado y control de un sitio web o servidor web.

Ciertas formas de ataques web se centran en obtener información privada. Estos ataques a menudo son 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 seguridad social, números de tarjetas de crédito, registros médicos y otra información privada. El atacante puede utilizar esta información o venderla a otros. Gran parte de la información obtenida por tales ataques está protegida por la ley, y toda por la costumbre y la expectativa. Una infracción de este tipo puede tener graves consecuencias para los clientes cuya información privada se vea comprometida. En el mejor de los casos, estos clientes tienen que ejercer vigilancia para evitar que otros abusen de sus tarjetas de crédito, abran cuentas de crédito no autorizadas a su nombre o se apropien de sus identidades (robo de identidad). En el peor de los casos, los clientes pueden enfrentar calificaciones crediticias arruinadas o incluso ser culpados por actividades delictivas en las que no tenían parte.

Otros ataques web tienen como objetivo obtener el control (o comprometer) un sitio web o el servidor en el que opera, o ambos. Un hacker que obtenga el control de un sitio web o servidor puede usarlo para alojar contenido no autorizado, actuar como proxy para contenido alojado en otro servidor web, proporcionar servicios SMTP para enviar correo electrónico masivo no solicitado o proporcionar servicios DNS para apoyar tales actividades en otros servidores web comprometidos. La mayoría de los sitios web alojados en servidores web comprometidos promueven negocios cuestionables o completamente fraudulentos. Por ejemplo, la mayoría de los sitios web de phishing y los sitios web de explotación infantil se alojan en servidores web comprometidos.

Proteger sus sitios web y servicios web contra estos ataques requiere una defensa multicapa capaz de bloquear ataques conocidos con funciones identificables y protegerse contra ataques desconocidos, que a menudo se pueden detectar porque se ven diferentes del tráfico normal a sus sitios web y sitios web servicios.

Ataques web conocidos

La primera línea de defensa para sus sitios web es la protección contra el gran número de ataques que se sabe que existen y que han sido observados y analizados por expertos en seguridad web. Los tipos 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 hace que el sistema se bloquee, 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, poner en peligro un servidor web o ambos.
• Ataques de seguridad de cookies. Enviar una cookie modificada a un servidor web, generalmente con la esperanza de obtener acceso a contenido no autorizado mediante el uso de credenciales falsificadas.
• Exploración forzada. Acceder directamente a las URL de un sitio web, sin navegar a las URL con hipervínculos en la página principal u otras URL de inicio comunes en el sitio web. Las instancias individuales de navegación forzosa pueden indicar un usuario que marcó una página en su sitio web, pero los intentos repetidos de acceder a contenido inexistente o contenido al que los usuarios nunca deben acceder directamente, suelen representar un ataque a la seguridad del sitio web. La navegación forzada se utiliza normalmente para obtener acceso a información no autorizada, pero también se puede combinar con un ataque de desbordamiento de búfer en un intento de comprometer su servidor.
• Ataques de seguridad de formularios web. Enviar 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 acepta solo una cadena corta, una cadena alfanumérica en un campo que acepta solo un entero y una amplia variedad de otros datos que su sitio web no espera recibir en ese formulario web. Un ataque de seguridad de formularios web se puede utilizar para obtener información no autorizada de su sitio web o para comprometer el sitio web directamente, generalmente cuando se combina con un ataque de desbordamiento de búfer.

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

• Ataques de inyección SQL. Enviar un comando SQL activo o comandos en un formulario web o como parte de una dirección URL, con el objetivo de hacer que una base de datos SQL ejecute el comando o comandos. Los ataques de inyección SQL se utilizan normalmente para obtener información no autorizada.
• Ataques de scripts entre sitios. Usar una URL o un script en una página web para infringir la directiva del mismo origen, que prohíbe que cualquier script obtenga propiedades o modifique cualquier contenido de un sitio web diferente. Dado que los scripts pueden obtener información y modificar archivos en su sitio web, permitir que un script acceda al contenido de un sitio web diferente puede proporcionar al atacante los medios para obtener información no autorizada, poner en peligro un servidor web o ambos.

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

• Código u objetos malintencionados. Solicitudes XML que contienen código u objetos que pueden obtener directamente información confidencial o que pueden proporcionar 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 de W3C y que, por lo tanto, pueden violar la seguridad en un servicio web inseguro
• Ataques de denegación de servicio (DoS). Solicitudes XML que se envían repetidamente y en gran volumen, con la intención de abrumar el servicio web de destino y denegar a los usuarios legítimos el acceso al servicio web.

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

• Ataques de inyección SQL. Envío de un comando SQL activo o comandos 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 HTML SQL, los ataques de inyección XML SQL se utilizan normalmente para obtener información no autorizada.
• Ataques de scripts entre sitios. Usar un script incluido en una aplicación basada en XML para infringir la directiva del mismo origen, que no permite que ningún script obtenga propiedades de ni modifique ningún contenido de una aplicación diferente. Dado que los scripts pueden obtener información y modificar archivos mediante la aplicación XML, permitir que un script acceda al contenido que pertenece a una aplicación diferente puede proporcionar a un atacante los medios para obtener información no autorizada, poner en peligro la aplicación o ambos

Los ataques web conocidos generalmente se pueden detener filtrando el tráfico del sitio web para obtener funciones específicas (firmas) que siempre aparecen para 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 relativamente poco riesgo de falsos positivos. Por lo tanto, es una herramienta valiosa para combatir ataques a sitios web y servicios web, y configurar la protección básica de firmas.

Ataques web desconocidos

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

Los ataques de día cero son una amenaza importante para todos los usuarios. Estos ataques suelen ser de los mismos tipos que los ataques conocidos; los ataques de día cero suelen involucrar SQL inyectado, un script entre sitios, una falsificación de solicitud entre sitios u otro tipo de ataque similar a los ataques conocidos. Por lo general, se dirigen a vulnerabilidades que los desarrolladores del software, sitio web o servicio web de destino no conocen o que han aprendido. Por lo tanto, las empresas de seguridad no han desarrollado defensas contra estos ataques, e incluso si lo han hecho, los usuarios no han obtenido e instalado los parches ni han realizado 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 carecen de protección específica contra el ataque.

Los ataques con lanza son una amenaza importante, pero para un grupo de usuarios más selectos. Un tipo común de ataque con lanza, un phishes de lanza, está dirigido a clientes de un banco o institución financiera específico, o (menos comúnmente) a empleados de una empresa u organización específica. A diferencia de otros phishes, que a menudo son falsificaciones crudamente escritas que un usuario con alguna familiaridad con las comunicaciones reales de ese banco o institución financiera puede reconocer, los phishes lanza son letras perfectas y convincentes. Pueden contener información específica del individuo que, a primera vista, ningún extraño debe conocer o ser capaz de obtener. Por lo tanto, el phisher de lanza es capaz de convencer al objetivo de que proporcione la información solicitada, que el phisher puede utilizar para saquear cuentas, procesar dinero obtenido ilegalmente de otras fuentes, o para obtener acceso a otra información, incluso más sensible.

Ambos tipos de ataques tienen ciertas funciones que normalmente se pueden detectar, aunque no mediante el uso de patrones estáticos que buscan funciones específicas, al igual que las firmas estándar. La detección de estos tipos de ataques requiere enfoques más sofisticados e intensivos en recursos, como el filtrado heurístico y sistemas de modelos de seguridad positivos. El filtrado heurístico se ve, no para patrones específicos, sino para patrones de comportamientos. Los sistemas de 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 encajan en ese modelo de uso normal. Las comprobaciones de seguridad basadas en URL y en formularios web perfilan el uso normal de sus sitios web y, a continuación, controlan cómo interactúan los usuarios con sus sitios web, mediante tanto heurística como seguridad positiva para bloquear el tráfico anómalo o inesperado. Tanto la seguridad heurística como la positiva, diseñada e implementada correctamente, pueden capturar la mayoría de los ataques que las firmas pierden. Sin embargo, requieren mucho más recursos que las firmas, y debe pasar algún tiempo configurándolas correctamente para evitar falsos positivos. Por lo tanto, se utilizan, no como la línea principal de defensa, sino como copias de seguridad de firmas u otros enfoques menos intensivos en recursos.

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

Cómo funciona Citrix Web Application Firewall

Al instalar Web App Firewall, se crea una configuración de seguridad inicial, que consta de 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 deben permitir o bloquear cuando se filtra el tráfico. Los patrones más simples, que se denominan firmas, no se especifican dentro del perfil, sino en un objeto signatures asociado al perfil.

Una firma es una cadena o 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 contra 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, especifique las categorías de firmas adecuadas para los servidores web y el contenido que necesita 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 comprobaciones de seguridad. Una comprobación de seguridad es una inspección algorítmica más rigurosa de una solicitud de patrones o tipos de comportamiento específicos que podrían indicar un ataque o constituir una amenaza para sus sitios web y servicios web protegidos. Puede, por ejemplo, identificar una solicitud que intente 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 seguridad social o un número de tarjeta de crédito. Durante la configuración, especifique las comprobaciones de seguridad adecuadas para los servidores web y el contenido que necesita proteger. Los controles de seguridad son restrictivos. Muchos de ellos pueden bloquear solicitudes y respuestas legítimas si no agrega las excepciones apropiadas (relajaciones) al configurarlas. Identificar las excepciones necesarias no es difícil si utiliza la función de aprendizaje adaptativo, que observa el uso normal de su 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 sus servidores y sus usuarios, generalmente detrás del enrutador o firewall de su empresa. Debe instalarse en una ubicación donde pueda interceptar el tráfico entre los servidores web que quiere proteger y el concentrador 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 directamente a los servidores web, y las respuestas al Web App Firewall en lugar de directamente a los usuarios. El Web App Firewall filtra ese tráfico antes de reenviarlo a su destino final, mediante 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.

Ilustración 1. Un diagrama de flujo de filtrado de 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, Citrix Web Application Firewall 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 dirección 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 pasa la inspección de firma, Web App Firewall aplica las comprobaciones de seguridad de solicitud que se han habilitado. Las comprobaciones de seguridad de la solicitud verifican que la solicitud es adecuada 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 falla en una comprobación de seguridad, Web App Firewall desinfecta la solicitud y, a continuación, la envía al dispositivo Citrix ADC (o al 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 respuesta examinan la respuesta en busca de fugas de información privada confidencial, signos de defacción del sitio web u otro contenido que no debe estar presente. Si la respuesta falla una comprobación de seguridad, 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 importación administra los archivos que se cargan en 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 posibles necesidades de más protecciones.

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

Citrix Web Application Firewall afecta al comportamiento de una aplicación web que protege al modificar lo siguiente:

• Cookies
• Encabezados de 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 se transfiere únicamente entre el explorador web y el Firewall de aplicaciones web de Citrix ADC y no al servidor web. Si algún pirata informático intenta modificar la cookie de sesión, Application Firewall descarta la cookie antes de reenviar la solicitud al servidor y trata la solicitud 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 pasa a ser válida. El estado de la sesión mantiene la información de las URL y formularios visitados por el cliente.

La cookie de sesión configurable de Web App Firewall escitrix_ns_id.

A partir de la compilación 12.1 54 y 13.0 de Citrix ADC, la consistencia de las cookies no tiene sesión y no impone la adición de cookies de sesión citrix_ns_id generada por el dispositivo.

Cookies de Citrix Web App Firewall

Muchas aplicaciones web generan cookies para realizar un seguimiento de la información específica del usuario o de la sesión. Esta información puede ser preferencias del usuario o artículos del carrito de compras. Una cookie de aplicación web puede ser 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 generalmente contiene información sobre el usuario, como inicio de sesión, contraseña o preferencias.
• Cookies de sesión o transitorias - Estas cookies se utilizan solo durante la sesión y se destruyen después de que finalice la sesión. Este tipo de cookie contiene información sobre el estado de la aplicación, como elementos del carrito de compras o credenciales de sesión.

Los hackers pueden intentar modificar o robar cookies de aplicaciones para secuestrar una sesión de usuario o hacerse pasar por un usuario. El Firewall de aplicaciones evita tales intentos con la ayuda del hash de las cookies de aplicación y al agregar más cookies con las firmas digitales. Mediante el seguimiento de las cookies, Application Firewall garantiza que las cookies no se modifiquen o comprometan entre el explorador del cliente y el Application Firewall. El firewall de aplicaciones no modifica las cookies de la aplicación.

Citrix Web Application Firewall genera las siguientes cookies predeterminadas para realizar un seguimiento de las cookies de la aplicación:

• Cookies persistentes:citrix_ns_id_wlf. Nota: Wlf significa que vivirá para siempre.
• Cookies de sesión o transitorias:citrix_ns_id_wat. Nota: Wat significa actuará de forma transitoria. Para realizar un seguimiento de las cookies de aplicación, Application Firewall agrupa las cookies de aplicación persistentes o de sesión juntas y, a continuación, hash y firmar todas las cookies juntas. Por lo tanto, Application Firewall genera unawlf cookie para rastrear todas las cookies de aplicación persistentes y unawat cookie para rastrear todas las cookies de sesión de aplicaciones.

La siguiente tabla muestra el número y los tipos de cookies generadas por el Firewall de aplicaciones 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 proporciona una opción para proxy de la cookie de sesión enviada por la aplicación, almacenándola con el resto de los datos de 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 inserta la cookie enviada de nuevo en la solicitud antes de enviar la solicitud a la aplicación de origen. Application Firewall también permite agregar las banderas 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 HTTPs. Un encabezado es una serie de líneas con cada línea que contiene un nombre seguido de dos puntos y 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 encabezados de respuesta, mientras que otros son apropiados solo para una solicitud o una respuesta. El Firewall de aplicaciones puede agregar, modificar o eliminar algunos encabezados en una o más solicitudes o respuestas HTTPS para mantener la seguridad de la aplicación.

Encabezados de solicitud eliminados por Citrix Web Application Firewall

Muchos de los encabezados de solicitud relacionados con el almacenamiento en caché se eliminan para ver cada solicitud dentro del 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 no comprimido para evitar cualquier fuga de datos confidenciales al cliente.

Application Firewall elimina los siguientes encabezados de solicitud:

• Rango: Se utiliza para recuperarse de transferencias parciales o fallidas de archivos.
• 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 el tiempo especificado en este campo, no se devuelve una entidad desde el servidor. Obtiene un error HTTP 304 no modificado.
• If-None-Match: Permite actualizaciones eficientes de la información almacenada en caché con una cantidad mínima de sobrecarga.
• Accept-Encoding: Qué métodos de codificación están permitidos para un objeto concreto, como gzip.

Encabezado de solicitud modificado por Citrix Web Application Firewall

Si un explorador web utiliza los protocolos HTTP/1.0 o anteriores, el explorador abre y cierra continuamente la conexión de 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. Application Firewall modifica el siguiente encabezado de solicitud para utilizar HTTP/1.1 entre Application Firewall y el servidor web, independientemente del protocolo utilizado por el explorador web: Connection: Keep-alive

Encabezados de solicitud agregados por Citrix Web Application Firewall

Application Firewall 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 Application Firewall. Por lo tanto, todas las solicitudes registradas en el registro del servidor web indican que las solicitudes se envían desde el Firewall de aplicaciones.

Encabezado de respuesta eliminado por Citrix Web Application Firewall

El firewall de aplicaciones puede bloquear o modificar contenido, como eliminar números de tarjetas de crédito o eliminar comentarios, lo que puede dar lugar a una discordancia de tamaño. Para evitar tal caso, Application Firewall descarta el siguiente encabezado:

Content-Length: Indica el tamaño del mensaje enviado al destinatario. Encabezados de respuesta modificados por el firewall de aplicaciones

Muchos de los encabezados de respuesta modificados por Application Firewall están relacionados con el almacenamiento en caché. Los encabezados de almacenamiento en caché en las respuestas HTTP (S) deben modificarse para forzar al explorador web a enviar siempre una solicitud al servidor web para obtener los datos más recientes y no utilizar la caché local. Sin embargo, algunas aplicaciones ASP utilizan complementos independientes para mostrar contenido dinámico y pueden requerir la capacidad de almacenar en caché los datos temporalmente en el explorador. Para permitir el almacenamiento en caché temporal de datos cuando se habilitan protecciones de seguridad avanzada, como FFC, cierre de URL o comprobaciones 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: sin caché, entonces Application Firewall no realiza ninguna modificación.
• Si Solicitud de cliente es HTTP 1.0, el Firewall de aplicaciones inserta Pragma: no-cache.
• Si Solicitud de cliente es HTTP 1.1 y tiene Caché Control: No-store, entonces Application Firewall no realiza ninguna modificación.

• Si Solicitud de cliente es HTTP 1.1 y Respuesta del servidor tiene encabezado Cache-Control sin almacén o sin directiva de caché, entonces Application Firewall no realiza ninguna modificación.

• Si la solicitud de cliente es HTTP 1.1 y la respuesta del servidor no tiene encabezado de control de caché o el encabezado Cache-Control no tiene ninguna directiva de almacén o no-caché, el firewall de aplicación completa las siguientes tareas:

1. Inserta cache-control: Max-age=3, debe revalidar, privado.
2. Inserta X-cache-control-ORIG = valor original del encabezado Cache-Control.
3. Elimina el encabezado Last-Modified.
4. Sustituye a Etag.
5. Inserta X-Expires-Orig=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 recoja de nuevo.
7. Modifica Accept-Ranges y lo establece en ninguno.

Para reemplazar los datos almacenados temporalmente en caché en el explorador del cliente cuando Application Firewall cambia la respuesta como, por ejemplo, para StripComments, X-out/Remove SafeObject, xout o quitar tarjeta de crédito o transformación de URL, Application Firewall realiza las siguientes acciones:

1. Elimina Last-Modified del servidor antes de reenviarlo al cliente.
2. Reemplaza a Etag por un valor determinado por Application Firewall.

Encabezados de respuesta agregados por Citrix Web App Firewall

• Transfer-Encoding: En trozos. Este encabezado transmite información a un cliente sin tener que conocer la longitud total de la respuesta antes de enviar la respuesta. Este encabezado es obligatorio porque se elimina el encabezado de longitud de contenido.
• Set-Cookie: Las cookies agregadas por el firewall de aplicaciones.
• Xet-Cookie: si la sesión es válida y si la respuesta no ha caducado en caché, puede servir desde caché y no es necesario enviar una nueva cookie porque la sesión sigue siendo válida. En tal caso, el 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 ataques que intentan modificar el contenido del formulario original enviado por el servidor. También puede proteger contra ataques de falsificación de solicitudes entre sitios. El Firewall de aplicaciones se logra 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 la consistencia del campo. Application Firewall utiliza este campo para realizar un seguimiento de todos los campos del formulario, incluidos los pares de nombre/valor de campo oculto y para garantizar que ninguno de los campos del formulario enviado por el servidor se cambie en el lado del cliente. La comprobación CSRF también utiliza esta etiqueta de formulario única as_fid para asegurarse de que los formularios enviados por el usuario fueron servidos al usuario en esta sesión y ningún pirata informático está intentando secuestrar la sesión del usuario.

Comprobación de formularios sin sesión

Application Firewall también ofrece una opción para proteger los datos del formulario mediante la consistencia de campos sin sesión. Esto resulta útil para aplicaciones en las que los formularios pueden tener un gran número de campos ocultos dinámicos que conducen a una asignación alta de memoria por sesión por parte del firewall de aplicaciones. La comprobación de consistencia de campos sin sesión se logra insertando otro campo oculto as_ffc_field solo para solicitudes POST o para solicitudes GET y POST en función de 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 revierte el método a GET al enviarlo de vuelta al servidor. El valor as_ffc_field puede ser grande porque contiene el resumen cifrado del formulario que se sirve. El siguiente es un ejemplo de la comprobación de formulario 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-->

Despojado de comentarios HTML

Application Firewall también ofrece la opción de quitar todos los comentarios HTML en las respuestas antes de enviarlos al cliente. Esto afecta no solo a los formularios, sino a todas las páginas de respuesta. Application Firewall localiza y elimina cualquier texto incrustado entre “<!-“ y “->” etiquetas de comentario. Las etiquetas permanecen para indicar que existía un comentario en esa ubicación del código fuente HTML. Cualquier texto incrustado en cualquier otra etiqueta HTML o JavaScript se ignora. Es posible que algunas aplicaciones no funcionen correctamente si tienen JavaScript incorrectamente incrustado en las etiquetas de comentario. 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 el JavaScript requerido incrustado en ellos.

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 elimina o elimina los números de la tarjeta de crédito antes de reenviar 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 de salida x funciona independientemente de la acción Bloquear.

Protección segura de objetos

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

La acción de scripts entre sitios transforma

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 CheckRequestTheaders en el Web App Firewall está habilitada, el Web App Firewall inspecciona los encabezados de solicitud y transforma estos caracteres en Encabezado y cookies también. 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 scripts entre sitios denegados. Estos se pueden personalizar seleccionando el objeto de firmas y haciendo clic en el cuadro de diálogo Administrar patrones de scripting SQL/Cross Site en la GUI.

Transformación de caracteres especiales SQL

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

Cuando la transformación de caracteres especiales está habilitada y CheckRequestTheaders se establece en ON, entonces la transformación de caracteres especiales ocurre en Encabezados y cookies también. Nota: Algunos encabezados de solicitud como User-Agent, Accept-Encoding generalmente contienen punto y coma y pueden verse afectados por la transformación SQL.

Comportamiento de Citrix Web Application Firewall en el que corrompe el encabezado ESPERE

1. Siempre que NetScaler recibe una solicitud HTTP con el encabezado EXPECT en ella, NetScaler envía la respuesta EXPECT: 100 -continue al cliente en nombre del servidor back-end.
2. Este comportamiento se debe a que las protecciones de Application Firewall deben ejecutarse en toda la solicitud antes de reenviar la solicitud al servidor, NetScaler debe obtener la solicitud completa del cliente.
3. Al recibir una 100 continue respuesta, el cliente envía la parte restante de la solicitud que completa la solicitud.
4. NetScaler ejecuta todas las protecciones y, a continuación, reenvía la solicitud al servidor.
5. Ahora, como NetScaler está reenviando la solicitud completa, el encabezado EXPECT que vino en la solicitud inicial se vuelve obsoleto, 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.