Vérification des scripts intersites HTML
La vérification Script intersite HTML (script intersite) examine à la fois les en-têtes et les corps POST des requêtes utilisateur pour détecter d’éventuelles attaques de script intersite. S’il trouve un script intersite, il modifie (transforme) la demande pour rendre l’attaque inoffensive ou bloque la demande.
Remarque :
La vérification Script intersite HTML (script intersite) fonctionne uniquement pour le type de contenu, la longueur du contenu, etc. Assurez-vous également que l’option « CheckRequestHeaders » est activée dans votre profil de pare-feu d’application Web.
Vous pouvez empêcher l’utilisation abusive des scripts sur vos sites Web protégés en utilisant les scripts de script intersite HTML qui enfreignent la même règle d’origine, qui stipule que les scripts ne doivent pas accéder au contenu ni le modifier sur aucun serveur, sauf le serveur sur lequel ils se trouvent. Tout script qui enfreint la même règle d’origine est appelé script intersite, et la pratique consistant à utiliser des scripts pour accéder ou modifier du contenu sur un autre serveur est appelée script intersite. La raison pour laquelle les scripts intersites constituent un problème de sécurité est qu’un serveur Web qui autorise le script intersite peut être attaqué à l’aide d’un script qui ne se trouve pas sur ce serveur Web, mais sur un autre serveur Web, tel qu’un serveur détenu et contrôlé par l’attaquant.
Malheureusement, de nombreuses entreprises disposent d’une importante base installée de contenu Web amélioré par JavaScript qui enfreint la même règle d’origine. Si vous activez la vérification de script intersite HTML sur un tel site, vous devez générer les exceptions appropriées afin que la vérification ne bloque pas les activités légitimes.
Le Web App Firewall propose diverses options d’action pour mettre en œuvre la protection par script intersite HTML. Outre les actions Bloquer, Consigner, Statistiques et Apprendre, vous avez également la possibilité de Transformer les scripts intersites afin de neutraliser une attaque par l’entité encodant les balises de script dans la demande soumise. Vous pouvez configurer le paramètre Vérifier les URL complètes pour le script intersite afin de spécifier si vous souhaitez inspecter non seulement les paramètres de requête, mais également l’URL complète pour détecter une attaque de script intersite. Vous pouvez configurer le paramètre InspectQueryContentTypes pour inspecter la partie requête de demande pour l’attaque de script intersite pour les types de contenu spécifiques.
Vous pouvez déployer des relaxations pour éviter les faux positifs. Le moteur d’apprentissage du Web App Firewall peut fournir des recommandations pour la configuration des règles de relaxation.
Pour configurer une protection par script intersite HTML optimisée pour votre application, configurez l’une des actions suivantes :
- Bloquer : si vous activez le blocage, l’action de blocage est déclenchée si les balises de script intersite sont détectées dans la demande.
- Journal : si vous activez la fonctionnalité de journal, la vérification de script intersite HTML génère des messages de journal indiquant les actions qu’elle entreprend. Si le blocage est désactivé, un message de journal distinct est généré pour chaque en-tête ou champ de formulaire dans lequel la violation de script intersite a été détectée. Toutefois, un seul message est généré lorsque la demande est bloquée. De même, 1 message de journal par demande est généré pour l’opération de transformation, même lorsque les balises de script intersite sont transformées dans plusieurs champs. Vous pouvez surveiller les journaux pour déterminer si les réponses aux demandes légitimes sont bloquées. Une forte augmentation du nombre de messages de journal peut indiquer des tentatives de lancement d’une attaque.
- Stats : si elle est activée, la fonctionnalité de statistiques collecte des statistiques sur les violations et les journaux. Une augmentation inattendue du compteur de statistiques peut indiquer que votre application est attaquée. Si des demandes légitimes sont bloquées, vous devrez peut-être revoir la configuration pour voir si vous devez configurer les nouvelles règles de relaxation ou modifier celles existantes.
- Learn—Si vous n’êtes pas sûr des règles de relaxation qui conviennent le mieux à votre application, vous pouvez utiliser la fonction d’apprentissage pour générer des recommandations de règles de script intersite HTML basées sur les données apprises. Le moteur d’apprentissage du Web App Firewall surveille le trafic et fournit des recommandations d’apprentissage basées sur les valeurs observées. Pour obtenir des avantages optimaux sans compromettre les performances, vous pouvez activer l’option d’apprentissage pendant une courte période afin d’obtenir un exemple représentatif des règles, puis déployer les règles et désactiver l’apprentissage.
-
Transformer les scripts intersites : si cette option est activée, le Web App Firewall apporte les modifications suivantes aux demandes qui correspondent à la vérification de script intersite HTML :
- Crochet angulaire gauche (<) en équivalent d’entité de caractères HTML (<)
- Crochet droit (>) en équivalent d’entité de caractères HTML (>)
Cela garantit que les navigateurs n’interprètent pas les balises HTML non sécurisées, telles que <script>, et exécutent ainsi du code malveillant. Si vous activez à la fois la vérification et la transformation des en-têtes de demande, tous les caractères spéciaux présents dans les en-têtes de demande sont également modifiés. Si les scripts de votre site Web protégé contiennent des fonctionnalités de script intersite, mais que votre site Web ne dépend pas de ces scripts pour fonctionner correctement, vous pouvez désactiver le blocage et activer la transformation en toute sécurité. Cette configuration garantit qu’aucun trafic Web légitime n’est bloqué, tout en arrêtant toute attaque de script intersite potentielle.
- Vérifiez les URL complètes pour les scripts intersites. Si la vérification des URL complètes est activée, le Web App Firewall examine les URL entières à la recherche d’attaques de script intersite HTML au lieu de vérifier uniquement les parties de requête des URL.
- Vérifiez les en-têtes de demande. Si la vérification des en-têtes de demande est activée, le Web App Firewall examine les en-têtes des demandes d’attaques de script intersite HTML, au lieu de simplement les URL. Si vous utilisez l’interface graphique, vous pouvez activer ce paramètre dans l’onglet Paramètres du profil Web App Firewall.
- InspectQueryContentTypes. Si l’inspection des requêtes par requête est configurée, App Firewall examine la requête des demandes d’attaques de script intersite pour les types de contenu spécifiques. Si vous utilisez l’interface graphique, vous pouvez configurer ce paramètre dans l’onglet Paramètres du profil App Firewall.
Important :
Dans le cadre des modifications apportées à la diffusion en continu, le traitement des balises de script intersite par le Web App Firewall a changé. Cette modification s’applique aux versions 11.0 et ultérieures. Cette modification est également pertinente pour les versions d’amélioration de la version 10.5.e qui prennent en charge la diffusion côté demande. Dans les versions précédentes, la présence d’un crochet ouvert (<), or close bracket (>) ou des deux crochets ouverts et fermants (<>) était signalée comme Violation de script intersite. Le comportement a changé dans les versions qui incluent la prise en charge du streaming côté demande. Seul le caractère de crochet fermé (>) n’est plus considéré comme une attaque. Les demandes sont bloquées même lorsqu’un caractère entre crochets ouverts (<) est présent, et sont considérées comme une attaque. L’attaque par script intersite est signalée.
Script intersite Relaxations affinées
Le Web App Firewall vous donne la possibilité d’exempter un champ de formulaire, un en-tête ou un cookie spécifique de la vérification d’inspection des scripts intersites. Vous pouvez complètement contourner l’inspection pour un ou plusieurs de ces champs en configurant les règles de relaxation.
Le Web App Firewall vous permet d’implémenter une sécurité plus stricte en affinant les règles de relaxation. Une application peut avoir besoin de flexibilité pour autoriser des modèles spécifiques, mais la configuration d’une règle d’assouplissement pour contourner l’inspection de sécurité peut rendre l’application vulnérable aux attaques, car le champ cible est exempté d’inspection pour tout modèle d’attaque par script intersite. La relaxation affinée des scripts intersites offre la possibilité d’autoriser des attributs, des balises et des modèles spécifiques. Les autres attributs, balises et modèles sont bloqués. Par exemple, le Web App Firewall possède actuellement un ensemble par défaut de plus de 125 modèles refusés. Étant donné que les pirates informatiques peuvent utiliser ces modèles dans des attaques de script intersites, le Web App Firewall les signale comme des menaces potentielles. Vous pouvez détendre un ou plusieurs modèles considérés comme sûrs pour un endroit spécifique. Les autres modèles de script intersite potentiellement dangereux sont toujours vérifiés pour l’emplacement cible et continuent de déclencher les violations du contrôle de sécurité. Vous avez maintenant un contrôle beaucoup plus serré.
Les commandes utilisées dans les relaxations ont des paramètres facultatifs pour Type de valeur et Expression de valeur. Le type de valeur peut être laissé vide ou vous avez la possibilité de sélectionner Balise, Attribut ou Motif. Si vous laissez le type de valeur vide, le champ configuré de l’URL spécifiée est exempté de l’inspection de vérification de script intersite. Si vous sélectionnez un type de valeur, vous devez fournir une expression de valeur. Vous pouvez spécifier si l’expression de valeur est une expression régulière ou une chaîne littérale. Lorsque l’entrée est mise en correspondance avec la liste autorisée et refusée, seules les expressions spécifiées configurées dans les règles de relaxation sont exemptées.
Le Web App Firewall possède les listes intégrées de script intersite suivantes :
- Attributs autorisés : 52 attributspar défaut sont autorisés, tels que, abbr, accesskey, align, alt, axis, bgcolor, border, remplissage de cellule, cellspacing, char, charoff, charset et ainsi de suite
- Balises autorisées : Il y a 47 balisesautorisées par défaut, telles que, address, basefont, bgsound, big, blockquote, bg, br, caption, center, **cite, **dd, del et ainsi de suite
- Modèles refusés de script intersite : Il existe 129 modèles refusés par défaut, tels que FSCommand, javascript :, OnAbort, OnActivate et ainsi de suite
Avertissement
Les URL d’action du Web App Firewall sont des expressions régulières. Lorsque vous configurez des règles de relaxation de script intersite HTML, vous pouvez spécifier Nameet Value Expression comme étant littéral ou RegEx. Les expressions régulières sont puissantes. Surtout si vous n’êtes pas très familier avec les expressions régulières au format PCRE, vérifiez toutes les expressions régulières que vous écrivez. Assurez-vous qu’ils définissent exactement la règle que vous souhaitez ajouter en tant qu’exception, et rien d’autre. L’utilisation imprudente de caractères génériques, et en particulier du métacaractère point-astérisque (.*) ou de la combinaison de caractères génériques, peut avoir des résultats indésirables, tels que le blocage de l’accès au contenu Web que vous n’aviez pas l’intention de bloquer ou l’autorisation d’une attaque que la vérification de script intersite HTML aurait autrement bloquée.
Points à considérer :
- L’expression de valeur est un argument facultatif. Le nom d’un champ peut ne pas comporter d’expression de valeur.
- Un nom de champ peut être lié à plusieurs expressions de valeur.
- Les expressions de valeur doivent se voir attribuer un type de valeur. Le type de valeur de script intersite peut être : 1) Balise, 2) Attribut ou 3) Modèle.
- Vous pouvez avoir plusieurs règles de relaxation par combinaison nom de champ/URL
- Les noms des champs de formulaire et les URL d’action ne sont pas sensibles à la casse.
Utilisation de la ligne de commande pour configurer la vérification de script intersite HTML
Pour configurer le script intersite HTML, les actions de vérification et d’autres paramètres à l’aide de la ligne de commande
Si vous utilisez l’interface de ligne de commande, vous pouvez entrer les commandes suivantes pour configurer la vérification de script inter-site HTML :
- définir le sujet du profil appfw .
<name> -crossSiteScriptingAction (([block] [learn] [log] [stats]) | [**none**])- [Définir le sujet du profil appfw.
<name> **-crossSiteScriptingTransformUnsafeHTML** (ON | OFF)- définir le sujet du profil appfw.
<name> -crossSiteScriptingCheckCompleteURLs (ON | OFF)- définir le sujet du profil appfw.
-
Vérification des scripts intersites HTML
La vérification Script intersite HTML (script intersite) examine à la fois les en-têtes et les corps POST des requêtes utilisateur pour détecter d’éventuelles attaques de script intersite. S’il trouve un script intersite, il modifie (transforme) la demande pour rendre l’attaque inoffensive ou bloque la demande.
Remarque :
La vérification Script intersite HTML (script intersite) fonctionne uniquement pour le type de contenu, la longueur du contenu, etc. Assurez-vous également que l’option « CheckRequestHeaders » est activée dans votre profil de pare-feu d’application Web.
Vous pouvez empêcher l’utilisation abusive des scripts sur vos sites Web protégés en utilisant les scripts de script intersite HTML qui enfreignent la même règle d’origine, qui stipule que les scripts ne doivent pas accéder au contenu ni le modifier sur aucun serveur, sauf le serveur sur lequel ils se trouvent. Tout script qui enfreint la même règle d’origine est appelé script intersite, et la pratique consistant à utiliser des scripts pour accéder ou modifier du contenu sur un autre serveur est appelée script intersite. La raison pour laquelle les scripts intersites constituent un problème de sécurité est qu’un serveur Web qui autorise le script intersite peut être attaqué à l’aide d’un script qui ne se trouve pas sur ce serveur Web, mais sur un autre serveur Web, tel qu’un serveur détenu et contrôlé par l’attaquant.
Malheureusement, de nombreuses entreprises disposent d’une importante base installée de contenu Web amélioré par JavaScript qui enfreint la même règle d’origine. Si vous activez la vérification de script intersite HTML sur un tel site, vous devez générer les exceptions appropriées afin que la vérification ne bloque pas les activités légitimes.
Le Web App Firewall propose diverses options d’action pour mettre en œuvre la protection par script intersite HTML. Outre les actions Bloquer, Consigner, Statistiques et Apprendre, vous avez également la possibilité de Transformer les scripts intersites afin de neutraliser une attaque par l’entité encodant les balises de script dans la demande soumise. Vous pouvez configurer le paramètre Vérifier les URL complètes pour le script intersite afin de spécifier si vous souhaitez inspecter non seulement les paramètres de requête, mais également l’URL complète pour détecter une attaque de script intersite. Vous pouvez configurer le paramètre InspectQueryContentTypes pour inspecter la partie requête de demande pour l’attaque de script intersite pour les types de contenu spécifiques.
Vous pouvez déployer des relaxations pour éviter les faux positifs. Le moteur d’apprentissage du Web App Firewall peut fournir des recommandations pour la configuration des règles de relaxation.
Pour configurer une protection par script intersite HTML optimisée pour votre application, configurez l’une des actions suivantes :
- Bloquer : si vous activez le blocage, l’action de blocage est déclenchée si les balises de script intersite sont détectées dans la demande.
- Journal : si vous activez la fonctionnalité de journal, la vérification de script intersite HTML génère des messages de journal indiquant les actions qu’elle entreprend. Si le blocage est désactivé, un message de journal distinct est généré pour chaque en-tête ou champ de formulaire dans lequel la violation de script intersite a été détectée. Toutefois, un seul message est généré lorsque la demande est bloquée. De même, 1 message de journal par demande est généré pour l’opération de transformation, même lorsque les balises de script intersite sont transformées dans plusieurs champs. Vous pouvez surveiller les journaux pour déterminer si les réponses aux demandes légitimes sont bloquées. Une forte augmentation du nombre de messages de journal peut indiquer des tentatives de lancement d’une attaque.
- Stats : si elle est activée, la fonctionnalité de statistiques collecte des statistiques sur les violations et les journaux. Une augmentation inattendue du compteur de statistiques peut indiquer que votre application est attaquée. Si des demandes légitimes sont bloquées, vous devrez peut-être revoir la configuration pour voir si vous devez configurer les nouvelles règles de relaxation ou modifier celles existantes.
- Learn—Si vous n’êtes pas sûr des règles de relaxation qui conviennent le mieux à votre application, vous pouvez utiliser la fonction d’apprentissage pour générer des recommandations de règles de script intersite HTML basées sur les données apprises. Le moteur d’apprentissage du Web App Firewall surveille le trafic et fournit des recommandations d’apprentissage basées sur les valeurs observées. Pour obtenir des avantages optimaux sans compromettre les performances, vous pouvez activer l’option d’apprentissage pendant une courte période afin d’obtenir un exemple représentatif des règles, puis déployer les règles et désactiver l’apprentissage.
-
Transformer les scripts intersites : si cette option est activée, le Web App Firewall apporte les modifications suivantes aux demandes qui correspondent à la vérification de script intersite HTML :
- Crochet angulaire gauche (<) en équivalent d’entité de caractères HTML (<)
- Crochet droit (>) en équivalent d’entité de caractères HTML (>)
Cela garantit que les navigateurs n’interprètent pas les balises HTML non sécurisées, telles que <!JEKYLL@5140@0>, et exécutent ainsi du code malveillant. Si vous activez à la fois la vérification et la transformation des en-têtes de demande, tous les caractères spéciaux présents dans les en-têtes de demande sont également modifiés. Si les scripts de votre site Web protégé contiennent des fonctionnalités de script intersite, mais que votre site Web ne dépend pas de ces scripts pour fonctionner correctement, vous pouvez désactiver le blocage et activer la transformation en toute sécurité. Cette configuration garantit qu’aucun trafic Web légitime n’est bloqué, tout en arrêtant toute attaque de script intersite potentielle.
- Vérifiez les URL complètes pour les scripts intersites. Si la vérification des URL complètes est activée, le Web App Firewall examine les URL entières à la recherche d’attaques de script intersite HTML au lieu de vérifier uniquement les parties de requête des URL.
- Vérifiez les en-têtes de demande. Si la vérification des en-têtes de demande est activée, le Web App Firewall examine les en-têtes des demandes d’attaques de script intersite HTML, au lieu de simplement les URL. Si vous utilisez l’interface graphique, vous pouvez activer ce paramètre dans l’onglet Paramètres du profil Web App Firewall.
- InspectQueryContentTypes. Si l’inspection des requêtes par requête est configurée, App Firewall examine la requête des demandes d’attaques de script intersite pour les types de contenu spécifiques. Si vous utilisez l’interface graphique, vous pouvez configurer ce paramètre dans l’onglet Paramètres du profil App Firewall.
Important :
Dans le cadre des modifications apportées à la diffusion en continu, le traitement des balises de script intersite par le Web App Firewall a changé. Cette modification s’applique aux versions 11.0 et ultérieures. Cette modification est également pertinente pour les versions d’amélioration de la version 10.5.e qui prennent en charge la diffusion côté demande. Dans les versions précédentes, la présence d’un crochet ouvert (<), or close bracket (>) ou des deux crochets ouverts et fermants (<>) était signalée comme Violation de script intersite. Le comportement a changé dans les versions qui incluent la prise en charge du streaming côté demande. Seul le caractère de crochet fermé (>) n’est plus considéré comme une attaque. Les demandes sont bloquées même lorsqu’un caractère entre crochets ouverts (<) est présent, et sont considérées comme une attaque. L’attaque par script intersite est signalée.
Script intersite Relaxations affinées
Le Web App Firewall vous donne la possibilité d’exempter un champ de formulaire, un en-tête ou un cookie spécifique de la vérification d’inspection des scripts intersites. Vous pouvez complètement contourner l’inspection pour un ou plusieurs de ces champs en configurant les règles de relaxation.
Le Web App Firewall vous permet d’implémenter une sécurité plus stricte en affinant les règles de relaxation. Une application peut avoir besoin de flexibilité pour autoriser des modèles spécifiques, mais la configuration d’une règle d’assouplissement pour contourner l’inspection de sécurité peut rendre l’application vulnérable aux attaques, car le champ cible est exempté d’inspection pour tout modèle d’attaque par script intersite. La relaxation affinée des scripts intersites offre la possibilité d’autoriser des attributs, des balises et des modèles spécifiques. Les autres attributs, balises et modèles sont bloqués. Par exemple, le Web App Firewall possède actuellement un ensemble par défaut de plus de 125 modèles refusés. Étant donné que les pirates informatiques peuvent utiliser ces modèles dans des attaques de script intersites, le Web App Firewall les signale comme des menaces potentielles. Vous pouvez détendre un ou plusieurs modèles considérés comme sûrs pour un endroit spécifique. Les autres modèles de script intersite potentiellement dangereux sont toujours vérifiés pour l’emplacement cible et continuent de déclencher les violations du contrôle de sécurité. Vous avez maintenant un contrôle beaucoup plus serré.
Les commandes utilisées dans les relaxations ont des paramètres facultatifs pour Type de valeur et Expression de valeur. Le type de valeur peut être laissé vide ou vous avez la possibilité de sélectionner Balise, Attribut ou Motif. Si vous laissez le type de valeur vide, le champ configuré de l’URL spécifiée est exempté de l’inspection de vérification de script intersite. Si vous sélectionnez un type de valeur, vous devez fournir une expression de valeur. Vous pouvez spécifier si l’expression de valeur est une expression régulière ou une chaîne littérale. Lorsque l’entrée est mise en correspondance avec la liste autorisée et refusée, seules les expressions spécifiées configurées dans les règles de relaxation sont exemptées.
Le Web App Firewall possède les listes intégrées de script intersite suivantes :
- Attributs autorisés : 52 attributspar défaut sont autorisés, tels que, abbr, accesskey, align, alt, axis, bgcolor, border, remplissage de cellule, cellspacing, char, charoff, charset et ainsi de suite
- Balises autorisées : Il y a 47 balisesautorisées par défaut, telles que, address, basefont, bgsound, big, blockquote, bg, br, caption, center, **cite, **dd, del et ainsi de suite
- Modèles refusés de script intersite : Il existe 129 modèles refusés par défaut, tels que FSCommand, javascript :, OnAbort, OnActivate et ainsi de suite
Avertissement
Les URL d’action du Web App Firewall sont des expressions régulières. Lorsque vous configurez des règles de relaxation de script intersite HTML, vous pouvez spécifier Nameet Value Expression comme étant littéral ou RegEx. Les expressions régulières sont puissantes. Surtout si vous n’êtes pas très familier avec les expressions régulières au format PCRE, vérifiez toutes les expressions régulières que vous écrivez. Assurez-vous qu’ils définissent exactement la règle que vous souhaitez ajouter en tant qu’exception, et rien d’autre. L’utilisation imprudente de caractères génériques, et en particulier du métacaractère point-astérisque (.*) ou de la combinaison de caractères génériques, peut avoir des résultats indésirables, tels que le blocage de l’accès au contenu Web que vous n’aviez pas l’intention de bloquer ou l’autorisation d’une attaque que la vérification de script intersite HTML aurait autrement bloquée.
Points à considérer :
- L’expression de valeur est un argument facultatif. Le nom d’un champ peut ne pas comporter d’expression de valeur.
- Un nom de champ peut être lié à plusieurs expressions de valeur.
- Les expressions de valeur doivent se voir attribuer un type de valeur. Le type de valeur de script intersite peut être : 1) Balise, 2) Attribut ou 3) Modèle.
- Vous pouvez avoir plusieurs règles de relaxation par combinaison nom de champ/URL
- Les noms des champs de formulaire et les URL d’action ne sont pas sensibles à la casse.
Utilisation de la ligne de commande pour configurer la vérification de script intersite HTML
Pour configurer le script intersite HTML, les actions de vérification et d’autres paramètres à l’aide de la ligne de commande
Si vous utilisez l’interface de ligne de commande, vous pouvez entrer les commandes suivantes pour configurer la vérification de script inter-site HTML :
- définir le sujet du profil appfw .
- <!JEKYLL@5140@1>
- [Définir le sujet du profil appfw.
- <!JEKYLL@5140@2>
- définir le sujet du profil appfw.
- <!JEKYLL@5140@3>
- définir le sujet du profil appfw.