Prise en charge en continu pour le traitement des demandes

Le Citrix Web App Firewall utilise désormais le streaming côté demande, ce qui entraîne une augmentation significative des performances. Au lieu de mettre en mémoire tampon toute la demande avant de la traiter, le pare-feu de l’application Web examine désormais les données entrantes, champ par champ, pour inspecter l’entrée de chaque champ pour toute violation de vérification de sécurité configurée (SQL, XSS, cohérence des champs, formats de champ, etc.). Dès que le traitement des données d’un champ est terminé, il est transmis au backend pendant que l’évaluation se poursuit pour les champs restants. Cela améliore considérablement le temps de traitement en particulier lors de la manipulation de grands poteaux où les formulaires ont un grand nombre de champs.

Remarque :

Citrix Web App Firewall prend en charge une taille de publication maximale de 20 Mo sans diffusion en continu. Pour une meilleure utilisation des ressources, Citrix vous recommande d’activer l’option de streaming pour les charges utiles supérieures à 20 Mo. En outre, le serveur principal doit accepter les requêtes en morceaux lorsque la diffusion en continu est activée.

Bien que le processus de diffusion en continu soit transparent pour les utilisateurs, des ajustements mineurs de configuration sont nécessaires en raison des modifications suivantes :

Correspondance de motifRegEx : la correspondance de motif RegEx est désormais limitée à 4K pour la correspondance de chaîne de caractères contiguës.

Correspondance de nom de champ : le moteur d’apprentissage du Web App Firewall ne peut distinguer que les 128 premiers octets du nom pour l’apprentissage. Si un formulaire comporte plusieurs champs avec des noms qui ont une correspondance de chaîne identique pour les 128 premiers octets, le moteur d’apprentissage peut ne pas être en mesure de les distinguer. De même, la règle de relaxation déployée pourrait, par inadvertance, modérer tous ces champs.

La suppression des espaces blancs, du pourcentage de décodage, du décodage Unicode et de la conversion du jeu de caractères effectuée lors de la standardisation est effectuée avant l’inspection du contrôle de sécurité. La limite de 128 octets est applicable à la représentation standardisée du nom de champ au format de caractères UTF-8. Les caractères ASCII sont de 1 octet mais la représentation UTF-8 des caractères dans certaines langues internationales peut varier de 1 à 4 octets. Si chaque caractère du nom prend 4 octets lorsqu’il est converti au format UTF-8, seuls les 32 premiers caractères du nom peuvent être distingués par la règle apprise pour une telle langue.

Vérification de cohérence des champs : lorsque le contrôle de cohérence des champs est activé, tous les formulaires de la session sont désormais stockés en fonction de la balise “as_fid” insérée par le Web App Firewall sans tenir compte de la balise “action_url.”

  • Marquage obligatoire du formulaire pour la cohérence du champde formulaire : lorsque la vérification de cohérence des champs est activée, la balise de formulaire doit également être activée. La protection de cohérence des champs peut ne pas fonctionner si le balisage des formulaires est désactivé.
  • Cohérence des champs de formulaire sans session : le Web App Firewall n’effectue plus la conversion « GET » en « POST » des formulaires lorsque le paramètre de cohérence des champs sans session est activé. La balise de formulaire est également requise pour la cohérence des champs sans session.
  • Falsification de as_fid : Si un formulaire est soumis après avoir falsifié as_fid, il déclenche désormais une violation de cohérence des champs même si aucun autre champ n’a été falsifié. Dans les requêtes non diffusées, cela était autorisé car les formulaires pouvaient être validés à l’aide de la « action_url » stockée dans la session.

Signatures : Les signatures ont maintenant les spécifications suivantes :

  • Emplacement : Il est maintenant obligatoire que l’emplacement soit spécifié pour chaque motif. Tous les modèles de la règle DOIVENT avoir une balise <Location>.

  • Correspondance rapide : toutes les règles de signature doivent avoir un modèle de correspondance rapide. S’il n’y a pas de modèle de correspondance rapide, une tentative sera faite pour en sélectionner un si possible. La correspondance rapide doit être une chaîne littérale, mais certains PCRE peuvent être utilisés pour la correspondance rapide s’ils contiennent une chaîne littérale utilisable.

  • Emplacements obsolètes : les emplacementssuivants ne sont plus pris en charge dans les règles de signature.

    • HTTP_ANY
    • HTTP_RAW_COOKIE
    • HTTP_RAW_HEADER
    • HTTP_RAW_RESP_HEADER
    • HTTP_RAW_SET_COOKIE

Transformation XSS/SQL : Les données brutes sont utilisées pour la transformation car les caractères spéciaux SQL (guillemets simples (‘), barre oblique inverse () et point-virgule (;)) et les balises XSS (<) and (>)) sont identiques dans toutes les langues et n’ont pas besoin de standardisation des données. Toutes les représentations de ces caractères, telles que le codage d’entité HTML, le codage en pourcentage ou l’ASCII, sont évaluées pour l’opération de transformation.

Le Web App Firewall n’inspecte plus le nom et la valeur de l’attribut pour l’opération de transformation XSS. Maintenant, seuls les noms d’attributs XSS sont transformés lorsque la diffusion en continu est engagée.

Traitement des balises XSS : Dans le cadre des modifications de diffusion en continu dans la version 10.5.e, le traitement du pare-feu d’application Web des balises de script inter-site a changé. Dans les versions antérieures, la présence de crochets ouverts (<), or close bracket (>) ou de crochets ouverts et fermés (<>) était signalée comme violation de script intersite. Le comportement a changé dans la version 10.5.e à partir. La présence de seulement le caractère entre crochets ouverts (<) ou seulement le caractère entre crochets (>) n’est plus considérée comme une attaque. C’est quand un caractère entre crochets ouverts (<) is followed by a close bracket character (>), l’attaque de script inter-site est signalée. Les deux caractères doivent être présents dans le bon ordre (< followed by >) pour déclencher une violation de script inter-site.

Remarque

Changement dans le journal des violations SQL Message : Dans le cadre des changements de streaming dans la version 10.5.e ultérieure, nous traitons maintenant les données d’entrée en blocs. La correspondance de motifs RegEx est désormais limitée à 4K pour la correspondance de chaînes de caractères contiguës. Avec cette modification, les messages du journal des violations SQL peuvent inclure des informations différentes par rapport aux versions précédentes. Le mot-clé et le caractère spécial de l’entrée peuvent être séparés par un grand nombre d’octets. Nous gardons maintenant une trace des mots-clés SQL et des chaînes spéciales lors du traitement des données, au lieu de mettre en mémoire tampon toute la valeur d’entrée. Outre le nom du champ, le message de journal inclut désormais le mot-clé SQL ou le caractère spécial SQL, ou à la fois le mot-clé SQL et le caractère spécial SQL, comme déterminé par le paramètre configuré. Le reste de l’entrée n’est plus inclus dans le message de journal, comme illustré dans l’exemple suivant :

Exemple :

Dans 10.5, lorsque le Web App Firewall détecte la violation SQL, la chaîne d’entrée entière peut être incluse dans le message de journal, comme indiqué ci-dessous :

La vérification du mot-clé SQL a échoué pour le champ text=”sélectionnez un nom dans testbed1 ; ( ;) ».<blocked>*

Dans 11.0, nous enregistrons uniquement le nom du champ, le mot-clé et le caractère spécial (le cas échéant) dans le message de journal, comme indiqué ci-dessous :

Échec de la vérification des mots-clés SQL pour le champ text="select(;)" <blocked>

Cette modification s’applique aux demandes qui contiennent des types de contenu application/x-www-form-urlencoded, multipart/form-dataou text/x-gwt-rpc. Les messages de journal générés lors du traitement des charges utiles JSON ou XML ne sont pas affectés par cette modification.

Corps RAW POST : Les contrôles de sécurité sont toujours effectués sur le corps RAW POST.

ID du formulaire : la balise “as_fid” insérée dans le Web App Firewall, qui est un hachage calculé du formulaire, ne sera plus unique pour la session utilisateur. Il aura maintenant une valeur identique pour un formulaire spécifique quel que soit l’utilisateur ou la session.

Jeu de caractères : si une demande ne possède pas de jeu de caractères, le jeu de caractères par défaut spécifié dans le profil d’application est utilisé lors du traitement de la demande.

Compteurs :

Les compteurs avec le préfixe “se_” et “appfwreq_” sont ajoutés pour suivre le moteur de streaming et les compteurs de requête du moteur de streaming Web App Firewall respectivement.

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 : indiquez l’événement rare qui aurait dû réussir mais qui a échoué en raison d’un problème d’allocation de mémoire ou d’un autre problème de ressource.

_tot counters : compteurs toujours en augmentation.

_cur counters : compteurs indiquant les valeurs actuelles qui continuent de changer en fonction de l’utilisation des transactions en cours.

Conseils :

  • Les vérifications de sécurité du Web App Firewall doivent fonctionner exactement de la même manière qu’auparavant.
  • Il n’y a pas de commande définie pour le traitement des contrôles de sécurité.
  • Le traitement côté réponse n’est pas affecté et reste inchangé.
  • La diffusion en continu n’est pas engagée si CVPN est utilisé.

Important

Calcul de la longueur du cookie : Dans la version 10.5.e (dans quelques versions d’amélioration provisoires antérieures à 59.13xx.e) ainsi que dans la version 11.0 (dans les versions antérieures à 65.x), le traitement de l’en-tête du cookie par le Web App Firewall a été modifié. Dans ces versions, chaque cookie est évalué individuellement, et si la longueur d’un cookie reçu dans l’en-tête Cookie dépasse le BufferOverflowMaxCookieLength configuré, la violation Buffer Overflow est déclenchée. À la suite de cette modification, les requêtes qui ont été bloquées dans les versions 10.5 et antérieures peuvent être autorisées, car la longueur de l’en-tête du cookie entier n’est pas calculée pour déterminer la longueur du cookie. Dans certains cas, la taille totale des cookies transmise au serveur peut être supérieure à la valeur acceptée, et le serveur peut répondre avec « 400 Bad Request ».

Notez que cette modification a été annulée. Le comportement dans les versions 10.5.e ->59.13xx.e et 10.5.e ultérieures ainsi que dans la version 11.0 65.x et les versions ultérieures est maintenant similaire à celui des versions non améliorées de la version 10.5. L’en-tête de Cookie brut entier est maintenant pris en compte lors du calcul de la longueur du cookie. Les espaces environnants et les point-virgule (;) séparant les paires nom-valeur sont également inclus dans la détermination de la longueur du cookie.

Prise en charge en continu pour le traitement des demandes