Función de streaming para el procesamiento de solicitudes
Citrix Web App Firewall admite la transmisión en el lado de solicitudes para proporcionar un aumento significativo del rendimiento. En lugar de almacenar en búfer una solicitud, el dispositivo examina el tráfico entrante en busca de infracciones de seguridad, como SQL, scripts entre sitios, consistencia de campos y formatos de campo. Cuando el dispositivo completa el procesamiento de datos de un campo, la solicitud se reenvía al servidor back-end mientras el dispositivo continúa evaluando otros campos. Este procesamiento de datos mejora significativamente el tiempo de procesamiento en formularios de manejo tienen muchos campos.
Citrix recomienda habilitar el streaming para el contenido de carga útil de más de 20 MB. Además, el servidor back-end debe aceptar las solicitudes fragmentadas si la transmisión está habilitada.
Nota:
La acción Post Body Limit siempre está configurada para bloquear y es aplicable tanto para los modos de transmisión como sin transmisión. Si el tráfico entrante supera los 20 MB, Citrix recomienda configurar
PostBodyLimiten el valor esperado.
Aunque el proceso de transmisión es transparente para los usuarios, se requieren pequeños ajustes de configuración debido a los siguientes cambios:
RegEx Pattern Match: la coincidencia de patrones RegEx ahora está restringida a 4K para la coincidencia de cadenas de caracteres contiguos.
Coincidencia de nombre de campo: el motor de aprendizaje de Web App Firewall solo puede distinguir los primeros 128 bytes del nombre. Si un formulario tiene varios campos con nombres que tienen una coincidencia de cadena idéntica para los primeros 128 bytes, el motor de aprendizaje no los distingue. Del mismo modo, la regla de relajación implementada podría relajar inadvertidamente todos esos campos.
La eliminación de espacios en blanco, la decodificación porcentual, la decodificación Unicode y la conversión de juego de caracteres se realizan durante la canonización para proporcionar una inspección de comprobación de seguridad. El límite de 128 bytes es aplicable a la representación canonizada del nombre del campo en formato de caracteres UTF-8. Los caracteres ASCII tienen una longitud de 1 byte, pero la representación UTF-8 de los caracteres en algunos idiomas internacionales puede variar de 1 byte a 4 bytes. Si cada carácter de un nombre requiere 4 bytes para convertirse a formato UTF-8, solo los primeros 32 caracteres del nombre pueden distinguirse por la regla aprendida.
Comprobación de coherencia de campos: cuando habilita la coherencia de campos, todos los formularios de la sesión se almacenan en función de la etiqueta “as_fid” insertada por Web App Firewall sin tener en cuenta la “action_url”.
- Etiquetado obligatorio de formulario para coherencia de campo de formulario: cuando la comprobación de coherencia de campo está habilitada, la etiqueta de formulario también debe estar habilitada. Es posible que la protección de coherencia de campo no funcione si el etiquetado de formularios está desactivado.
- Consistencia de campos de formulario sin sesión: Web App Firewall ya no lleva a cabo la conversión de formularios “GET” a “POST” cuando el parámetro de coherencia de campos sin sesión está habilitado. La etiqueta de formulario también es necesaria para la coherencia de los campos sin sesión.
- Manipulación de as_fid: Si un formulario se envía después de manipular as_fid, desencadena una infracción de consistencia del campo incluso si no se ha alterado ningún campo. En las solicitudes que no son de transmisión, esto se permitió porque los formularios se pueden validar con la “action_url” almacenada en la sesión.
Firmas: Las firmas ahora tienen las siguientes especificaciones:
-
Ubicación: Ahora es un requisito obligatorio que la ubicación debe especificarse para cada patrón. Todos los patrones de la regla DEBE tener una etiqueta
<Location>. -
Coincidencia rápida: Todas las reglas de firma deben tener un patrón de coincidencia rápida. Si no hay un patrón de coincidencia rápida, se intenta seleccionar uno si es posible. La coincidencia rápida es una cadena literal, pero
PCREse puede usar para la coincidencia rápida si contienen una cadena literal utilizable. -
Ubicaciones en desuso: las siguientes ubicaciones ya no son compatibles con las reglas de firma.
- HTTP_ANY
- HTTP_RAW_COOKIE
- HTTP_RAW_HEADER
- HTTP_RAW_RESP_HEADER
- HTTP_RAW_SET_COOKIE
Script entre sitios/SQL Transform: Los datos sin procesar se utilizan para la transformación porque los caracteres especiales de SQL como comillas simples (‘), barra invertida (\) y punto y coma (;) y las etiquetas de scripts entre sitios son los mismos y no requieren la canonización de los datos. La representación de caracteres especiales como codificación de entidades HTML, codificación porcentual o ASCII se evalúa para la operación de transformación.
Web App Firewall ya no inspecciona el nombre y el valor del atributo para la operación de transformación de scripts entre sitios. Ahora solo se transforman los nombres de atributos de scripting entre sitios cuando se activa la transmisión.
Procesamiento de etiquetas de scripts entre sitios: como parte de los cambios de streaming en la compilación de NetScaler 10.5.e y versiones posteriores, el procesamiento de las etiquetas de scripts entre sitios ha cambiado. En versiones anteriores, la presencia de corchetes abiertos (<), or close bracket (>) o de ambos corchetes abiertos y cerrados (<>) se marcaba como infracción de scripts entre sitios. El comportamiento ha cambiado en la compilación 10.5.e en adelante. La presencia del carácter de corchete abierto (<) o del carácter de corchete cerrado (>) ya no se considera un ataque. Esto es cuando un carácter de corchete de apertura (<) va seguido de un carácter de corchete de cierre (>), se detecta el ataque de scripting entre sitios. Ambos caracteres deben estar presentes en el orden correcto (< seguido de >) para activar la infracción de scripts entre sitios.
Nota:
Mensaje de cambio en el registro de infracciones de SQL: Como parte de los cambios de transmisión en la versión 10.5.e de Citrix ADC en adelante, ahora procesamos los datos de entrada en bloques. La coincidencia de patrones RegEx ahora está restringida a 4K para la coincidencia de cadenas de caracteres contiguos. Con este cambio, los mensajes de registro de infracciones SQL pueden incluir información diferente en comparación con las compilaciones anteriores. La palabra clave y el carácter especial de la entrada están separados por muchos bytes. El dispositivo tiene un seguimiento de las palabras clave SQL y cadenas especiales al procesar los datos, en lugar de almacenar en búfer todo el valor de entrada. Además del nombre del campo, el mensaje de registro incluye la palabra clave SQL, el carácter especial SQL o tanto la palabra clave SQL como el carácter especial SQL. El resto de la entrada ya no se incluye en el mensaje de registro, como se muestra en el ejemplo siguiente:
Ejemplo:
En 10.5, cuando Web App Firewall detecta la infracción de SQL, la cadena de entrada completa podría incluirse en el siguiente mensaje de registro:
Error en la comprobación de palabras clave SQL para text="select a name from testbed1\;\(\;\)".*<blocked>
En 11.0, registramos solo el nombre del campo, la palabra clave y el carácter especial (si corresponde) en el siguiente mensaje de registro.
Error en la comprobación de palabras clave SQL para el campo
text="select(;)" <blocked>Este cambio se aplica a las solicitudes que contienen application/x-www-form-urlencoded, multipart/form-data o text/x-gwt-rpc content-types. Los mensajes de registro generados durante el procesamiento de cargas útiles JSON o XML no se ven afectados por este cambio.
Cuerpo RAW POST: Las inspecciones de control de seguridad siempre se realizan en el cuerpo RAW POST.
ID de formulario: Web App Firewall insertó la etiqueta “as_fid”, que es un hash calculado del formulario que ya es único para la sesión del usuario. Es un valor idéntico para un formulario específico, independientemente del usuario o de la sesión.
Juego de caracteres: si una solicitud no tiene un juego de caracteres, el juego de caracteres predeterminado especificado en el perfil de la aplicación se utiliza al procesar la solicitud.
Contadores:
Se agregan contadores con un prefijo “se” y “appfwreq” para rastrear los contadores de solicitudes del motor de transmisión y del motor de transmisión.
nsconsmg -d statswt0 -g se_err_
nsconsmg -d statswt0 -g se_tot_
nsconsmg -d statswt0 -g se_cur_
nsconsmg -d statswt0 -g appfwreq_err_
nsconsmg -d statswt0 -g appfwreq_tot_
nsconsmg -d statswt0 -g appfwreq_cur_
_err counters: indica el evento raro que debe haber tenido éxito pero falló debido a un problema de asignación de memoria o alguna otra crisis de recursos.
_tot counters: contadores cada vez mayores.
_cur counters: contadores que indican valores actuales que siguen cambiando según el uso de las transacciones actuales.
Sugerencias:
- Las comprobaciones de seguridad de Web App Firewall deben funcionar igual que antes.
- No hay ningún orden establecido para el procesamiento de los controles de seguridad.
- El procesamiento del lado de respuesta no se ve afectado y permanece sin cambios.
- La transmisión no se activa si se utiliza VPN sin cliente.
Importante:
Calcular la longitud de la cookie: en la versión 10.5.e, además de la versión 11.0 de Citrix ADC (en compilaciones anteriores a la 65.x), se cambió la forma en que Web App Firewall procesaba el encabezado de la cookie. El dispositivo evaluó la cookie individualmente y, si la longitud de una cookie en el encabezado de la cookie excedió la longitud configurada, se activó la infracción de desbordamiento de búfer. Como resultado, es posible que se permitan solicitudes bloqueadas en la versión 10.5 de NetScaler o en versiones anteriores. La longitud de todo el encabezado de la cookie no se calcula para determinar la longitud de la cookie. En algunas situaciones, el tamaño total de la cookie puede ser mayor que el valor aceptado, y el servidor puede responder con “400 Bad Request”.
Nota: El cambio se ha revertido. El comportamiento de NetScaler versión 10.5.e a la versión 59.13xx.e y sus compilaciones posteriores es similar a las compilaciones no mejoradas de la versión 10.5. Ahora se tiene en cuenta todo el encabezado de Cookie sin procesar al calcular la longitud de la cookie. Los espacios circundantes y los caracteres de punto y coma (;) que separan los pares nombre-valor también se incluyen para determinar la longitud de la cookie.