Función de streaming para el procesamiento de solicitudes
NetScaler Web App Firewall admite la transmisión del lado de la solicitud para proporcionar un aumento significativo del rendimiento. En lugar de almacenar una solicitud en búfer, el dispositivo examina el tráfico entrante para detectar infracciones de seguridad, como el SQL, las secuencias de comandos entre sitios, la coherencia de los campos y los formatos de los campos. Cuando el dispositivo termina de procesar los datos de un campo, la solicitud se reenvía al servidor de fondo 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:
Coincidencia depatrones RegEx: la coincidencia de patrones RegEx ahora está restringida a 4K para la coincidencia de cadenas de caracteres contiguas.
Coincidencia de nombres 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 los espacios en blanco, la decodificación porcentual, la decodificación Unicode y la conversión de conjuntos de caracteres se realizan durante la canonicalización para realizar una inspecció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 se especifique la ubicación para cada patrón. Todos los patrones de la regla DEBEN tener una
<Location>etiqueta. -
Coincidencia rápida: todas las reglas de firma deben tener un patrón de coincidencia rápida. Si no hay ningún 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 obsoletas: las reglas de firma ya no admiten las siguientes ubicaciones.
- 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.
El Web App Firewall ya no inspecciona tanto el nombre como el valor del atributo de la operación de transformación mediante secuencias de comandos entre sitios. Ahora, solo los nombres de los atributos de secuencias de comandos entre sitios se transforman cuando se activa la transmisión.
Procesamiento de etiquetas de secuencias de comandos entre sitios: como parte de los cambios de transmisión en la versión 10.5.e y versiones posteriores de NetScaler, ha cambiado el procesamiento de las etiquetas de secuencias de comandos entre sitios. En versiones anteriores, la presencia de corchetes abiertos (<), corquetes cerrados (>) o corchetes abiertos y cerrados (<>) se marcaba como Infracción de scripts de sitios. El comportamiento cambió a partir de la versión 10.5.e. La presencia únicamente del carácter entre corchetes (<), or only the close bracket character (>) 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 NetScaler 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.
Falló la comprobación de palabras clave de 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, se utiliza el juego de caracteres predeterminado especificado en el perfil de la aplicación 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 los valores actuales que siguen cambiando en función del uso de las transacciones actuales.
Sugerencias:
- Las comprobaciones de seguridad de Web App Firewall deben funcionar igual que antes.
- No hay un orden establecido para el procesamiento de los controles de seguridad.
- El procesamiento del lado de la respuesta no se ve afectado y permanece sin cambios.
- La transmisión no se activa si se utiliza una 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 NetScaler (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 superior al valor aceptado y el servidor puede responder con “400 solicitudes incorrectas”.
Nota: El cambio se ha revertido. El comportamiento de las versiones 10.5.e de NetScaler a 59.13xx.e y sus compilaciones posteriores es similar al de las compilaciones sin mejoras 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.