Citrix ADC

Introducción a Citrix Web Application Firewall

Citrix Web App Firewall evita las infracciones de seguridad, la pérdida de datos y posibles modificaciones no autorizadas en sitios web que acceden a información confidencial del negocio o del cliente. Lo hace filtrando tanto las solicitudes como las respuestas, examinándolas en busca de evidencia de actividad maliciosa y bloqueando aquellas 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 servidores web y sitios web contra el acceso no autorizado y el uso indebido por parte de hackers y programas malintencionados, Web App Firewall proporciona protección contra vulnerabilidades de seguridad en códigos o scripts CGI heredados, otros marcos web, software de servidor web y los sistemas operativos subyacentes.

Citrix Web App Firewall está disponible como un dispositivo independiente o como una 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 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 quiera crear depende de la complejidad del sitio web. En algunos casos, 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, 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 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 extremadamente 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 permita 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 obtenía acceso a un servidor web e hizo modificaciones no autorizadas en un sitio web (desfigurado) 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 intenta lograr uno o ambos de los siguientes objetivos: Obtener información privada sensible y potencialmente valiosa, u obtener acceso y control no autorizados a un sitio web o servidor web.

Ciertas formas de ataques web se centran en obtener información privada. Estos ataques son a menudo posibles incluso contra sitios web que son lo suficientemente seguros 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 violación de este tipo puede tener consecuencias extremadamente graves para los clientes cuya información privada está comprometida. En el mejor de los casos, estos clientes tendrán 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 de (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 utilizarlo 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 dichas actividades en otros servidores web comprometidos. La mayoría de los sitios web alojados en servidores web comprometidos promueven negocios cuestionables o totalmente fraudulentos. Por ejemplo, la mayoría de los sitios web de phishing y los sitios web de explotación infantil están alojados en servidores web comprometidos.

La protección de sus sitios web y servicios web contra estos ataques requiere una defensa multicapa capaz de bloquear ataques conocidos con funciones identificables y proteger contra ataques desconocidos, que a menudo pueden detectarse porque tienen un aspecto diferente del tráfico normal a sus sitios web y servicios web.

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. Enviar una URL extremadamente larga, cookie extremadamente larga u otro bit de información extremadamente larga a un servidor web con la esperanza de causar que él o el sistema operativo subyacente se cuelguen, se bloqueen o proporcionen al atacante acceso 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 por medio de 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 simplemente indicar a 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, a menudo representan 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 el sitio web no utiliza. esperan 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 poner en peligro el sitio web directamente, normalmente 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 o comandos SQL activos 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 a cualquier script obtener propiedades o modificar 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 otro sitio web puede proporcionar a un 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 normalmente se pueden detener filtrando el tráfico del sitio web para buscar funciones específicas (firmas) que siempre aparecen para un ataque específico y que 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 los ataques en sitios web y servicios web, y configurar protecciones básicas de firma que interceptan la mayoría de los ataques web conocidos es fácil de hacer.

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 dividen en dos categorías: Ataques de reciente lanzamiento para los que 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 de lanza). Estos ataques, al igual que los ataques conocidos, suelen estar destinados a obtener información privada confidencial, comprometer el sitio web o el 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. En la mayoría de los casos, se dirigen a vulnerabilidades que los desarrolladores del software, sitio web o servicio web de destino no conocen o acaban de conocer. Por lo tanto, las empresas de seguridad generalmente no han desarrollado defensas contra estos ataques, e incluso si lo han hecho, los usuarios generalmente no han obtenido e instalado los parches ni han realizado las soluciones necesarias para protegerse contra estos ataques. El tiempo 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 perpetradores todavía 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 spear, un spear phish, generalmente 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 mal escritas que un usuario con cualquier familiaridad con las comunicaciones reales de ese banco o institución financiera puede reconocer, spear phishes escritas a la perfección y extremadamente convincentes. Pueden contener información específica del individuo que, a primera vista, ningún extraño debería conocer o ser capaz de obtener. Por lo tanto, el spear phisher es capaz de convencer a su objetivo de proporcionar la información solicitada, que el phisher puede utilizar para saquear cuentas, procesar dinero obtenido ilícitamente de otras fuentes, o para obtener acceso a otra información aún más delicada.

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 modelo de seguridad positiva modelan el comportamiento normal del sitio web o servicio web que están protegiendo y, a continuación, bloquean las conexiones que no se ajustan a ese modelo de uso normal. La seguridad basada en URL y en formularios web comprueba el uso normal del perfil de sus sitios web y, a continuación, controla 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, generalmente 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 puedan 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 figura proporciona una descripción general del proceso de filtrado.

Nota:

La figura 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

Diagrama de flujo de Web App Firewall

Como muestra la figura, cuando un usuario solicita una dirección URL en un sitio web protegido, 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 que se encuentra en el dispositivo Web App Firewall y que puede configurar mediante la función de importaciones) 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ía una respuesta al usuario, 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 degradación del sitio web u otro contenido que no debería estar presente. Si la respuesta falla en una comprobación de seguridad, Web App Firewall quita 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 como se describe en Ataques web conocidos, Ataques web desconocidos y Cómo funciona el 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 protecciones adicionales.

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

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.

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

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 podría ser las preferencias del usuario o los artículos del carrito de la compra. Una cookie de aplicación web puede ser uno de los dos tipos siguientes:

  • Cookies persistentes: Estas cookies se almacenan localmente en el ordenador 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 duración de la sesión y se destruyen después de que la sesión se termina. 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 mediante el hashing de las cookies de la aplicación y luego la adición de cookies adicionales 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.

Web App Firewall siempre genera una cookie de sesión de Application Firewall independientemente de si la aplicación web genera alguna cookie.

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:

Antes de Citrix ADC Web App Firewall Hasta
Sin cookies Cookie de sesión: Citrix_ns_id
Una cookie persistente Cookie de sesión: Citrix_ns_id
Dos cookies persistentes Dos cookies persistentes originales de la aplicación. Cookie de sesión: Citrix_ns_id, cookie persistente: Citrix_ns_id_wlf
Una cookie persistente, una cookie transitoria Una cookie persistente original de la aplicación. Una cookie de sesión original de la aplicación. Cookie de sesión: Citrix_ns_id, Cookie persistente:citrix_ns_id_wlf, Cookie transitoria:citix_ns_id_wat

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 HTTP (s) como las respuestas HTTP (s) utilizan encabezados para enviar información sobre el mensaje HTTP (s). 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 la solicitud o respuesta HTTP para mantener la seguridad de la aplicación.

Encabezados de solicitud eliminados por Citrix Web Application Firewall

Es posible que Application Firewall descarte muchos de los encabezados de solicitud relacionados con el almacenamiento en caché 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, Application Firewall elimina este encabezado para que Application Firewall pueda inspeccionar el contenido de la respuesta del servidor sin comprimir 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 Application Firewall.

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 este caso, Application Firewall deja caer el encabezado siguiente:

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:no-cache, entonces el firewall de aplicaciones no realiza ninguna modificación.
  • Si Solicitud de cliente es HTTP 1.0, entonces Application Firewall 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, por lo que siempre se vuelve a recoger.
  7. Modifica Accept-Ranges y lo establece en ninguno.

Para reemplazar 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 remove Card o URL Transform, 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 está caducada en la caché, entonces puede servir desde la caché y no tiene que 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, Xet-Cookie es similar a cualquier otro encabezado personalizado.

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 logra esto 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==" />

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

Application Firewall 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.

Acción de transformación XSS

Cuando la transformación está habilitada para XSS, Application Firewall cambia"<" into "%26lt;" and ">" into "%26gt;" en las solicitudes. Si está habilitada la opción CheckRequesTheaders en Application Firewall, el firewall de aplicación inspecciona los encabezados de solicitud y también transforma estos caracteres en Encabezado 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 XSS permitidos por Application Firewall. También se proporciona una lista predeterminada de patrones XSS denegados. Estos se pueden personalizar seleccionando el objeto de firmas y haciendo clic en el diálogo Administrar patrones SQL/XSS en la interfaz gráfica de usuario.

Transformación de caracteres especiales SQL

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

De Hasta Transformación
‘(comillas simples, es decir, %27) Otra cita sencilla
\ (barra invertida que es%5C) |Se agregó otra barra invertida  
; (punto y coma que es%3B)   Se cayó

Cuando la transformación de caracteres especiales está habilitada y CheckRequesTheaders se establece en ON, entonces la transformación de caracteres especiales ocurre también en Encabezados y cookies. 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 Firewall de aplicaciones web de Cirix en el que corrompe el encabezado de

  1. Cada vez que NetScaler recibe una solicitud HTTP con el encabezado ESPECT en ella, NetScaler envía la respuesta ESPECT: 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 necesita obtener toda la solicitud del cliente.
  3. En la recepción de 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, a medida que NetScaler está reenviando el encabezado de solicitud completa ESPECT 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.

Introducción a Citrix Web Application Firewall