Présentation du pare-feu Citrix Web Application

Le Citrix Web App Firewall empêche les failles de sécurité, la perte de données et les éventuelles modifications non autorisées des sites Web qui accèdent aux informations sensibles de l’entreprise ou des clients. Il le fait en filtrant les demandes et les réponses, en les examinant à la recherche de preuves d’activités malveillantes et en bloquant les demandes qui démontrent une telle activité. Votre site est protégé non seulement contre les types d’attaques courants, mais aussi contre les attaques nouvelles, encore inconnues. En plus de protéger les serveurs Web et les sites Web contre les accès non autorisés, le Web App Firewall protège contre les vulnérabilités des codes ou scripts CGI existants, des frameworks Web, des logiciels de serveur Web et d’autres systèmes d’exploitation sous-jacents.

Citrix Web App Firewall est disponible en tant qu’appliance autonome ou en tant que fonctionnalité sur un dispositif virtuel Citrix ADC (VPX). Dans la documentation du Web App Firewall, le terme Citrix ADC fait référence à la plate-forme sur laquelle le Web App Firewall est exécuté, que cette plate-forme soit un dispositif de pare-feu dédié, un Citrix ADC sur lequel d’autres fonctionnalités ont également été configurées ou un Citrix ADC VPX.

Pour utiliser le Web App Firewall, vous devez créer au moins une configuration de sécurité pour bloquer les connexions qui enfreignent les règles que vous définissez pour vos sites Web protégés. Le nombre de configurations de sécurité que vous souhaitez créer dépend de la complexité de votre site Web. Parfois, une seule configuration est suffisante. Dans d’autres cas, en particulier ceux qui incluent des sites Web interactifs, des sites Web qui accèdent à des serveurs de base de données, des magasins en ligne avec des paniers d’achat, vous pourriez avoir besoin de plusieurs configurations différentes pour protéger au mieux les données sensibles sans gaspiller d’efforts importants sur le contenu qui n’est pas vulnérable à certains types de attaques. Vous pouvez souvent laisser les valeurs par défaut des paramètres globaux, qui affectent toutes les configurations de sécurité, inchangées. Toutefois, vous pouvez modifier les paramètres globaux s’ils sont en conflit avec d’autres parties de votre configuration ou si vous préférez les personnaliser.

Sécurité des applications Web

La sécurité des applications Web est la sécurité du réseau pour les ordinateurs et les programmes qui communiquent à l’aide des protocoles HTTP et HTTPS. Il s’agit d’un vaste domaine dans lequel les failles et les faiblesses en matière de sécurité abondent. Les systèmes d’exploitation des serveurs et des clients présentent des problèmes de sécurité et sont vulnérables aux attaques. Les logiciels de serveur Web et les technologies d’activation de sites Web comme CGI, Java, JavaScript, PERL et PHP présentent des vulnérabilités sous-jacentes. Les navigateurs et autres applications clientes qui communiquent avec des applications web présentent également des vulnérabilités. Les sites Web qui utilisent n’importe quelle technologie, mais le HTML le plus simple, y compris tout site qui permet l’interaction avec les visiteurs, ont souvent des vulnérabilités propres.

Dans le passé, une atteinte à la sécurité n’était souvent qu’une gêne, mais aujourd’hui c’est rarement le cas. Par exemple, les attaques au cours desquelles un pirate a accédé à un serveur Web et apporté des modifications non autorisées à un site Web (défacé) étaient courantes. Ils étaient généralement lancés par des pirates qui n’avaient aucune motivation que de démontrer leurs compétences à d’autres pirates ou de gêner la personne ou l’entreprise visée. Cependant, la plupart des manquements actuels à la sécurité sont motivés par un désir d’argent. La majorité tente d’atteindre l’un ou l’autre des objectifs suivants : obtenir des renseignements confidentiels et potentiellement utiles, ou obtenir un accès non autorisé à un site Web ou un serveur Web et à le contrôler.

Certaines formes d’attaques sur le Web visent à obtenir des informations privées. Ces attaques sont souvent possibles même contre des sites Web suffisamment sécurisés pour empêcher un attaquant de prendre le contrôle total. Les informations qu’un attaquant peut obtenir à partir d’un site Web peuvent inclure les noms, adresses, numéros de téléphone, numéros de sécurité sociale, numéros de carte de crédit, dossiers médicaux et autres informations privées. L’attaquant peut alors utiliser ces informations ou les vendre à d’autres. Une grande partie de l’information obtenue par de telles attaques est protégée par la loi, et tout cela par la coutume et l’attente. Une violation de ce type peut avoir de graves conséquences pour les clients dont les informations privées sont compromises. Au mieux, ces clients doivent faire preuve de vigilance pour empêcher les autres d’abuser de leurs cartes de crédit, d’ouvrir des comptes de crédit non autorisés à leur nom ou de s’approprier leur identité pure et simple (usurpation d’identité). Au pire, les clients peuvent faire face à des notations de crédit ruines ou même être blâmés pour des activités criminelles auxquelles ils n’ont pas participé.

D’autres attaques Web visent à obtenir le contrôle (ou compromettre) un site Web ou le serveur sur lequel il opère, ou les deux. Un pirate qui prend le contrôle d’un site Web ou d’un serveur peut l’utiliser pour héberger du contenu non autorisé, agir comme proxy pour le contenu hébergé sur un autre serveur Web, fournir des services SMTP pour envoyer des courriels non sollicités en masse ou fournir des services DNS pour prendre en charge de telles activités sur d’autres serveurs Web compromis. La plupart des sites Web hébergés sur des serveurs Web compromis favorisent des entreprises douteuses ou carrément frauduleuses. Par exemple, la plupart des sites Web d’hameçonnage et des sites d’exploitation des enfants sont hébergés sur des serveurs Web compromis.

La protection de vos sites Web et services Web contre ces attaques nécessite une défense multicouche capable à la fois de bloquer les attaques connues avec des caractéristiques identifiables et de protéger contre les attaques inconnues, qui peuvent souvent être détectées parce qu’elles ont un aspect différent du trafic normal vers vos sites Web et Web services.

Attaques Web connues

La première ligne de défense de vos sites Web est la protection contre le grand nombre d’attaques connues et observées et analysées par des experts en sécurité web. Les types courants d’attaques contre les sites Web HTML sont les suivants :

• Attaques par débordement de tampon. L’envoi d’une longue URL, d’un cookie long ou de longues informations à un serveur Web entraîne le blocage, le blocage ou l’accès non autorisé au système d’exploitation sous-jacent. Une attaque par débordement de tampon peut être utilisée pour accéder à des informations non autorisées, compromettre un serveur Web, ou les deux.
• Attaques de sécurité des cookies. Envoi d’un cookie modifié à un serveur Web, généralement dans l’espoir d’obtenir l’accès à un contenu non autorisé en utilisant des informations d’identification falsifiées.
• Navigation puissante. Accéder directement aux URL d’un site Web, sans accéder aux URL contenant des hyperliens sur la page d’accueil ou d’autres URL de démarrage courantes sur le site Web. Des cas individuels de navigation forcée peuvent indiquer un utilisateur qui a marqué une page sur votre site Web, mais les tentatives répétées d’accès à du contenu inexistant, ou à du contenu auquel les utilisateurs ne doivent jamais accéder directement, représentent souvent une atteinte à la sécurité du site Web. La navigation forcée est normalement utilisée pour accéder à des informations non autorisées, mais peut également être combinée à une attaque par débordement de tampon dans le but de compromettre votre serveur.
• Attaques de sécurité des formulaires Web. Envoi de contenu inapproprié à votre site Web dans un formulaire Web. Le contenu inapproprié peut inclure des champs masqués modifiés, du code HTML ou du code dans un champ destiné uniquement aux données alphanumériques, une chaîne trop longue dans un champ qui n’accepte qu’une chaîne courte, une chaîne alphanumérique dans un champ qui n’accepte qu’un entier et une grande variété d’autres données que votre site Web ne contient pas attendez à recevoir dans ce formulaire Web. Une attaque de sécurité de formulaire Web peut être utilisée soit pour obtenir des informations non autorisées de votre site Web, soit pour compromettre le site Web, généralement lorsqu’elle est associée à une attaque de débordement de tampon.

Deux types spécialisés d’attaques contre la sécurité des formulaires Web méritent une mention spéciale :

• Attaques par injection SQL. Envoi d’une ou de plusieurs commandes SQL actives dans un formulaire Web ou dans le cadre d’une URL, dans le but d’amener une base de données SQL à exécuter la ou les commandes. Les attaques par injection SQL sont normalement utilisées pour obtenir des informations non autorisées.
• Attaques de scripts intersites. Utilisation d’une URL ou d’un script sur une page Web pour enfreindre la stratégie de même origine, qui interdit à tout script d’obtenir des propriétés à partir d’un autre site Web ou de modifier un contenu sur un autre site Web. Étant donné que les scripts peuvent obtenir des informations et modifier des fichiers sur votre site Web, autoriser un script à accéder au contenu d’un autre site Web peut fournir à un attaquant le moyen d’obtenir des informations non autorisées, de compromettre un serveur web, ou les deux.

Les attaques contre les services Web XML relèvent normalement d’au moins une des deux catégories suivantes : tentatives d’envoi de contenu inapproprié à un service Web ou tentatives de violation de la sécurité sur un service Web. Les types d’attaques les plus courants contre les services Web XML sont les suivants :

• Code ou objets malveillants. Demandes XML contenant du code ou des objets qui peuvent obtenir directement des informations sensibles ou donner à un attaquant le contrôle du service Web ou du serveur sous-jacent.
• Demandes XML mal formées. Demandes XML qui ne sont pas conformes à la spécification XML du W3C et qui peuvent donc enfreindre la sécurité sur un service Web non sécurisé
• Attaques par déni de service (DoS). Demandes XML envoyées à plusieurs reprises et en volume élevé, dans le but d’accabler le service Web ciblé et de refuser aux utilisateurs légitimes l’accès au service Web.

Outre les attaques basées sur XML standard, les services Web XML et les sites Web 2.0 sont également vulnérables aux attaques par injection SQL et par script intersite, comme décrit ci-dessous :

• Attaques par injection SQL. Envoi d’une ou de plusieurs commandes SQL actives dans une requête XML, dans le but d’amener une base de données SQL à exécuter cette ou ces commandes. Comme pour les attaques par injection HTML SQL, les attaques par injection XML SQL sont normalement utilisées pour obtenir des informations non autorisées.
• Attaques de scripts intersites. Utilisation d’un script inclus dans une application XML pour enfreindre la stratégie de même origine, ce qui ne permet à aucun script d’obtenir des propriétés à partir d’une application différente ou de modifier un contenu. Étant donné que les scripts peuvent obtenir des informations et modifier des fichiers à l’aide de votre application XML, permettre à un script d’accéder au contenu appartenant à une autre application peut donner à un attaquant les moyens d’obtenir des informations non autorisées, de compromettre l’application, ou les deux

Les attaques Web connues peuvent généralement être arrêtées en filtrant le trafic du site Web pour des caractéristiques spécifiques (signatures) qui apparaissent toujours pour une attaque spécifique et ne doivent jamais apparaître dans le trafic légitime. Cette approche présente l’avantage d’exiger relativement peu de ressources et de présenter relativement peu de risques de faux positifs. Par conséquent, il s’agit d’un outil précieux pour lutter contre les attaques sur les sites Web et les services Web, et pour configurer la protection de base des signatures.

Attaques Web inconnues

La plus grande menace contre les sites Web et les applications ne provient pas d’attaques connues, mais d’attaques inconnues. La plupart des attaques inconnues appartiennent à l’une des deux catégories suivantes : les attaques nouvellement lancées pour lesquelles les entreprises de sécurité n’ont pas encore développé de défense efficace (attaques « jour zéro »), et les attaques ciblées avec soin sur un site Web ou un service Web spécifique plutôt que sur de nombreux sites Web ou services Web (attaques lancées). Ces attaques, comme les attaques connues, ont pour but d’obtenir des informations confidentielles sensibles, de compromettre le site Web ou le service Web et de les utiliser pour d’autres attaques, ou les deux objectifs.

Les attaques Zero Day constituent une menace majeure pour tous les utilisateurs. Ces attaques sont généralement du même type que les attaques connues ; les attaques « jour zéro » impliquent souvent du SQL injecté, un script intersite, une falsification de requête intersite ou un autre type d’attaque similaire aux attaques connues. Généralement, ils ciblent des vulnérabilités que les développeurs du logiciel, du site Web ou du service Web ciblé ignorent ou ont appris. Les entreprises de sécurité n’ont donc pas développé de défenses contre ces attaques, et même si elles l’ont fait, les utilisateurs n’ont pas obtenu et installé les correctifs ni effectué les solutions de contournement nécessaires pour se protéger contre ces attaques. Le temps entre la découverte d’une attaque « jour zéro » et la disponibilité d’une défense (la fenêtre de vulnérabilité) diminue, mais les auteurs peuvent toujours compter sur des heures, voire des jours pendant lesquels de nombreux sites Web et services Web ne disposent pas d’une protection spécifique contre l’attaque.

Les attaques de lance constituent une menace majeure, mais pour un groupe d’utilisateurs plus sélect. Un type commun d’attaque de lance, un hameçonnage de lance, est ciblé sur les clients d’une banque ou d’une institution financière spécifique, ou (moins souvent) sur les employés d’une entreprise ou d’une organisation spécifique. Contrairement à d’autres hameçons, qui sont souvent des faux écrits grossièrement qu’un utilisateur connaissant les communications réelles de cette banque ou institution financière peut reconnaître, les phishing de lance sont lettre parfaite et convaincante. Ils peuvent contenir des renseignements spécifiques à la personne qu’aucun étranger ne doit connaître ou être en mesure d’obtenir à première vue. Le spécialiste de l’hameçonnage est donc en mesure de convaincre la cible de fournir les informations demandées, que le phisher peut ensuite utiliser pour piller des comptes, traiter de l’argent obtenu illégitimement d’autres sources ou accéder à d’autres informations encore plus sensibles.

Ces deux types d’attaque ont certaines caractéristiques qui peuvent généralement être détectées, mais pas en utilisant des modèles statiques qui recherchent des caractéristiques spécifiques, comme le font les signatures standard. La détection de ces types d’attaques nécessite des approches plus sophistiquées et plus gourmandes en ressources, telles que le filtrage heuristique et les systèmes de modèles de sécurité positifs. Les regards de filtrage heuristique, non pas pour des modèles spécifiques, mais pour des modèles de comportements. Les systèmes de modèles de sécurité positifs modélisent le comportement normal du site Web ou du service Web qu’ils protègent, puis bloquent les connexions qui ne correspondent pas à ce modèle d’utilisation normale. Les contrôles de sécurité basés sur des URL et des formulaires Web permettent de déterminer le profil de l’utilisation normale de vos sites Web, puis de contrôler la façon dont les utilisateurs interagissent avec vos sites Web, en utilisant à la fois des heuristiques et une sécurité positive pour bloquer le trafic anormal ou inattendu. Une sécurité heuristique et positive, bien conçue et déployée, peut détecter la plupart des attaques que les signatures manquent. Cependant, ils nécessitent beaucoup plus de ressources que les signatures, et vous devez passer du temps à les configurer correctement pour éviter les faux positifs. Ils sont donc utilisés, non pas comme ligne de défense principale, mais comme sauvegarde des signatures ou d’autres approches moins gourmandes en ressources.

En configurant ces protections avancées en plus des signatures, vous créez un modèle de sécurité hybride qui permet au Web App Firewall de fournir une protection complète contre les attaques connues et inconnues.

Fonctionnement de Citrix Web Application Firewall

Lorsque vous installez le Web App Firewall, vous créez une configuration de sécurité initiale, qui se compose d’une stratégie, d’un profil et d’un objet signatures. La stratégie est une règle qui identifie le trafic à filtrer et le profil identifie les modèles et les types de comportement à autoriser ou à bloquer lorsque le trafic est filtré. Les modèles les plus simples, appelés signatures, ne sont pas spécifiés dans le profil, mais dans un objet signatures associé au profil.

Une signature est une chaîne ou un motif qui correspond à un type d’attaque connu. Le Web App Firewall contient plus d’un millier de signatures dans sept catégories, chacune dirigée contre des attaques contre des types spécifiques de serveurs Web et de contenu Web. Citrix met à jour la liste avec de nouvelles signatures au fur et à mesure que de nouvelles menaces sont identifiées. Au cours de la configuration, vous spécifiez les catégories de signature appropriées pour les serveurs Web et le contenu que vous devez protéger. Les signatures offrent une bonne protection de base avec de faibles frais de traitement. Si vos applications présentent des vulnérabilités spéciales ou si vous détectez une attaque contre elles pour laquelle aucune signature n’existe, vous pouvez ajouter vos propres signatures.

Les protections les plus avancées sont appelées contrôles de sécurité. Une vérification de sécurité est une inspection algorithmique plus rigoureuse d’une demande de modèles ou de comportements spécifiques qui pourraient indiquer une attaque ou constituer une menace pour vos sites Web et services Web protégés. Il peut, par exemple, identifier une demande qui tente d’effectuer un certain type d’opération susceptible de violer la sécurité, ou une réponse qui inclut des informations confidentielles sensibles telles qu’un numéro de sécurité sociale ou un numéro de carte de crédit. Lors de la configuration, vous spécifiez les vérifications de sécurité appropriées pour les serveurs Web et le contenu que vous devez protéger. Les contrôles de sécurité sont restrictifs. Beaucoup d’entre eux peuvent bloquer les demandes et réponses légitimes si vous n’ajoutez pas les exceptions appropriées (relaxations) lors de leur configuration. Identifier les exceptions nécessaires n’est pas difficile si vous utilisez la fonction d’apprentissage adaptatif, qui observe l’utilisation normale de votre site Web et crée des exceptions recommandées.

Le Web App Firewall peut être installé en tant que périphérique réseau de couche 3 ou pont réseau de couche 2 entre vos serveurs et vos utilisateurs, généralement derrière le routeur ou le pare-feu de votre entreprise. Il doit être installé à un endroit où il peut intercepter le trafic entre les serveurs Web que vous souhaitez protéger et le concentrateur ou basculer par lequel les utilisateurs accèdent à ces serveurs Web. Vous configurez ensuite le réseau pour qu’il envoie des demandes au Web App Firewall plutôt que directement à vos serveurs Web, et des réponses au Web App Firewall plutôt que directement à vos utilisateurs. Le Web App Firewall filtre ce trafic avant de le transférer vers sa destination finale, en utilisant à la fois son jeu de règles interne et vos ajouts et modifications. Il bloque ou rend inoffensif toute activité qu’il détecte comme nuisible, puis transfère le trafic restant au serveur Web. La figure suivante donne une vue d’ensemble du processus de filtrage.

Remarque :

La figure omet l’application d’une stratégie au trafic entrant. Il illustre une configuration de sécurité dans laquelle la stratégie est de traiter toutes les demandes. De plus, dans cette configuration, un objet signatures a été configuré et associé au profil, et des vérifications de sécurité ont été configurées dans le profil.

Figure 1. Diagramme de flux du filtrage du Web App Firewall

Comme l’illustre la figure, lorsqu’un utilisateur demande une URL sur un site Web protégé, le Web App Firewall examine d’abord la demande pour s’assurer qu’elle ne correspond pas à une signature. Si la demande correspond à une signature, Citrix Web Application Firewall affiche l’objet d’erreur (une page Web située sur le dispositif de Web App Firewall et que vous pouvez configurer à l’aide de la fonctionnalité d’importation) ou transfère la demande à l’URL d’erreur désignée (la page d’erreur). Les signatures ne nécessitent pas autant de ressources que les vérifications de sécurité. La détection et l’arrêt des attaques détectées par une signature avant d’exécuter l’une des vérifications de sécurité réduisent la charge sur le serveur.

Si une demande réussit l’inspection des signatures, le Web App Firewall applique les vérifications de sécurité des demandes qui ont été activées. Les contrôles de sécurité de la demande permettent de vérifier que la demande est appropriée pour votre site Web ou service Web et qu’elle ne contient pas de matériel susceptible de constituer une menace. Par exemple, les vérifications de sécurité examinent la demande pour détecter des signes indiquant qu’elle peut être d’un type inattendu, demander du contenu inattendu ou contenir des données de formulaire Web, des commandes SQL ou des scripts inattendus et éventuellement malveillants. Si la demande échoue une vérification de sécurité, le Web App Firewall nettoie la demande, puis la renvoie à l’appliance Citrix ADC (ou à l’appliance virtuelle Citrix ADC), ou affiche l’objet d’erreur. Si la demande réussit les vérifications de sécurité, elle est renvoyée à l’appliance Citrix ADC, qui termine tout autre traitement et transfère la demande au serveur Web protégé.

Lorsque le site Web ou le service Web envoie une réponse à l’utilisateur, le Web App Firewall applique les vérifications de sécurité de réponse qui ont été activées. Les contrôles de sécurité des réponses examinent la réponse à la présence de fuites d’informations confidentielles sensibles, de signes de défacement du site Web ou d’autres contenus qui ne doivent pas être présents. Si la réponse échoue une vérification de sécurité, le Web App Firewall supprime le contenu qui ne doit pas être présent ou bloque la réponse. Si la réponse réussit les vérifications de sécurité, elle est renvoyée à l’appliance Citrix ADC, qui la transmet à l’utilisateur.

Fonctionnalités du pare-feu Citrix Web Application

Les fonctionnalités de base du Web App Firewall sont les stratégies, les profils et les signatures, qui fournissent un modèle de sécurité hybride tel que décrit dans Attaques Web connues, Attaques Web inconnueset Fonctionnement du pare-feu Web App. Il convient de noter la fonctionnalité d’apprentissage, qui observe le trafic vers vos applications protégées et recommande les paramètres de configuration appropriés pour certaines vérifications de sécurité.

La fonctionnalité d’importation gère les fichiers que vous téléchargez vers le Web App Firewall. Ces fichiers sont ensuite utilisés par le Web App Firewall dans divers contrôles de sécurité ou lors de la réponse à une connexion qui correspond à une vérification de sécurité.

Vous pouvez utiliser les fonctions de journaux, de statistiques et de rapports pour évaluer les performances du Web App Firewall et identifier les besoins possibles pour davantage de protections.

Comment Citrix Web Application Firewall modifie le trafic des applications

Citrix Web Application Firewall affecte le comportement d’une application Web qu’il protège en modifiant les éléments suivants :

• Cookies
• En-têtes HTTP
• Formulaires/Données

Cookie de session Citrix Web Application Firewall

Pour maintenir l’état de la session, Citrix ADC Web App Firewall génère son propre cookie de session. Ce cookie est transmis uniquement entre le navigateur Web et le pare-feu Citrix ADC Web Application et non au serveur Web. Si un pirate tente de modifier le cookie de session, le pare-feu d’application supprime le cookie avant de transférer la demande au serveur et traite la demande comme une nouvelle session utilisateur. Le cookie de session est présent tant que le navigateur Web est ouvert. Lorsque le navigateur Web est fermé, le cookie de session Application Firewall devient plus valide. L’état de la session conserve les informations des URL et formulaires visités par le client.

Le cookie de session de Web App Firewall configurable est citrix_ns_id.

À partir de Citrix ADC build 12.1 54 et 13.0, la cohérence des cookies est sans session et n’applique pas le cookie de session d’ajout citrix_ns_id généré par l’appliance.

Cookies Citrix Web App Firewall

De nombreuses applications Web génèrent des cookies pour suivre les informations spécifiques à l’utilisateur ou à la session. Ces informations peuvent être des préférences de l’utilisateur ou des articles de panier. Un cookie d’application Web peut être l’un des deux types suivants :

• Cookies persistants - Ces cookies sont stockés localement sur l’ordinateur et utilisés à nouveau la prochaine fois que vous visitez le site. Ce type de cookie contient généralement des informations sur l’utilisateur, telles que l’ouverture de session, le mot de passe ou les préférences.
• Cookies de session ou transitoires - Ces cookies ne sont utilisés que pendant la session et sont détruits après la fin de la session. Ce type de cookie contient des informations sur l’état de l’application, telles que les éléments du panier d’achat ou les informations d’identification de session.

Les pirates peuvent tenter de modifier ou de voler des cookies d’application pour détourner une session utilisateur ou se masquer en tant qu’utilisateur. Le pare-feu d’application empêche de telles tentatives en hachant les cookies de l’application, puis en ajoutant plus de cookies avec les signatures numériques. En traçant les cookies, le Pare-feu d’application garantit que les cookies ne sont pas modifiés ou compromis entre le navigateur client et le pare-feu d’application. Le Pare-feu d’application ne modifie pas les cookies de l’application.

Citrix Web Application Firewall génère les cookies par défaut suivants pour suivre les cookies d’application :

• Cookies persistants : citrix_ns_id_wlf. Note : wlf signifie vivra éternellement.
• Cookies de session ou transitoires : citrix_ns_id_wat. Note : wat signifie agir de façon transitoire. Pour suivre les cookies de l’application, le Pare-feu d’application regroupe les cookies persistants ou de session de l’application, puis hacher et signer tous les cookies ensemble. Ainsi, le Pare-feu d’application génère un wlf cookie pour suivre tous les cookies d’application persistants et un wat cookie pour suivre tous les cookies de session d’application.

Le tableau suivant indique le nombre et les types de cookies générés par l’Application Firewall sur la base des cookies générés par l’application web :

Citrix Web App Firewall permet de chiffrer le cookie d’application. Application Firewall offre également une option pour proxy le cookie de session envoyé par l’application, en le stockant avec le reste des données de session Application Firewall et en ne l’envoyant pas au client. Lorsqu’un client envoie une requête à l’application qui inclut un cookie de session Application Firewall, Application Firewall insère le cookie envoyé de nouveau dans la demande avant d’envoyer la demande à l’application d’origine. Application Firewall permet également d’ajouter les indicateurs HttpOnly et/ou Secure aux cookies.

Comment le pare-feu de l’application affecte les en-têtes HTTP

Les requêtes HTTPS et les réponses HTTPS utilisent des en-têtes pour envoyer des informations sur un ou plusieurs messages Https. Un en-tête est une série de lignes avec chaque ligne contenant un nom suivi d’un deux-points, d’un espace et d’une valeur. Par exemple, l’en-tête Host a le format suivant :

Host: www.citrix.com

Certains champs d’en-tête sont utilisés dans les en-têtes de requête et de réponse, tandis que d’autres ne conviennent qu’à une demande ou à une réponse. Le pare-feu d’application peut ajouter, modifier ou supprimer certains en-têtes dans une ou plusieurs requêtes HTTPS ou réponse afin de maintenir la sécurité de l’application.

En-têtes de requête supprimés par Citrix Web Application Firewall

La plupart des en-têtes de requête liés à la mise en cache sont supprimés pour afficher chaque requête dans le contexte d’une session. De même, si la demande inclut un en-tête de codage permettant au serveur Web d’envoyer des réponses compressées, le pare-feu d’application supprime cet en-tête de sorte que le contenu de la réponse du serveur non compressé soit inspecté par le Web App Firewall pour éviter toute fuite de données sensibles vers le client.

Le pare-feu d’application supprime les en-têtes de requête suivants :

• Range : permet de récupérer à partir d’un transfert de fichiers en échec ou partiel.
• If-Range — Permet à un client de récupérer un objet partiel lorsqu’il contient déjà une partie de cet objet dans son cache (GET conditionnel).
• If-Modified-Since — Si l’objet demandé n’est pas modifié depuis l’heure spécifiée dans ce champ, une entité n’est pas renvoyée par le serveur. Vous obtenez une erreur HTTP 304 non modifiée.
• If-Non-Match — Permet des mises à jour efficaces des informations mises en cache avec un minimum de frais généraux.
• Accept-Encoding — Quelles méthodes d’encodage sont autorisées pour un objet particulier, tel que gzip.

En-tête de demande modifié par Citrix Web Application Firewall

Si un navigateur Web utilise les protocoles HTTP/1.0 ou antérieurs, le navigateur ouvre et ferme continuellement la connexion socket TCP après avoir reçu chaque réponse. Cela ajoute une surcharge au serveur Web et empêche le maintien de l’état de session. Le protocole HTTP/1.1 permet à la connexion de rester ouverte pendant la session. Le pare-feu d’application modifie l’en-tête de requête suivant pour utiliser HTTP/1.1 entre le pare-feu d’application et le serveur Web, quel que soit le protocole utilisé par le navigateur Web : Connexion : keep-alive

En-têtes de requête ajoutés par Citrix Web Application Firewall

Le Pare-feu d’application agit comme un proxy inverse et remplace l’adresse IP source d’origine de la session par l’adresse IP du pare-feu d’application. Par conséquent, toutes les demandes enregistrées dans le journal du serveur Web indiquent que les demandes sont envoyées à partir du pare-feu d’application.

En-tête de réponse supprimé par Citrix Web Application Firewall

Le Pare-feu d’application peut bloquer ou modifier du contenu, comme la suppression des numéros de carte de crédit ou la suppression de commentaires, ce qui peut entraîner une inadéquation de la taille. Pour éviter un tel scénario, le pare-feu d’application supprime l’en-tête suivant :

Content-Length — Indique la taille du message envoyé au destinataire. En-têtes de réponse modifiés par le pare-feu d’application

La plupart des en-têtes de réponse modifiés par le pare-feu Application sont liés à la mise en cache. Les en-têtes de mise en cache dans les réponses HTTP (S) doivent être modifiés pour forcer le navigateur Web à toujours envoyer une requête au serveur Web pour obtenir les données les plus récentes et à ne pas utiliser le cache local. Toutefois, certaines applications ASP utilisent des plug-ins distincts pour afficher des contenus dynamiques et peuvent nécessiter la possibilité de mettre en cache temporairement les données dans le navigateur. Pour autoriser la mise en cache temporaire des données lorsque des protections avancées de sécurité telles que FFC, fermeture d’URL ou vérifications CSRF sont activées, Application Firewall ajoute ou modifie les en-têtes de contrôle de cache dans la réponse du serveur à l’aide de la logique suivante :

• Si Server envoie Pragma : no-cache, le pare-feu d’application n’effectue aucune modification.
• Si la requête client est HTTP 1.0, Application Firewall insère Pragma : no-cache.
• Si la requête client est HTTP 1.1 et a Cache-Control : no-store, Application Firewall n’apporte aucune modification.

• Si la requête client est HTTP 1.1 et que Server Response a un en-tête Cache-Control sans magasin ou aucune directive de cache, Application Firewall n’apporte aucune modification.

• Si la requête client est HTTP 1.1 et que la réponse du serveur n’a pas d’en-tête de contrôle Cache-Control ou l’en-tête Cache-Control n’a pas de directive magasin ou sans cache, le pare-feu d’application effectue les tâches suivantes :

1. Inserts Cache-control: max-age=3, must-revalidate,private.
2. Inserts X-Cache-Control-orig = Original value of Cache-Control Header.
3. Supprime l’en-tête Dernière modification.
4. Remplace Etag.
5. Insère X-Expires-Orig=Valeur d’origine de l’en-tête Expire envoyé par le serveur.
6. Modifie l’en-tête Expire et définit la date d’expiration de la page Web sur le passé, de sorte qu’elle est toujours récupérée à nouveau.
7. Modifie les plages Accept-Plages et la définit sur aucun.

Pour remplacer les données temporairement mises en cache dans le navigateur client lorsque Application Firewall modifie la réponse (par exemple, pour StripComments, X-out/Remove SafeObject, xout ou suppression de carte de crédit ou transformation d’URL), Application Firewall effectue les actions suivantes :

1. Supprime la dernière modification du serveur avant le transfert vers le client.
2. Remplace Etag par une valeur déterminée par Application Firewall.

En-têtes de réponse ajoutés par Citrix Web App Firewall

• Transfer-Encoding : Chunked. Cet en-tête transmet les informations à un client sans avoir à connaître la longueur totale de la réponse avant d’envoyer la réponse. Cet en-tête est obligatoire car l’en-tête de longueur de contenu est supprimé.
• Set-Cookie : les cookies ajoutés par le pare-feu d’application.
• Xet-Cookie : si la session est valide et si la réponse n’a pas expiré dans le cache, vous pouvez servir à partir du cache et n’avez pas à envoyer de nouveau cookie car la session est toujours valide. Dans un tel scénario, le Set-Cookie est changé en Xet-Cookie. Pour le navigateur Web.

Comment les données de formulaire sont affectées

Le pare-feu d’application protège contre les attaques qui tentent de modifier le contenu du formulaire original envoyé par le serveur. Il peut également se protéger contre les attaques de falsification de requête inter-site. Le pare-feu d’application effectue en insérant la balise de formulaire masquée as_fid dans la page.

Exemple : <input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />

Le champ masqué as_fid est utilisé pour la cohérence des champs. Ce champ est utilisé par Application Firewall pour suivre tous les champs du formulaire, y compris les paires nom/valeur des champs masqués et pour s’assurer qu’aucun des champs du formulaire envoyé par le serveur n’est modifié du côté client. La vérification CSRF utilise également cette balise de formulaire unique as_fid pour s’assurer que les formulaires soumis par l’utilisateur ont été servis à l’utilisateur dans cette session et qu’aucun pirate ne tente de détourner la session utilisateur.

Vérification du formulaire sans session

Application Firewall offre également une option pour protéger les données de formulaire en utilisant une cohérence de champ sans session. Ceci est utile pour les applications où les formulaires peuvent avoir un grand nombre de champs masqués dynamiques qui conduisent à une allocation de mémoire élevée par session par le pare-feu d’application. Le contrôle de cohérence des champs sans session est effectué en insérant un autre champ masqué as_ffc_field pour uniquement les requêtes POST ou pour les requêtes GET et POST en fonction du paramètre configuré. Le pare-feu d’application change la méthode GET en POST lorsqu’il transfère le formulaire au client. L’appliance rétablit ensuite la méthode GET lorsqu’elle est renvoyée au serveur. La valeur as_ffc_field peut être volumineuse car elle contient le résumé chiffré du formulaire servi. Voici un exemple de vérification de formulaire sans session :

<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />
<!--NeedCopy-->

Décapage des commentaires HTML

Le pare-feu d’application offre également une option pour supprimer tous les commentaires HTML dans les réponses avant de les envoyer au client. Cela affecte non seulement les formulaires, mais toutes les pages de réponses. Le Pare-feu d’application localise et supprime tout texte incorporé entre les balises de commentaire “<!-“ et “->”. Les balises restent pour indiquer qu’un commentaire existait à cet emplacement du code source HTML. Tout texte incorporé dans d’autres balises HTML ou JavaScript est ignoré. Certaines applications peuvent ne pas fonctionner correctement si JavaScript est incorrectement incorporé dans les balises de commentaire. Une comparaison du code source de la page avant et après que les commentaires ont été supprimés par Application Firewall peut aider à identifier si l’un des commentaires supprimés comportait le JavaScript requis intégré dans ces commentaires.

Protection des cartes de crédit

Le pare-feu d’application offre une option pour inspecter les en-têtes et le corps de la réponse et supprime ou élimine les numéros de carte de crédit avant de transférer la réponse au client. Actuellement Application Firewall offre une protection pour les principales cartes de crédit suivantes : American Express, Diners Club, Discover, JCB, MasterCard et Visa. L’action X-out fonctionne indépendamment de l’action Bloquer.

Protection sécurisée des objets

Comme pour les numéros de carte de crédit, la fuite d’autres données sensibles peut également être évitée en utilisant la vérification de sécurité Application Firewall Safe Object pour supprimer ou supprimer le contenu sensible dans la réponse.

Le script inter-site transforme l’action

Lorsque la transformation est activée pour le script intersite, le Web App Firewall change "<" into "%26lt;" and ">" into "%26gt;" dans les requêtes. Si le paramètre CheckRequestHeaders dans le Web App Firewall est activé, le pare-feu Web App inspecte les en-têtes de requête et transforme ces caractères dans En-tête et cookies également. L’action de transformation ne bloque ni ne transforme pas les valeurs initialement envoyées par le serveur. Il existe un ensemble d’attributs et de balises par défaut pour les scripts inter-sites que le Web App Firewall permet. Une liste par défaut des modèles de script intersite refusés est également fournie. Vous pouvez les personnaliser en sélectionnant l’objet signatures et en cliquant sur la boîte de dialogue Gérer les modèles de script SQL/inter-site dans l’interface graphique.

Transformation des caractères spéciaux SQL

Application Firewall possède les règles de transformation par défaut suivantes pour les caractères spéciaux SQL :

Lorsque la transformation des caractères spéciaux est activée et que le checkRequestHeaders est défini sur ON, la transformation des caractères spéciaux se produit également dans les en-têtes et les cookies. Remarque : Certains en-têtes de requête tels que User-Agent, Accept-Encoding contiennent généralement des points-virgules et peuvent être affectés par la transformation SQL.

Comportement Citrix Web Application Firewall dans lequel il corrompt l’en-tête EXPECT

1. Chaque fois que NetScaler reçoit une requête HTTP avec l’en-tête EXPECT, NetScaler envoie la réponse EXPECT: 100 -continue au client au nom du serveur back-end.
2. Ce problème est dû au fait que les protections du pare-feu d’application doivent être exécutées sur l’ensemble de la demande avant de transférer la demande au serveur, NetScaler doit obtenir la demande entière du client.
3. À la réception d’une 100 continue réponse, le client envoie la partie restante de la demande qui complète la demande.
4. NetScaler exécute ensuite toutes les protections, puis transmet la requête au serveur.
5. Maintenant que NetScaler transfère la requête complète, l’en-tête EXPECT qui provient de la requête initiale devient obsolète, ce qui entraîne l’altération de cet en-tête par Netscaler qui l’envoie au serveur.
6. Serveur à la réception de la demande ignore tout en-tête corrompu.