Présentation de NetScaler Web App Firewall

Le pare-feu NetScaler Web App Firewall prévient les failles de sécurité, les pertes de données et les éventuelles modifications non autorisées des sites Web qui accèdent à des informations commerciales ou clients sensibles. Pour ce faire, il filtre à la fois les demandes et les réponses, en les examinant pour détecter des preuves d’activité malveillante et en bloquant les demandes présentant une telle activité. Votre site est protégé non seulement contre les types d’attaques courants, mais également contre les nouvelles attaques encore inconnues. En plus de protéger les serveurs Web et les sites Web contre tout accès non autorisé, le Web App Firewall protège contre les vulnérabilités du code ou des scripts CGI existants, des frameworks Web, des logiciels de serveur Web et d’autres systèmes d’exploitation sous-jacents.

Le NetScaler Web App Firewall est disponible en tant qu’appliance autonome ou en tant que fonctionnalité sur une appliance virtuelle NetScaler (VPX). Dans la documentation du Web App Firewall, le terme NetScaler fait référence à la plate-forme sur laquelle le Web App Firewall s’exécute, qu’il s’agisse d’une appliance de pare-feu dédiée, d’un NetScaler sur lequel d’autres fonctionnalités ont également été configurées ou d’un NetScaler VPX.

Pour utiliser le Web App Firewall, vous devez créer au moins une configuration de sécurité afin de bloquer les connexions qui enfreignent les règles que vous avez définies pour vos sites Web protégés. Le nombre de configurations de sécurité que vous souhaiterez peut-être créer dépend de la complexité de votre site Web. Parfois, une seule configuration suffit. Dans d’autres cas, notamment 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 pouvez avoir besoin de plusieurs configurations différentes pour protéger au mieux les données sensibles sans gaspiller d’efforts importants sur du contenu non vulnérable à certains types d’attaques. Vous pouvez souvent laisser inchangées les valeurs par défaut des paramètres globaux, qui affectent toutes les configurations de sécurité. Vous pouvez toutefois modifier les paramètres généraux s’ils entrent 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é réseau des ordinateurs et des programmes qui communiquent à l’aide des protocoles HTTP et HTTPS. Il s’agit d’un vaste domaine dans lequel les failles et les faiblesses 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 des sites Web telles que 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 à l’exception du langage HTML le plus simple, y compris tout site permettant une interaction avec les visiteurs, présentent souvent leurs propres vulnérabilités.

Dans le passé, une faille de 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 informatique accédait à un serveur Web et apportait des modifications non autorisées (dégradant) un site Web étaient monnaie courante. Ils étaient généralement lancés par des pirates informatiques qui n’avaient d’autre motivation que de démontrer leurs compétences à d’autres pirates informatiques ou d’embarrasser la personne ou l’entreprise ciblée. La plupart des failles de sécurité actuelles sont toutefois motivées par un désir d’argent. La majorité d’entre eux tentent d’atteindre l’un ou l’autre des objectifs suivants, voire les deux : obtenir des informations privées sensibles et potentiellement précieuses, ou obtenir un accès non autorisé à un site Web ou à un serveur Web et le contrôle de celui-ci.

Certaines formes d’attaques 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 d’en prendre le contrôle total. Les informations qu’un attaquant peut obtenir à partir d’un site Web peuvent inclure les noms des clients, des adresses, des numéros de téléphone, des numéros de sécurité sociale, des numéros de carte de crédit, des dossiers médicaux et d’autres informations privées. L’attaquant peut ensuite utiliser ces informations ou les vendre à d’autres personnes. La plupart des informations obtenues par de telles attaques sont protégées par la loi, et toutes par les coutumes et les attentes. 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 d’autres personnes d’utiliser leurs cartes de crédit à mauvais escient, d’ouvrir des comptes de crédit non autorisés à leur nom ou de s’approprier purement et simplement leur identité (vol d’identité). Dans le pire des cas, les clients risquent d’être confrontés à des cotes de crédit ruinées ou même d’être accusés d’activités criminelles auxquelles ils n’ont pas participé.

D’autres attaques Web visent à prendre le contrôle (ou à compromettre) un site Web ou le serveur sur lequel il fonctionne, ou les deux. Un pirate informatique qui prend le contrôle d’un site Web ou d’un serveur peut l’utiliser pour héberger du contenu non autorisé, agir en tant que proxy pour le contenu hébergé sur un autre serveur Web, fournir des services SMTP pour envoyer des e-mails en masse non sollicités 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 font la promotion d’entreprises douteuses ou carrément frauduleuses. Par exemple, la plupart des sites Web de phishing et d’exploitation d’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 à plusieurs niveaux capable à la fois de bloquer les attaques connues présentant des caractéristiques identifiables et de vous protéger contre les attaques inconnues, qui peuvent souvent être détectées car leur apparence est différente du trafic normal vers vos sites Web et services Web.

Pour plus d’informations sur les contrôles de sécurité, consultez la section Présentation des contrôles de sécurité.

Attaques Web connues

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

• Attaques par débordement de la mémoire tampon. L’envoi d’une URL longue, d’un cookie long ou de longues informations à un serveur Web entraîne le blocage, le blocage du système ou l’accès non autorisé au système d’exploitation sous-jacent. Une attaque par débordement de la mémoire tampon peut être utilisée pour accéder à des informations non autorisées, pour compromettre un serveur Web, ou les deux.
• Attaques de sécurité liées aux cookies. Envoi d’un cookie modifié à un serveur Web, généralement dans l’espoir d’accéder à un contenu non autorisé en utilisant des informations d’identification falsifiées.
• Navigation forcée. Accès direct 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 qu’un utilisateur a ajouté une page à ses favoris sur votre site Web, mais les tentatives répétées d’accès à un contenu inexistant, ou à un contenu auquel les utilisateurs ne doivent jamais accéder directement, constituent souvent une atteinte à la sécurité du site Web. La navigation forcée est généralement utilisée pour accéder à des informations non autorisées, mais elle peut également être associée à une attaque par débordement de la mémoire tampon dans le but de compromettre votre serveur.
• Attaques de sécurité liées aux 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 à des 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 s’attend pas à recevoir dans ce formulaire Web. Une attaque de sécurité par formulaire Web peut être utilisée soit pour obtenir des informations non autorisées à partir de votre site Web, soit pour compromettre purement et simplement le site Web, généralement lorsqu’elle est associée à une attaque par débordement de la mémoire tampon.

Deux types d’attaques spécifiques visant 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 de faire en sorte qu’une base de données SQL exécute la ou les commandes. Les attaques par injection SQL sont généralement utilisées pour obtenir des informations non autorisées.
• Attaques par script intersite. Utilisation d’une URL ou d’un script sur une page Web pour enfreindre la stratégie d’origine identique, qui interdit à tout script d’obtenir des propriétés ou de modifier le contenu d’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 basés sur XML appartiennent généralement à au moins l’une des deux catégories suivantes : tentatives d’envoi de contenu inapproprié à un service Web ou tentatives de violation de la sécurité d’un service Web. Les types d’attaques les plus courants contre les services Web basés sur XML sont les suivants :

• Code ou objets malveillants. Requêtes XML contenant du code ou des objets susceptibles d’obtenir directement des informations sensibles ou de permettre à un attaquant de contrôler le service Web ou le 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 porter atteinte à la sécurité d’un service Web non sécurisé
• Attaques par déni de service (DoS). Requêtes XML qui sont envoyées à plusieurs reprises et en grand volume, dans le but de surcharger le service Web ciblé et de refuser aux utilisateurs légitimes l’accès au service Web.

Outre les attaques 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 de faire en sorte qu’une base de données SQL exécute cette ou ces commandes. Comme les attaques par injection HTML SQL, les attaques par injection XML SQL sont généralement utilisées pour obtenir des informations non autorisées.
• Attaques par script intersite. Utilisation d’un script inclus dans une application XML pour enfreindre la stratégie d’origine identique, qui interdit à tout script d’obtenir des propriétés ou de modifier le contenu d’une autre application. Étant donné que les scripts peuvent obtenir des informations et modifier des fichiers à l’aide de votre application XML, autoriser un script à accéder au contenu appartenant à une autre application peut permettre à un attaquant d’obtenir des informations non autorisées, de compromettre l’application, ou les deux

Les attaques Web connues peuvent généralement être bloquées en filtrant le trafic du site Web en fonction de 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 de nécessiter relativement peu de ressources et de présenter relativement peu de risques de faux positifs. Il s’agit donc d’un outil précieux pour lutter contre les attaques contre 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 se classent dans l’une des deux catégories suivantes : les attaques récemment lancées pour lesquelles les entreprises de sécurité n’ont pas encore développé de défense efficace (attaques de type « zero-day »), et les attaques soigneusement ciblées visant un site Web ou un service Web spécifique plutôt que de nombreux sites Web ou services Web (attaques de type spear). Ces attaques, comme les attaques connues, visent à obtenir des informations privées sensibles, à compromettre le site Web ou le service Web et à permettre leur utilisation pour d’autres attaques, ou à ces 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 zero-day impliquent souvent du SQL injecté, un script intersite, une falsification de requêtes intersites ou un autre type d’attaque similaire aux attaques connues. Ils ciblent généralement des vulnérabilités que les développeurs du logiciel, du site Web ou du service Web ciblé ignorent ou ont découvert. Les entreprises de sécurité n’ont donc pas développé de moyens de défense contre ces attaques et, même si c’est le cas, les utilisateurs n’ont pas obtenu et installé les correctifs ni mis en œuvre les solutions de contournement nécessaires pour se protéger contre ces attaques. Le délai entre la découverte d’une attaque de type « jour zéro » et la mise en place d’une défense (la fenêtre de vulnérabilité) est de plus en plus court, 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 à la lance constituent une menace majeure, mais elles concernent un groupe d’utilisateurs plus restreint. Un type courant d’attaque au harpon, le hameçonnage, vise les clients d’une banque ou d’une institution financière spécifique, ou (moins fréquemment) les employés d’une entreprise ou d’une organisation spécifique. Contrairement aux autres hameçonnage, qui sont souvent des contrefaçons rédigées de manière grossière et qu’un utilisateur familiarisé avec les communications de cette banque ou institution financière peut reconnaître, les hameçonnages sont parfaits et convaincants. Ils peuvent contenir des informations spécifiques à l’individu que, à première vue, aucun étranger ne doit connaître ou être en mesure d’obtenir. 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’attaques présentent 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. Le filtrage heuristique ne recherche pas des modèles spécifiques, mais des modèles de comportements. Les systèmes à modèle de sécurité positif 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 évaluent l’utilisation normale de vos sites Web, puis contrôlent la manière 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. La sécurité heuristique et positive, correctement conçue et déployée, permet de détecter la plupart des attaques que les signatures passent inaperçues. Cependant, elles nécessitent beaucoup plus de ressources que les signatures, et vous devez passer un certain 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.

Comment fonctionne NetScaler Web App 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 de signatures associé au profil.

Une signature est une chaîne ou un modèle qui correspond à un type d’attaque connu. Le Web App Firewall contient plus d’un millier de signatures réparties en sept catégories, chacune dirigée contre des attaques contre des types spécifiques de serveurs Web et de contenu Web. NetScaler met à jour la liste avec de nouvelles signatures à mesure que de nouvelles menaces sont identifiées. Lors de la configuration, vous spécifiez les catégories de signatures adaptées aux serveurs Web et au contenu que vous devez protéger. Les signatures fournissent une bonne protection de base avec une faible charge de traitement. Si vos applications présentent des vulnérabilités particulières ou si vous détectez une attaque contre 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é. Un contrôle de sécurité est une inspection algorithmique plus rigoureuse d’une demande visant à détecter des modèles ou des types de comportements spécifiques susceptibles d’indiquer une attaque ou de constituer une menace pour vos sites Web et services Web protégés. Il peut, par exemple, identifier une demande visant à effectuer un certain type d’opération susceptible de porter atteinte à la sécurité, ou une réponse contenant des informations privées 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 contrôles de sécurité adaptés aux serveurs Web et au contenu que vous devez protéger. Les contrôles de sécurité sont restrictifs. Nombre d’entre eux peuvent bloquer les demandes et les réponses légitimes si vous n’ajoutez pas les exceptions (assouplissements) appropriées 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 en tant que 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 hub ou le commutateur par lequel les utilisateurs accèdent à ces serveurs Web. Vous configurez ensuite le réseau pour envoyer 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 ensemble de règles internes 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. Organigramme du filtrage du Web App Firewall

Comme le montre 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, NetScaler Web App Firewall affiche l’objet d’erreur (une page Web située sur l’appliance Web App Firewall et que vous pouvez configurer à l’aide de la fonctionnalité d’importation) ou transmet la demande à l’URL d’erreur désignée (la page d’erreur). Les signatures ne nécessitent pas autant de ressources que les contrôles de sécurité. Par conséquent, la détection et l’arrêt des attaques détectées par une signature avant d’exécuter l’un des contrôles de sécurité réduisent la charge sur le serveur.

Si une demande passe l’inspection des signatures, le Web App Firewall applique les contrôles de sécurité des demandes qui ont été activés. Les contrôles de sécurité des demandes vérifient que la demande est appropriée pour votre site Web ou service Web et qu’elle ne contient aucun élément 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 à un contrôle de sécurité, le Web App Firewall nettoie la demande puis la renvoie à l’appliance NetScaler (ou à l’appliance virtuelle NetScaler) ou affiche l’objet d’erreur. Si la demande passe les contrôles de sécurité, elle est renvoyée à l’appliance NetScaler, qui termine tout autre traitement et transmet 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 contrôles de sécurité des réponses qui ont été activés. Les contrôles de sécurité des réponses examinent la réponse pour détecter les fuites d’informations privées sensibles, les signes de dégradation du site Web ou tout autre contenu qui ne doit pas être présent. Si la réponse échoue à un contrôle 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 passe les contrôles de sécurité, elle est renvoyée à l’appliance NetScaler, qui la transmet à l’utilisateur.

Fonctionnalités du pare-feu NetScaler Web App

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 chargez sur le Web App Firewall. Ces fichiers sont ensuite utilisés par le Web App Firewall lors de divers contrôles de sécurité ou lorsqu’il répond à une connexion qui correspond à un contrôle de sécurité.

Vous pouvez utiliser les fonctionnalités de journaux, de statistiques et de rapports pour évaluer les performances du Web App Firewall et identifier les besoins éventuels en matière de protections supplémentaires.

Comment NetScaler Web App Firewall modifie le trafic des applications

Le pare-feu NetScaler Web App 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 NetScaler Web App Firewall

Pour maintenir l’état de la session, NetScaler Web App Firewall génère son propre cookie de session. Ce cookie est transmis uniquement entre le navigateur Web et le pare-feu d’application Web NetScaler, et non au serveur Web. Si un pirate informatique tente de modifier le cookie de session, Web App Firewall le supprime avant de transmettre 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 invalide. L’état de la session conserve les informations relatives aux URL et aux formulaires visités par le client.

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

À partir des versions 12.1 54 et 13.0 de NetScaler, la cohérence des cookies est sans session et l’ajout du cookie de session citrix_ns_id généré par l’appliance n’est pas obligatoire. Pour plus d’informations sur la configuration des cookies, consultez la section Paramètres du moteur.

Cookies du pare-feu NetScaler Web App

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

• Cookies persistants - Ces cookies sont stockés localement sur l’ordinateur et réutilisés lors de votre prochaine visite sur le site. Ce type de cookie contient généralement des informations sur l’utilisateur, telles que son identifiant, son mot de passe ou ses 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 articles du panier ou les informations d’identification de session.

Les pirates informatiques peuvent tenter de modifier ou de voler des cookies d’applications pour pirater la session d’un utilisateur ou se faire passer pour un utilisateur. Le pare-feu d’application empêche de telles tentatives en hachant les cookies de l’application, puis en ajoutant d’autres cookies avec les signatures numériques. En suivant 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.

Le pare-feu NetScaler Web App Firewall génère les cookies par défaut suivants pour suivre les cookies de l’application :

• Cookies persistants : citrix_ns_id_wlf. Remarque : wlf est l’abréviation de Will Live Forever.
• Cookies de session ou transitoires : citrix_ns_id_wat. Remarque : ce qui signifie agira de manière transitoire. Pour suivre les cookies d’application, le pare-feu d’application regroupe les cookies d’application persistants ou de session, puis hache et signe 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 de l’application.

Le tableau suivant indique le nombre et les types de cookies générés par le pare-feu d’application en fonction des cookies générés par l’application Web :

NetScaler Web App Firewall permet de crypter le cookie de l’application. Le pare-feu d’application fournit également une option permettant de transmettre par proxy le cookie de session envoyé par l’application, en le stockant avec le reste des données de session du pare-feu d’application et en ne l’envoyant pas au client. Lorsqu’un client envoie à l’application une demande qui inclut un cookie de session Application Firewall, Application Firewall réinsère le cookie envoyé par l’application dans la demande avant de l’envoyer à l’application d’origine. Le pare-feu d’application 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 dont chaque ligne contient un nom suivi de 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 à la fois dans les en-têtes de demande 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 demandes ou réponses HTTPS afin de maintenir la sécurité de l’application.

En-têtes de requête supprimés par le NetScaler Web App Firewall

La plupart des en-têtes de demande liés à la mise en cache sont supprimés pour afficher chaque demande 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 des applications supprime cet en-tête afin que le contenu de la réponse non compressée du serveur soit inspecté par le Web App Firewall afin d’empêcher toute fuite de données sensibles vers le client.

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

• Plage : utilisée pour récupérer des données après un échec ou un transfert partiel de fichiers.
• 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, aucune entité n’est renvoyée par le serveur. Vous obtenez une erreur HTTP 304 non modifiée.
• If-None-Match : permet des mises à jour efficaces des informations mises en cache avec un minimum de surcharge.
• Accept-Encoding — Quelles méthodes de codage sont autorisées pour un objet particulier, tel que gzip.

En-tête de demande modifié par le NetScaler Web App Firewall

Si un navigateur Web utilise le protocole HTTP/1.0 ou une version antérieure, le navigateur ouvre et ferme continuellement la connexion au socket TCP après avoir reçu chaque réponse. Cela augmente la charge du serveur Web et empêche le maintien de l’état de la 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 demande suivant pour utiliser le protocole HTTP/1.1 entre le pare-feu d’applications 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 le NetScaler Web App 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 qu’elles sont envoyées depuis le pare-feu d’applications.

En-tête de réponse déposé par le NetScaler Web App Firewall

Le pare-feu des applications peut bloquer ou modifier du contenu, par exemple en supprimant des numéros de carte de crédit ou en supprimant des commentaires, ce qui peut entraîner une différence de taille. Pour éviter un tel scénario, le pare-feu d’applications supprime l’en-tête suivant :

Longueur du contenu : indique la taille du message envoyé au destinataire. En-têtes de réponse modifiés par le pare-feu de l’application

La plupart des en-têtes de réponse modifiés par le pare-feu d’applications sont liés à la mise en cache. Les en-têtes de mise en cache des réponses HTTP (S) doivent être modifiés pour obliger le navigateur Web à toujours envoyer une demande 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 temporairement les données en cache dans le navigateur. Pour autoriser la mise en cache temporaire des données lorsque des protections de sécurité avancées telles que la FFC, la fermeture d’URL ou les contrôles CSRF sont activées, Application Firewall ajoute ou modifie les en-têtes de contrôle du cache dans la réponse du serveur en utilisant la logique suivante :

• Si le serveur envoie Pragma : no-cache, le pare-feu des applications n’apporte aucune modification.
• Si la demande du client est HTTP 1.0, Application Firewall insère Pragma : no-cache.
• Si la demande du client est HTTP 1.1 et que le contrôle du cache est défini comme suit : no-store, Application Firewall n’apporte aucune modification.

• Si la demande du client est HTTP 1.1 et que la réponse du serveur comporte un en-tête Cache-Control sans directive de stockage ou sans cache, alors Application Firewall n’apporte aucune modification.

• Si la demande du client est HTTP 1.1 et que la réponse du serveur comporte un en-tête No Cache-Control ou que l’en-tête Cache-Control ne comporte aucune directive store ou no-cache, le pare-feu applicatif 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 de 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 Expires et fixe la date d’expiration de la page Web au passé, afin qu’elle soit toujours reprise.
7. Modifie Accept-Ranges et le définit sur None.

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 remove Credit Card ou URL Transform, Application Firewall prend les mesures suivantes :

1. Supprime la dernière modification du serveur avant de la transférer au client.
2. Remplace Etag par une valeur déterminée par Application Firewall.

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

• Transfer-Encoding : Chunked. Cet en-tête renvoie des informations à un client sans avoir à connaître la longueur totale de la réponse avant de l’envoyer. 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 de l’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 sans avoir à envoyer de nouveau cookie car la session est toujours valide. Dans un tel scénario, le Set-Cookie est remplacé par Xet-Cookie. Pour le navigateur Web.

Comment les données du formulaire sont-elles affectées

Le pare-feu d’application protège contre les attaques visant à modifier le contenu du formulaire original envoyé par le serveur. Il peut également vous protéger contre les attaques de falsification de requêtes intersites. Le pare-feu d’application y parvient 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 de champ masquées, et pour s’assurer qu’aucun des champs du formulaire envoyé par le serveur n’est modifié 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 lui ont été servis au cours de cette session et qu’aucun pirate informatique ne tente de pirater la session utilisateur.

Vérification des formulaires sans session

Application Firewall propose également une option pour protéger les données des formulaires grâce à la cohérence des champs sans session. Cela est utile pour les applications où les formulaires peuvent contenir un grand nombre de champs cachés dynamiques, ce qui entraîne une allocation de mémoire élevée par session par le pare-feu des applications. Le contrôle de cohérence des champs sans session est effectué en insérant un autre champ masqué as_ffc_field uniquement pour les requêtes POST ou pour les requêtes GET et POST en fonction du paramètre configuré. Le pare-feu d’application remplace la méthode GET par POST lorsqu’il transmet le formulaire au client. L’appliance rétablit ensuite la méthode en GET lorsqu’elle la renvoie au serveur. La valeur as_ffc_field peut être importante car elle contient le résumé crypté du formulaire diffusé. 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-->

Suppression des commentaires HTML

Le pare-feu d’application offre également la possibilité de supprimer tous les commentaires HTML contenus dans les réponses avant de les envoyer au client. Cela concerne non seulement les formulaires, mais également toutes les pages de réponses. Le pare-feu d’application localise et supprime tout texte intégré entre les balises de commentaire “<!-“ et “->”. Les balises sont conservées pour indiquer qu’un commentaire existait à cet emplacement du code source HTML. Tout texte intégré dans d’autres balises HTML ou JavaScript est ignoré. Certaines applications risquent de ne pas fonctionner correctement si le code JavaScript est incorrectement intégré dans les balises de commentaire. Une comparaison du code source de la page avant et après la suppression des commentaires par Application Firewall peut aider à déterminer si le code JavaScript requis était intégré à l’un des commentaires supprimés.

Protection par carte de crédit

Le pare-feu des applications offre la possibilité d’inspecter les en-têtes et le corps de la réponse et de supprimer ou de supprimer les numéros de carte de crédit avant de transmettre la réponse au client. À l’heure actuelle, Application Firewall protège 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ûre des objets

À l’instar des numéros de carte de crédit, la fuite d’autres données sensibles peut également être évitée en utilisant le contrôle de sécurité Safe Object d’Application Firewall pour supprimer ou masquer le contenu sensible de la réponse.

Les scripts intersites transforment l’action

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

Transformation de caractères spéciaux SQL

Application Firewall applique 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 du pare-feu NetScaler Web App qui altère l’en-tête EXPECT

1. Chaque fois que NetScaler reçoit une requête HTTP contenant l’en-tête EXPECT, NetScaler envoie la réponse EXPECT : 100 -continue au client au nom du serveur principal.
2. Ce comportement est dû au fait que les protections du pare-feu d’application doivent être exécutées sur l’intégralité de la demande avant de la transmettre au serveur. NetScaler doit obtenir l’intégralité de la demande 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 demande au serveur.
5. Maintenant que NetScaler transmet la requête complète, l’en-tête EXPECT qui figurait dans la demande initiale devient obsolète, car NetScaler corrompt cet en-tête et l’envoie au serveur.
6. Lors de la réception de la demande, le serveur ignore tout en-tête endommagé.