Soporte de transmisión para el procesamiento de solicitudes

Citrix Web App Firewall utiliza ahora la transmisión por el lado de las solicitudes, lo que da como resultado un aumento significativo del rendimiento. En lugar de almacenar en búfer toda la solicitud antes de procesarla, el Web App Firewall ahora examina los datos entrantes, campo por campo, para inspeccionar la entrada de cada campo en busca de cualquier infracción de comprobación de seguridad configurada (SQL, XSS, coherencia de campos, formatos de campo, etc.). Tan pronto como se completa el procesamiento de los datos de un campo, se reenvía al back-end mientras la evaluación continúa para los campos restantes. Esto mejora significativamente el tiempo de procesamiento, especialmente cuando se manejan postes grandes donde los formularios tienen un gran número de campos.

Nota:

Citrix Web App Firewall admite un tamaño máximo de publicación de 20 MB sin transmisión por secuencias. Para una mejor utilización de los recursos, Citrix recomienda habilitar la opción de transmisión para cargas útiles superiores a 20 MB. Además, el servidor back-end debe aceptar las solicitudes fragmentadas cuando la transmisión está habilitada.

Aunque el proceso de transmisión es transparente para los usuarios, se requieren pequeños ajustes de configuración debido a los siguientes cambios:

Match depatrón de RegEx: la coincidenciade patrón de RegEx ahora está restringida a 4K para coincidencia de cadena 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 para el aprendizaje. Si un formulario tiene varios campos con nombres que tienen una coincidencia de cadena idéntica para los primeros 128 bytes, es posible que el motor de aprendizaje no pueda distinguir entre ellos. Del mismo modo, la regla de relajación desplegada podría relajar inadvertidamente todos esos campos.

La eliminación de espacios en blanco, decodificación porcentual, decodificación Unicode y conversión de conjuntos de caracteres que se realiza durante la canonización se lleva a cabo antes de la inspección de comprobación de seguridad. El límite de 128 bytes es aplicable a la representación canónica del nombre de campo en formato de caracteres UTF-8. Los caracteres ASCII son de 1 byte, pero la representación UTF-8 de los caracteres en algunos idiomas internacionales puede oscilar entre 1-4 bytes. Si cada carácter del nombre toma 4 bytes cuando se convierte al formato UTF-8, solo los primeros 32 caracteres del nombre pueden distinguirse por la regla aprendida para dicho idioma.

Comprobación de coherencia de campo: Cuando la comprobación de coherencia de campo está habilitada, todos los formularios de la sesión se almacenan ahora en función de la etiqueta “as_fid” insertada por el Web App Firewall sin tener en cuenta la opción “action_url”.

  • Etiquetado de formulario obligatorio para la coherencia de campos de formulario: Cuando la comprobación de coherencia de campos está habilitada, también debe habilitarse la etiqueta de formulario. 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: El Web App Firewall ya no lleva a cabo la conversión “GET” a “POST” de formularios cuando el parámetro de consistencia de campo sin sesión está habilitado. La etiqueta de formulario también es necesaria para la coherencia de los campos sin sesión.
  • Alteración de as_fid: Si se envía un formulario después de manipular as_fid, ahora desencadena una infracción de coherencia de campo aunque no se haya alterado ningún otro campo. En las solicitudes que no son de transmisión, esto se permitió porque los formularios se podían validar mediante 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 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 intentará seleccionar uno si es posible. La coincidencia rápida debe ser una cadena literal, pero algunos PCRE se pueden usar para la coincidencia rápida si contienen una cadena literal utilizable.

  • Ubicaciones obsoletas: 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

Transformación XSS/SQL: Los datos sin procesar se utilizan para la transformación porque los caracteres especiales de SQL (comilla simple (‘), barra invertida () y punto y coma (;)) y las etiquetas XSS ((<) and (>)) son los mismos en todos los idiomas y no necesitan canonicalización de los datos. Todas las representaciones de estos caracteres, como codificación de entidad HTML, codificación de porcentaje o ASCII, se evalúan para la operación de transformación.

El Web App Firewall ya no inspecciona el nombre y el valor del atributo para la operación de transformación XSS. Ahora solo se transforman los nombres de atributos XSS cuando se activa la transmisión.

Procesamiento de etiquetas XSS: Como parte de los cambios de transmisión en versión 10.5.e en adelante, el procesamiento de Web App Firewall de las etiquetas Cross-Site Scripting ha cambiado. En versiones anteriores, la presencia de corchetes abiertos (<), corchetes cerrados (>) o ambos corchetes abiertos y cerrados (<>) se marcó como Violació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. Es cuando un carácter de corchete abierto (<) va seguido de un corchetes cerrados (>), el ataque de scripts entre sitios se marca. Ambos caracteres deben estar presentes en el orden correcto (< followed by >) para desencadenar una infracción de scripts entre sitios.

Nota

Cambio en el registro de infracciones SQL Mensaje: Como parte de los cambios de transmisión en versión 10.5.e 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 en la entrada podrían estar separados por un gran número de bytes. Ahora hacemos un seguimiento de las palabras clave SQL y las 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 ahora la palabra clave SQL, o el carácter especial SQL, o tanto la palabra clave SQL como el carácter especial SQL, según lo determinado por la configuración configurada. 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 SQL, es posible que la cadena de entrada completa se incluya en el mensaje de registro, como se muestra a continuación:

Error en la comprobación de palabras clave SQL para el campo 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 mensaje de registro, como se muestra a continuación:

Error en la comprobación de palabras clave SQL para el campo text="select(;)" <blocked>

Este cambio es aplicable a las solicitudes que contienen application/x-www-form-urlencoded, o multipart/form-data, o text/x-gwt-rpcContent-types. Los mensajes de registro generados durante el procesamiento de cargas JSON o XML no se ven afectados por este cambio.

Cuerpo RAW POST: Las inspecciones de comprobación de seguridad siempre se realizan en el cuerpo RAW POST.

Id. de formulario: La etiqueta “as_fid” insertada en Web App Firewall, que es un hash calculado del formulario, ya no será única para la sesión de usuario. Ahora tendrá un valor idéntico para un formulario específico independientemente del usuario o la sesión.

Conjunto 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:

Los contadores con el prefijo “se_” y “appfwreq_” se agregan para rastrear el motor de transmisión y los contadores de solicitudes del motor de transmisión de Web App Firewall respectivamente.

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_

Contadores _err: indica el evento raro que debería haber tenido éxito pero falló debido a problemas de asignación de memoria o a algún otro recorte de recursos.

Contadores _tot: contadores cada vez mayores.

contadores _cur: contadores que indican los valores actuales que siguen cambiando según el uso de las transacciones actuales.

Consejos:

  • Las comprobaciones de seguridad de Web App Firewall deberían funcionar exactamente 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 CVPN.

Importante

Cálculo de la longitud de la cookie: en la versión 10.5.e (en algunas compilaciones de mejoras provisionales anteriores a la compilación 59.13xx.e), así como en la versión 11.0 (en compilaciones anteriores a 65.x), se cambió el procesamiento del Web App Firewall del encabezado Cookie. En esas versiones, cada cookie se evalúa individualmente, y si la longitud de cualquier cookie recibida en el encabezado Cookie excede el BufferOverflowMaxCookieLength configurado, se desencadena la infracción de desbordamiento de búfer. Como resultado de este cambio, las solicitudes que se bloquearon en versiones 10.5 y versiones anteriores podrían ser permitidas, ya que 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 reenviada al servidor puede ser mayor que el valor aceptado, y el servidor puede responder con “400 Bad Request”.

Tenga en cuenta que este cambio se ha revertido. El comportamiento en las compilaciones 10.5.e ->59.13xx.e y posteriores de mejora 10.5.e, así como en la versión 11.0 65.x y posteriores compilaciones ahora es similar al de 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.

Soporte de transmisión para el procesamiento de solicitudes