-
-
Configuration de Citrix ADC pour Citrix Virtual Apps and Desktops
-
Préférence de zone optimisée pour l'équilibrage de la charge du serveur global (GSLB)
-
Déploiement d'une plateforme de publicité numérique sur AWS avec Citrix ADC
-
Amélioration de l'analyse des flux de clics dans AWS à l'aide de Citrix ADC
-
Citrix ADC dans un cloud privé géré par Microsoft Windows Azure Pack et Cisco ACI
-
-
Déployer une instance de Citrix ADC VPX sur AWS
-
Installer une instance Citrix ADC VPX sur le cloud VMware sur AWS
-
Installer une instance Citrix ADC VPX sur des serveurs Microsoft Hyper-V
-
Installer une instance Citrix ADC VPX sur la plate-forme Linux-KVM
-
Provisionnement de l'appliance virtuelle Citrix ADC à l'aide d'OpenStack
-
Provisionnement de l'appliance virtuelle Citrix ADC à l'aide de Virtual Machine Manager
-
Configuration des appliances virtuelles Citrix ADC pour utiliser l'interface réseau SR-IOV
-
Configuration des appliances virtuelles Citrix ADC pour utiliser l'interface réseau PCI
-
Provisioning de l'appliance virtuelle Citrix ADC à l'aide du programme virsh
-
Provisioning de l'appliance virtuelle Citrix ADC avec SR-IOV, sur OpenStack
-
Configuration d'une instance Citrix ADC VPX sur KVM pour utiliser les interfaces hôtes OVS DPDK
-
Déployer une instance de Citrix ADC VPX sur AWS
-
Serveurs d'équilibrage de charge dans différentes zones de disponibilité
-
Haute disponibilité dans toutes les zones de disponibilité AWS
-
Déployer une paire VPX haute disponibilité avec des adresses IP privées dans différentes zones AWS
-
Ajout d'un service de mise à l'échelle automatique AWS back-end
-
Configurer une instance Citrix ADC VPX pour utiliser l'interface réseau SR-IOV
-
Configurer une instance Citrix ADC VPX pour utiliser la mise en réseau améliorée avec AWS ENA
-
Déployer une instance de Citrix ADC VPX sur Microsoft Azure
-
Architecture réseau pour les instances Citrix ADC VPX sur Microsoft Azure
-
Configurer plusieurs adresses IP pour une instance autonome Citrix ADC VPX
-
Configurer une configuration haute disponibilité avec plusieurs adresses IP et cartes réseau
-
Configurer une instance Citrix ADC VPX pour utiliser la mise en réseau accélérée Azure
-
Configurer les nœuds HA-INC à l'aide du modèle de haute disponibilité Citrix avec Azure ILB
-
Ajouter des paramètres de mise à l'échelle automatique Azure
-
Configurer GSLB sur une configuration haute disponibilité active en veille
-
Configurer des pools d'adresses (IIP) pour une appliance Citrix Gateway
-
Scripts PowerShell supplémentaires pour le déploiement Azure
-
Déployer une instance Citrix ADC VPX sur Google Cloud Platform
-
Déployer une paire haute disponibilité VPX sur Google Cloud Platform
-
Déployer une paire VPX haute disponibilité avec des adresses IP privées sur Google Cloud Platform
-
Ajouter un service de mise à l'échelle automatique GCP back-end
-
Prise en charge de la mise à l'échelle VIP pour l'instance Citrix ADC VPX sur GCP
-
-
Automatiser le déploiement et les configurations de Citrix ADC
-
Solutions pour les fournisseurs de services de télécommunication
-
Trafic de plan de contrôle d'équilibrage de charge basé sur les protocoles Diameter, SIP et SMPP
-
Utilisation de la bande passante à l'aide de la fonctionnalité de redirection de cache
-
Optimisation TCP de Citrix ADC
-
Authentification, autorisation et audit du trafic des applications
-
Fonctionnement de l'authentification, de l'autorisation et de l'audit
-
Composants de base de la configuration d'authentification, d'autorisation et d'audit
-
Autorisation de l'accès des utilisateurs aux ressources applicatives
-
Citrix ADC en tant que proxy du service de fédération Active Directory
-
Citrix Gateway sur site en tant que fournisseur d'identité pour Citrix Cloud
-
Prise en charge de la configuration de l'attribut de cookie SameSite
-
Configuration d'authentification, d'autorisation et d'audit pour les protocoles couramment utilisés
-
Résoudre les problèmes liés à l'authentification et à l'autorisation
-
-
-
Prise en charge de la configuration Citrix ADC dans la partition d'administration
-
Prise en charge de VXLAN pour les partitions d'administration
-
Prise en charge de SNMP pour les partitions d'administration
-
Prise en charge des journaux d'audit pour les partitions d'administration
-
Afficher les adresses PMAC configurées pour la configuration VLAN partagée
-
-
-
-
Configuration de l'expression de stratégie avancée : Mise en route
-
Expressions de stratégie avancées : utilisation de dates, d'heures et de nombres
-
Expressions de stratégie avancées : analyse des données HTTP, TCP et UDP
-
Expressions de stratégie avancées : analyse des certificats SSL
-
Expressions de stratégie avancées : adresses IP et MAC, débit, ID VLAN
-
Expressions de stratégie avancées : fonctions d'analyse de flux
-
Référence aux expressions - Expressions de stratégie avancées
-
Résumé d'exemples d'expressions et de stratégies de syntaxe par défaut
-
Didacticiel exemples de stratégies de syntaxe par défaut pour la réécriture
-
Migration des règles Apache mod_rewrite vers la syntaxe par défaut
-
-
-
-
Vérification des scripts de site à site HTML
-
Prise en charge du pare-feu d'application pour Google Web Toolkit
-
-
Vérifications de protection XML
-
-
Traduire l'adresse IP de destination d'une requête vers l'adresse IP d'origine
-
-
Prise en charge de la configuration de Citrix ADC dans un cluster
-
-
-
Groupes de nœuds pour les configurations spotted et striped partielles
-
Suppression du nœud d'un cluster déployé à l'aide de l'agrégation de liens de cluster
-
Surveillance des itinéraires pour les itinéraires dynamiques dans le cluster
-
Surveillance de la configuration du cluster à l'aide de MIB SNMP avec liaison SNMP
-
Surveillance des échecs de propagation des commandes dans un déploiement de cluster
-
Prise en charge de MSR pour les nœuds inactifs dans une configuration de cluster spotted
-
Liaison d'interface VRRP dans un cluster actif à nœud unique
-
Scénarios de configuration et d'utilisation du cluster
-
Migration d'une configuration HA vers une configuration de cluster
-
Interfaces communes pour le client et le serveur et interfaces dédiées pour le backplane
-
Commutateur commun pour le client, le serveur et le backplane
-
Commutateur commun pour le client et le serveur et commutateur dédié pour le backplane
-
Services de surveillance dans un cluster à l'aide de la surveillance des chemins
-
Opérations prises en charge sur des nœuds de cluster individuels
-
-
-
Configurer les enregistrements de ressources DNS
-
Créer des enregistrements MX pour un serveur d'échange de messagerie
-
Créer des enregistrements NS pour un serveur faisant autorité
-
Créer des enregistrements NAPTR pour le domaine des télécommunications
-
Créer des enregistrements PTR pour les adresses IPv4 et IPv6
-
Créer des enregistrements SOA pour les informations faisant autorité
-
Créer des enregistrements TXT pour contenir du texte descriptif
-
Configurer Citrix ADC en tant que résolveur de stub adapté à la sécurité sans validation
-
Prise en charge des trames Jumbo pour DNS pour gérer les réponses de grandes tailles
-
Configurer la mise en cache négative des enregistrements DNS
-
-
Équilibrage de charge globale des serveurs
-
Configurer les entités GSLB individuellement
-
Cas d'utilisation : Déploiement d'un groupe de services d'échelle automatique basé sur l'adresse IP
-
-
Remplacer le comportement de proximité statique en configurant les emplacements préférés
-
Configurer la sélection du service GSLB à l'aide du changement de contenu
-
Configurer GSLB pour les requêtes DNS avec les enregistrements NAPTR
-
Exemple de configuration parent-enfant complète à l'aide du protocole d'échange de mesures
-
-
Équilibrer la charge du serveur virtuel et des états de service
-
Protéger une configuration d'équilibrage de charge contre les défaillances
-
-
Configurer des serveurs virtuels d'équilibrage de charge sans session
-
Réécriture des ports et des protocoles pour la redirection HTTP
-
Insérer l'adresse IP et le port d'un serveur virtuel dans l'en-tête de requête
-
Utiliser une adresse IP source spécifiée pour la communication backend
-
Définir une valeur de délai d'attente pour les connexions client inactives
-
Utiliser un port source à partir d'une plage de ports spécifiée pour la communication backend
-
Configurer la persistance de l'IP source pour les communications backend
-
-
Paramètres avancés d'équilibrage de charge
-
Protéger les applications sur les serveurs protégés contre les surtensions de trafic
-
Activer le nettoyage des connexions de serveur virtuel et de service
-
Activer ou désactiver la session de persistance sur les services TROFS
-
Activer la vérification de l'état TCP externe pour les serveurs virtuels UDP
-
Maintenir la connexion client pour plusieurs demandes client
-
Utiliser l'adresse IP source du client lors de la connexion au serveur
-
Définir une limite de nombre de requêtes par connexion au serveur
-
Définir une valeur de seuil pour les moniteurs liés à un service
-
Définir une valeur de délai d'attente pour les connexions client inactives
-
Définir une valeur de délai d'attente pour les connexions au serveur inactif
-
Définir une limite sur l'utilisation de la bande passante par les clients
-
Configurer les moniteurs dans une configuration d'équilibrage de charge
-
Configurer l'équilibrage de charge pour les protocoles couramment utilisés
-
Cas d'utilisation 3 : Configurer l'équilibrage de charge en mode de retour direct du serveur
-
Cas d'utilisation 4 : Configurer les serveurs LINUX en mode DSR
-
Cas d'utilisation 5 : Configurer le mode DSR lors de l'utilisation de TOS
-
Cas d'utilisation 7 : Configurer l'équilibrage de charge en mode DSR à l'aide d'IP sur IP
-
Cas d'utilisation 8 : Configurer l'équilibrage de charge en mode à un bras
-
Cas d'utilisation 9 : Configurer l'équilibrage de charge en mode Inline
-
Cas d'utilisation 10 : Équilibrage de la charge des serveurs du système de détection d'intrusion
-
Cas d'utilisation 11 : Isolation du trafic réseau à l'aide de stratégies d'écoute
-
Cas d'utilisation 12 : Configurer XenDesktop pour l'équilibrage de charge
-
Cas d'utilisation 13 : Configurer XenApp pour l'équilibrage de charge
-
Cas d'utilisation 14 : Assistant ShareFile pour l'équilibrage de charge Citrix ShareFile
-
-
Configurer pour source de trafic de données Citrix ADC FreeBSD à partir d'une adresse SNIP
-
Déchargement et accélération SSL
-
Prise en charge du protocole TLSv1.3 tel que défini dans la RFC 8446
-
Suites de chiffrement disponibles sur les appliances Citrix ADC
-
Matrice de prise en charge des certificats de serveur sur l'appliance ADC
-
Prise en charge du module de sécurité matérielle du réseau Gemalto SafeNet
-
-
-
-
Authentification et autorisation pour les utilisateurs du système
-
Configuration des utilisateurs, des groupes d'utilisateurs et des stratégies de commande
-
Réinitialisation du mot de passe administrateur par défaut (nsroot)
-
Configuration de l'authentification des utilisateurs externes
-
Authentification basée sur la clé SSH pour les administrateurs Citrix ADC
-
Authentification à deux facteurs pour les utilisateurs système
-
-
-
Configuration d'un tunnel de connecteur CloudBridge entre deux centres de données
-
Configuration de CloudBridge Connector entre Datacenter et AWS Cloud
-
Configuration d'un tunnel de connecteur CloudBridge entre un centre de données et Azure Cloud
-
Configuration du tunnel Connector CloudBridge entre Datacenter et SoftLayer Enterprise Cloud
-
-
Points à prendre en considération pour une configuration de haute disponibilité
-
Restriction du trafic de synchronisation haute disponibilité à un VLAN
-
Configuration des nœuds haute disponibilité dans différents sous-réseaux
-
Limitation des basculements causés par les moniteurs de routage en mode non-INC
-
Comprendre le calcul de la vérification de l'état de haute disponibilité
-
Gestion des messages de pulsation haute disponibilité sur une appliance Citrix ADC
-
Suppression et remplacement d'un Citrix ADC dans une configuration haute disponibilité
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已动态机器翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.
Este artigo foi traduzido automaticamente.
这篇文章已经过机器翻译.放弃
Translation failed!
Vérification des scripts inter-sites HTML
La vérification HTML Cross-Site Scripting (script inter-site) examine à la fois les en-têtes et les corps POST des requêtes utilisateur pour détecter d’éventuelles attaques de script inter-sites. S’il trouve un script intersite, il modifie (transforme) la requête pour rendre l’attaque inoffensive, ou bloque la requête.
Remarque :
La vérification de script inter-site HTML (script inter-site) ne fonctionne que pour le type de contenu, la longueur du contenu, etc. Cela ne fonctionne pas pour le cookie. 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 inter-site HTML qui enfreignent la même règle d’origine, qui stipule que les scripts ne doivent ni accéder ni modifier du contenu sur un 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 le script inter-site est un problème de sécurité est qu’un serveur Web qui autorise le script inter-site peut être attaqué avec 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 grande base installée de contenu Web amélioré par Javascript-qui viole la même règle d’origine. Si vous activez la vérification HTML Cross-Site Scripting sur un tel site, vous devez générer les exceptions appropriées afin que la vérification ne bloque pas l’activité légitime.
Le Web App Firewall offre diverses options d’action pour implémenter la protection HTML cross-site Scripting. En plus des actions Block, Log, Statset Apprendre, vous avez également la possibilité de transformer des scripts intersitespour rendre une attaque inoffensive en codant les balises de script dans la demande soumise. Vous pouvez configurer Vérifier les URL complètes pour le paramètre de script inter-site pour spécifier si vous souhaitez inspecter non seulement les paramètres de requête, mais l’URL entière pour détecter les attaques de script inter-sites. Vous pouvez configurer le paramètre InspectQueryContentTypes pour inspecter la partie requête de requête pour l’attaque de script inter-site 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 optimisée par script multisite HTML pour votre application, configurez l’une des actions suivantes :
- Bloc—Si vous activez le bloc, l’action de blocage est déclenchée si les balises de script intersite sont détectées dans la requête.
- Journal : si vous activez la fonction de journal, le contrôle HTML Cross-Site Scripting génère des messages de journal indiquant les actions qu’il effectue. Si le bloc 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, un message de journal par requête est généré pour l’opération de transformation, même lorsque les balises de script intersite sont transformées en 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.
- Statistiques : si cette option est activée, la fonction de statistiques recueille des statistiques sur les violations et les journaux. Une augmentation inattendue du compteur de statistiques peut indiquer que votre application est attaquée. Si les demandes légitimes sont bloquées, vous devrez peut-être revoir la configuration pour voir si vous devez configurer de nouvelles règles de relaxation ou modifier les règles existantes.
- Learn—Si vous n’êtes pas sûr des règles de relaxation qui conviennent parfaitement à votre application, vous pouvez utiliser la fonctionnalité d’apprentissage pour générer des recommandations de règles de script inter-site 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 un avantage optimal sans compromettre les performances, vous pouvez activer l’option d’apprentissage pendant une courte période afin d’obtenir un échantillon 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 inter-site HTML :
- Crochet d’angle gauche (<) à l’équivalent d’entité de caractères HTML (<)
- Angle droit (>) à l’équivalent d’entité de caractères HTML (>)
Cela garantit que les navigateurs n’interprètent pas les balises html dangereuses, telles que <script>
, et exécutent ainsi du code malveillant. Si vous activez à la fois la vérification et la transformation de l’en-tête de demande, tous les caractères spéciaux trouvés dans les en-têtes de requête 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 s’appuie pas sur 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 inter-sites. Si la vérification des URL complètes est activée, le Web App Firewall examine des URL entières pour les attaques de script inter-sites HTML au lieu de vérifier uniquement les parties de requête des URL.
- Cochez les en-têtes de requête. Si la vérification des en-têtes de requête est activée, le Web App Firewall examine les en-têtes des requêtes pour les attaques de script inter-sites HTML, au lieu de se contenter d’URL. Si vous utilisez l’interface graphique, vous pouvez activer ce paramètre dans l’onglet Paramètres du profil Pare-feu de l’application Web.
- InspectQueryContentTypes. Si l’inspection des requêtes de requête est configurée, le pare-feu d’application 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 Pare-feu de l’application.
Important :
Dans le cadre des modifications de diffusion en continu, le traitement du Web App Firewall des balises de script inter-site a changé. Cette modification s’applique aux versions 11.0 ultérieures. Cette modification est également pertinente pour les versions d’amélioration de 10.5.e qui prennent en charge le streaming côté demande. Dans les versions antérieures, la présence de crochets ouverts (<), or close bracket (>) ou de crochets ouverts et fermément (<>) était marquée comme violation de script inter-site. Le comportement a changé dans les versions qui incluent la prise en charge de la diffusion côté demande. Seul le caractère rapproché (>) n’est plus considéré comme une attaque. Les requêtes sont bloquées même lorsqu’un caractère entre crochets ouverts (<) est présent et est considéré comme une attaque. L’attaque de script inter-site est signalée.
Scripting inter-site Relaxations à grain fin
Le Web App Firewall vous permet d’exempter un champ de formulaire, un en-tête ou un cookie spécifique de la vérification de l’inspection des scripts intersites. Vous pouvez contourner complètement l’inspection d’un ou plusieurs de ces champs en configurant des 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 nécessiter la flexibilité nécessaire pour autoriser des modèles spécifiques, mais la configuration d’une règle de relaxation pour contourner l’inspection de sécurité peut rendre l’application vulnérable aux attaques, car le champ cible est exempté de l’inspection pour tout modèle d’attaque de script intersite. La relaxation fine de script inter-site permet d’autoriser des attributs, des balises et des motifs spécifiques. Les autres attributs, balises et motifs sont bloqués. Par exemple, le Web App Firewall dispose actuellement d’un ensemble par défaut de plus de 125 modèles refusés. Étant donné que les pirates peuvent utiliser ces modèles dans des attaques de script inter-sites, le Web App Firewall les signale comme des menaces potentielles. Vous pouvez vous détendre un ou plusieurs modèles considérés comme sûrs pour l’emplacement spécifique. Le reste des modèles de script inter-sites potentiellement dangereux sont toujours vérifiés pour l’emplacement cible et continuent à déclencher les violations des contrôles 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 inter-site. 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 comporte les listes intégrées suivantes de scripts inter-sites :
- script inter-site Attributs autorisés : Il existe 52 attributs autorisés par défaut, tels que, abbr, accesskey, align, alt, axis, bgcolor, border, cell padding, cell spacing, char, charoff, charset et ainsi de suite
- script inter-site balises autorisées : Il y a 47 balises autorisées par défaut, telles que, address, basefont, bgsound, big, blockquote, bg, br, légende, center, **cite, **dd, del et ainsi de suite
- Script inter-site Refusé Patterns : Il y a 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 inter-site HTML, vous pouvez spécifier Nomet Expression de valeurcomme étant littérale ou RegEx. Les expressions régulières sont puissantes. Surtout si vous n’êtes pas familier avec les expressions régulières au format PCRE, vérifiez 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 négligente des caractères génériques, et en particulier de la combinaison de métacaractres/caractères génériques (.*), peut avoir des résultats que vous ne voulez pas, comme bloquer l’accès au contenu Web que vous n’aviez pas l’intention de bloquer ou autoriser une attaque que la vérification de script inter-site HTML aurait autrement bloquée.
Points à considérer :
- L’expression de valeur est un argument facultatif. Un nom de champ peut ne pas avoir d’expression de valeur.
- Un nom de champ peut être lié à plusieurs expressions de valeur.
- Un type de valeur doit être affecté aux expressions de valeur. Le type de valeur de script inter-site peut être : 1) Tag, 2) Attribut ou 3) Pattern.
- Vous pouvez avoir plusieurs règles de relaxation par combinaison nom/URL de champ
- 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 HTML cross-site Scripting
Pour configurer les actions de vérification HTML Cross-Site Scripting 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 profil appfw “Description des paramètres fournie en bas de la page.”)
<name> -crossSiteScriptingAction (([block] [learn] [log] [stats]) | [**none**])
- définir le profil appfw “Description des paramètres fournie en bas de la page.”)
<name> **-crossSiteScriptingTransformUnsafeHTML** (ON | OFF)
- définir le profil appfw Description des paramètres fournie en bas de la page.
<name> -crossSiteScriptingCheckCompleteURLs (ON | OFF)
- définir le profil appfw Description des paramètres fournie en bas de la page.
-
<name> - checkRequestHeaders (ON | OFF)
Description des paramètres fournie en bas de la page.” -
<name> - CheckRequestQueryNonHtml (ON | OFF)
Description des paramètres fournie en bas de la page.”
Pour configurer une règle de relaxation de script inter-site HTML à l’aide de la ligne de commande
Utilisez la commande bind ou unbind pour ajouter ou supprimer une liaison, comme suit :
bind appfw profile <name> -crossSiteScripting <String> [isRegex (REGEX | NOTREGEX)] <formActionURL> [-location <location>] [-valueType (Tag|Attribute|Pattern) [<valueExpression>] [-isValueRegex (REGEX | NOTREGEX) ]]
unbind appfw profile <name> -crossSiteScripting <String> <formActionURL> [-location <location>] [-valueType (Tag |Attribute|Pattern) [<valueExpression>]]
Utilisation de l’interface graphique pour configurer la vérification des scripts entre sites HTML
Dans l’interface graphique, vous pouvez configurer la vérification HTML Cross-Site Scripting dans le volet du profil associé à votre application.
Pour configurer ou modifier la vérification HTML Cross-Site Scripting à l’aide de l’interface graphique
- Accédez à Application Pare-feu > Profils, mettez en surbrillance le profil cible, puis cliquez sur Modifier.
- Dans le volet Paramètres avancés, cliquez sur Vérifications de sécurité.
La table de vérification de sécurité affiche les paramètres d’action actuellement configurés pour tous les contrôles de sécurité. Vous avez 2 options de configuration :
a. Si vous souhaitez activer ou désactiver les actions de blocage, de journal, de statistiqueset d’ apprentissage pour le script inter-site HTML, vous pouvez cocher ou désactiver les cases à cocher dans le tableau, cliquez sur OK, puis cliquez sur Enregistrer et fermer pour fermer le Volet de vérification de la sécurité.
b. Si vous souhaitez configurer d’autres options pour cette vérification de sécurité, double-cliquez sur HTML Inter-Site Scriptingou sélectionnez la ligne et cliquez sur Paramètres d’actionpour afficher les options suivantes :
Transformer des scripts intersites—Transformer des balises de script non sécurisées.
Vérifier les URL complètes pour les scripts inter-sites : au lieu de vérifier uniquement la partie requête de l’URL, vérifiez l’URL complète pour les violations de script inter-sites.
Après avoir modifié l’un des paramètres ci-dessus, cliquez sur OK pour enregistrer les modifications et revenir au tableau Vérifications de sécurité. Vous pouvez procéder à la configuration d’autres vérifications de sécurité si nécessaire. Cliquez sur OK pour enregistrer toutes les modifications que vous avez apportées dans la section Contrôles de sécurité, puis cliquez sur Enregistrer et fermer pour fermer le volet de vérification de la sécurité.
Pour activer ou désactiver le paramètre Vérifier l’en-tête de demande, dans le volet Paramètres avancés, cliquez sur Paramètres du profil. Dans Paramètres communs, activez ou désactivez la case à cocher Vérifier les en-têtes de demande. Cliquez sur OK. Vous pouvez utiliser l’icône X en haut à droite du volet Paramètres du profil pour fermer cette section ou, si vous avez terminé la configuration de ce profil, vous pouvez cliquer sur Terminé pour revenir à Application Pare-feu > Profil.
Pour activer ou désactiver le paramètre Vérifier la requête Requête non HTML, dans le volet Paramètres avancés, cliquez sur Paramètres du profil. Dans Paramètres communs, Activez ou désactivez la case à cocher Requête non HTML de requête. Cliquez sur OK. Vous pouvez utiliser l’icône X en haut à droite du volet Paramètres du profil pour fermer cette section ou, si vous avez terminé de configurer ce profil, vous pouvez cliquer sur Terminé pour revenir au pare-feu de l’application > Profil.
Pour configurer une règle de relaxation de script inter-site HTML à l’aide de l’interface graphique
- Accédez à Application Pare-feu > Profils, mettez en surbrillance le profil cible, puis cliquez sur Modifier.
- Dans le volet Paramètres avancés, cliquez sur Règles de relaxation.
- Dans le tableau Règles de relaxation, double-cliquez sur l’entrée HTML Cross-Site Scripting, ou sélectionnez-la et cliquez sur Modifier.
- Dans la boîte de dialogue Règles de relaxation de script inter-site HTML, effectuez les opérations Ajouter, Modifier, Supprimer, Activer ou Désactiver pour les règles de relaxation.
Remarque
Lorsque vous ajoutez une nouvelle règle, le champ Expression de valeur n’est pas affiché, sauf si vous sélectionnez l’option Balise ou Attribut ou Modèle dans le champ Type de valeur.
Pour gérer les règles de relaxation HTML Cross-Site Scripting à l’aide du visualiseur
Pour obtenir une vue consolidée de toutes les règles de relaxation, vous pouvez mettre en surbrillance la ligne HTML Cross-Site Scripting dans le tableau Règles de relaxation, puis cliquer sur Visualiseur. Le visualiseur pour les relaxations déployées vous offre la possibilité d’ ajouter une nouvelle règle ou de modifier une règle existante. Vous pouvez également activer ou désactiver un groupe de règles en sélectionnant un nœud et en cliquant sur les boutons correspondants dans le visualiseur de relaxation.
Pour afficher ou personnaliser les modèles de script inter-site à l’aide de l’interface graphique
Vous pouvez utiliser l’interface graphique pour afficher ou personnaliser la liste par défaut des attributs autorisés de script intersite ou des balises autorisées. Vous pouvez également afficher ou personnaliser la liste par défaut des motifs refusés de script inter-site.
Les listes par défaut sont spécifiées dans Application Firewall > Signatures > Signaturespar défaut. Si vous ne liez aucun objet signature à votre profil, la liste de scripts intersites par défaut autorisée et refusée spécifiée dans l’objet Signatures par défaut sera utilisée par le profil pour le traitement du contrôle de sécurité Cross-Site Scripting. Les balises, attributs et motifs, spécifiés dans l’objet signatures par défaut, sont en lecture seule. Vous ne pouvez pas les modifier ou les modifier. Si vous souhaitez les modifier ou les modifier, effectuez une copie de l’objet Signatures par défaut pour créer un objet signature définie par l’utilisateur. Modifiez les listes autorisées ou refusées dans le nouvel objet de signature défini par l’utilisateur et utilisez cet objet de signature dans votre profil qui traite le trafic pour lequel vous souhaitez utiliser ces listes personnalisées autorisées et refusées.
- Pour afficher les modèles de script intersite par défaut :
a. Accédez à Application Pare-feu > Signatures, sélectionnez Signatures par défaut, puis cliquez sur Modifier. Ensuite, cliquez sur Gérer les modèles de script SQL/inter-site.
Le tableau Gérer les chemins de script SQL/inter-site présente les trois lignes suivantes relatives au script inter-site :
xss/allowed/attribute
xss/allowed/tag
xss/denied/pattern
b. Sélectionnez une ligne et cliquez sur Gérer les éléments pour afficher les éléments de script intersite correspondants (balise, attribut, motif) utilisés par la vérification de script inter-site du Web App Firewall.
- Pour personnaliser des éléments de script inter-sites : vous pouvez modifier l’objet de signature défini par l’utilisateur pour personnaliser la balise autorisée, les attributs autorisés et les motifs refusés. Vous pouvez ajouter de nouvelles entrées ou supprimer celles qui existent déjà.
a. Accédez à Application Pare-feu > Signatures, mettez en surbrillance la signature définie par l’utilisateur cible, puis cliquez sur Modifier. Cliquez sur Gérer les modèles de script SQL/inter-sites pour afficher la table Gérer les chemins de script SQL/inter-site.
b. Sélectionnez la ligne cible de script inter-site.
i. Cliquez sur Gérer les élémentspour ajouter, modifier ou supprimer l’élément de script inter-site correspondant.
ii. Cliquez sur Supprimer pour supprimer la ligne sélectionnée.
Avertissement :
Vous devez être prudent avant de supprimer ou de modifier tout élément de script inter-site par défaut, ou de supprimer le chemin de script inter-site pour supprimer la ligne entière. Les règles de signature et le contrôle de sécurité des scripts inter-sites reposent sur ces éléments pour détecter les attaques afin de protéger vos applications. La personnalisation du script inter-site Elements peut rendre votre application vulnérable aux attaques de script inter-site si le modèle requis est supprimé lors de la modification.
Utilisation de la fonctionnalité d’apprentissage avec la vérification de script inter-site HTML
Lorsque l’action « apprendre » est activée, le moteur d’apprentissage Citrix Web App Firewall surveille le trafic et apprend les violations des URL de script inter-sites. Vous pouvez inspecter périodiquement les règles d’URL de script intersite et les déployer pour détecter les scénarios de faux positifs.
Remarque :
Dans une configuration de cluster, tous les nœuds doivent être de la même version pour déployer les règles d’URL de script inter-site.
Amélioration de l’apprentissage des scripts inter-sites HTML. Une amélioration de l’apprentissage du Web App Firewall a été introduite dans la version 11.0 du logiciel Citrix ADC. Pour déployer une relaxation de script cross-site HTML à grain fin, le Web App Firewall offre un apprentissage de script cross-site HTML à grain fin. Le moteur d’apprentissage formule des recommandations concernant le type de valeur observé (balise, attribut, modèle) et l’expression de valeur correspondante observée dans les champs de saisie. En plus de vérifier les demandes bloquées pour déterminer si la règle actuelle est trop restrictive et doit être assouplie, vous pouvez consulter les règles générées par le moteur d’apprentissage pour déterminer quels types de valeur et expressions de valeur déclenchent des violations et doivent être traitées dans les règles de relaxation.
Remarque :
Le moteur d’apprentissage de Web App Firewall ne peut distinguer que les 128 premiers octets du nom. Si un formulaire comporte plusieurs champs dont les noms correspondent aux 128 premiers octets, le moteur d’apprentissage peut ne pas être en mesure de les distinguer. De même, la règle de relaxation déployée peut par inadvertance relâcher tous ces champs de l’inspection HTML Cross-Site Scripting. Conseil
Les balises de script inter-sites qui contiennent plus de 12 caractères ne sont pas apprises ou enregistrées correctement.
Si vous avez besoin d’une plus grande longueur de balise pour l’apprentissage, vous pouvez ajouter une grande balise n’apparaissant pas dans AS_Cross-Site Scripting_Allowed_tags_list pour la longueur ‘x’.
Pour afficher ou utiliser les données apprises à l’aide de l’interface de ligne de commande
À l’invite de commandes, tapez l’une des commandes suivantes :
show appfw learningdata <profilename> crossSiteScripting
rm appfw learningdata <profilename> -crossSiteScripting <string> <formActionURL> [<location>] [<valueType> <valueExpression>]
export appfw learningdata <profilename> **crossSiteScripting*
Pour afficher ou utiliser les données apprises à l’aide de l’interface graphique
- Accédez à Application Pare-feu > Profils, mettez en surbrillance le profil cible, puis cliquez sur Modifier.
- Dans le volet Paramètres avancés, cliquez sur Règles apprises. Vous pouvez sélectionner l’entrée HTML Cross-Site Scripting dans le tableau Règles apprises et double-cliquer dessus pour accéder aux règles apprises. Le tableau affiche les colonnes Nom du champ,URL A ction, Typede valeur, Valeuret Hits . Vous pouvez déployer les règles apprises ou modifier une règle avant de la déployer en tant que règle de relaxation. Pour ignorer une règle, vous pouvez la sélectionner et cliquer sur le bouton Ignorer. Vous ne pouvez modifier qu’une seule règle à la fois, mais vous pouvez sélectionner plusieurs règles à déployer ou à ignorer.
Vous avez également la possibilité d’afficher une vue résumée des relaxations apprises en sélectionnant l’entrée HTML Cross-Site Scripting dans le tableau Règles apprises et en cliquant sur Visualiseur pour obtenir une vue consolidée de toutes les violations apprises. Le visualiseur facilite la gestion des règles apprises. Il présente une vue complète des données sur un seul écran et facilite l’action sur un groupe de règles en un seul clic. Le plus grand avantage du visualiseur est qu’il recommande des expressions régulières pour consolider plusieurs règles. Vous pouvez sélectionner un sous-ensemble de ces règles, en fonction du délimiteur et de l’URL Action. Vous pouvez afficher 25, 50 ou 75 règles dans le visualiseur, en sélectionnant le nombre dans une liste déroulante. Le visualiseur des règles apprises offre la possibilité de modifier les règles et de les déployer en tant que relaxations. Ou vous pouvez ignorer les règles pour les ignorer.
Utilisation de la fonctionnalité de journal avec la vérification des scripts inter-sites HTML
Lorsque l’action de journalisation est activée, les violations de vérification de sécurité des scripts inter-sites HTML sont enregistrées dans le journal d’audit en tant que violations de script AppFW_Cross-site. Le Web App Firewall prend en charge les formats de journaux natifs et CEF. Vous pouvez également envoyer les journaux à un serveur syslog distant.
Pour accéder aux messages du journal à l’aide de la ligne de commande
Basculez vers l’interpréteur de commandes et queue les ns.logs dans le /var/log/
dossier pour accéder aux messages de journal relatifs aux violations de script inter-site HTML :
Shell
tail -f /var/log/ns.log | grep APPFW_cross-site scripting
Exemple d’un message de journal des violations de vérification de sécurité de script inter-site au format de journal CEF :
Jul 11 00:45:51 <local0.info> 10.217.31.98 CEF:0|Citrix|Citrix ADC|NS11.0|APPFW|\*\*APPFW_cross-site scripting\*\*|6|src=10.217.253.62 geolocation=Unknown spt=4840 method=GET request=http://aaron.stratum8.net/FFC/CreditCardMind.html?abc=%3Cdef%3E msg=\*\*Cross-site script check failed for field abc="Bad tag: def"\*\* cn1=133 cn2=294 cs1=pr_ffc cs2=PPE1 cs3=eUljypvLa0BbabwfGVE52Sewg9U0001 cs4=ALERT cs5=2015 act=\*\*not blocked\*\*
Exemple d’un message de journal de violation de vérification de sécurité Cross-Site Scripting au format journal natif montrant une action de transformation
Jul 11 01:00:28 <local0.info> 10.217.31.98 07/11/2015:01:00:28 GMT ns 0-PPE-0 : default APPFW \*\*APPFW_cross-site scripting\*\* 132 0 : 10.217.253.62 392-PPE0 eUljypvLa0BbabwfGVE52Sewg9U0001 pr_ffc http://aaron.stratum8.net/FFC/login.php?login_name=%3CBOB%3E&passwd=&drinking_pref=on &text_area=&loginButton=ClickToLogin&as_sfid=AAAAAAVFqmYL68IGvkrcn2pzehjfIkm5E6EZ9FL8YLvIW_41AvAATuKYe9N7uGThSpEAxbb0iBx55jyvqOZNiVK_XwEPstMYvWHxfUWl62WINwRMrKsEDil-FC4llF \*\*Cross-site script special characters seen in fields <transformed>\*\*
Accéder aux messages du journal à l’aide de l’interface graphique
L’interface utilisateur graphique Citrix inclut un outil utile (Syslog Viewer) pour analyser les messages du journal. Vous disposez de plusieurs options pour accéder à la visionneuse Syslog :
- Accédez au pare-feu des applications > Profils, sélectionnez le profil cible et cliquez sur Vérifications de sécurité. Mettez en surbrillance la ligne HTML Cross-Site Scripting, puis cliquez sur Journaux. Lorsque vous accédez aux journaux directement à partir de la vérification HTML Cross-Site Scripting du profil, l’interface graphique filtre les messages de journal et affiche uniquement les journaux relatifs à ces violations de vérification de sécurité.
- Vous pouvez également accéder à la visionneuse Syslog en accédant à Citrix ADC > Système > Audit. Dans la section Messages d’audit, cliquez sur le lien Messages Syslog pour afficher la visionneuse Syslog, qui affiche tous les messages de journal, y compris les autres journaux de violation de vérification de sécurité. Ceci est utile pour le débogage lorsque plusieurs violations de vérification de sécurité peuvent être déclenchées pendant le traitement de la demande.
- Accédez à Application Firewall > Stratégies > Audit. Dans la section Messages d’audit, cliquez sur le lien Messages Syslog pour afficher la visionneuse Syslog, qui affiche tous les messages de journal, y compris les autres journaux de violation de vérification de sécurité.
La visionneuse Syslog basée sur HTML fournit diverses options de filtre pour sélectionner uniquement les messages de journal qui vous intéressent. Pour sélectionner les messages de journalisation pour la vérification de script inter-site HTML, filtrez en sélectionnant APPFW dans les options de la liste déroulante pour Module. La liste Type d’événement offre un ensemble complet d’options pour affiner votre sélection. Par exemple, si vous activez la case à cocher AppFW_Inter-Site Script et que vous cliquez sur le bouton Appliquer, seuls les messages relatifs aux violations de vérification de sécurité des scripts inter-sites HTML apparaissent dans la visionneuse Syslog.
Si vous placez le curseur dans la ligne d’un message de journal spécifique, plusieurs options, telles que Module, Type d’événement, ID d’événement, adresse IP du client, etc., apparaissent sous le message de journal. Vous pouvez sélectionner l’une de ces options pour mettre en surbrillance les informations correspondantes dans le message de journal.
Cliquez sur pour Déployer la fonctionnalité est disponible uniquement dans l’interface graphique. Vous pouvez utiliser la visionneuse Syslog non seulement pour afficher les journaux, mais aussi pour déployer des règles de relaxation HTML Cross-Site Scripting basées sur les messages de journal pour les violations de vérification de sécurité du Web App Firewall. Les messages de journal doivent être au format de journal CEF pour cette opération. Cliquez pour déployer la fonctionnalité est disponible uniquement pour les messages de journal générés par l’action Bloquer (ou non bloquer). Vous ne pouvez pas déployer une règle de relaxation pour un message de journal concernant l’opération de transformation.
Pour déployer une règle de relaxation à partir de la visionneuse Syslog, sélectionnez le message de journal. Une case à cocher s’affiche dans le coin supérieur droit de la case Visionneuse Syslog de la ligne sélectionnée. Activez la case à cocher, puis sélectionnez une option dans la liste Action pour déployer la règle de relaxation. Modifier et déployer, déployeret déployer toutsont disponibles en tant qu’options Action.
Les règles de script inter-site HTML déployées à l’aide de l’option Cliquez pour déployer n’incluent pas les recommandations de relaxation du grain fin.
Configurer le clic pour déployer la fonctionnalité à l’aide de l’interface graphique
- Dans la visionneuse Syslog, sélectionnez APPFW dans les options du module.
- Sélectionnez le script App_cross-site comme Type d’événement pour filtrer les messages de journal correspondants.
- Activez la case à cocher pour identifier la règle à déployer.
- Utilisez la liste déroulante d’options Action pour déployer la règle de relaxation.
- Vérifiez que la règle apparaît dans la section Règle de relaxation correspondante.
Statistiques pour les violations de script inter-site HTML
Lorsque l’action des statistiques est activée, le compteur de la vérification HTML Cross-Site Scripting est incrémenté lorsque le Web App Firewall prend une action pour cette vérification de sécurité. Les statistiques sont collectées pour le taux et le nombre total pour le trafic, les violations et les journaux. La taille d’un incrément du compteur de journaux peut varier en fonction des paramètres configurés. Par exemple, si l’action de blocage est activée, la demande d’une page contenant 3 violations de script inter-site HTML incrémente le compteur de statistiques d’un, car la page est bloquée dès que la première violation est détectée. Toutefois, si le bloc est désactivé, le traitement de la même demande incrémente le compteur de statistiques pour les violations et les journaux de trois, car chaque violation génère un message de journal distinct.
Pour afficher HTML Cross-Site Scripting, vérifiez les statistiques à l’aide de la ligne de commande
À l’invite de commandes, tapez :
> sh appfw stats
Pour afficher les statistiques d’un profil spécifique, utilisez la commande suivante :
> **stat appfw profile** <profile name>
Afficher les statistiques de script inter-sites HTML à l’aide de l’interface graphique
- Accédez à Sécurité > Pare-feu d’application > Profils > Statistiques.
- Dans le volet droit, accédez au lien Statistiques.
- Utilisez la barre de défilement pour afficher les statistiques sur les violations et les journaux de script inter-site HTML. Le tableau des statistiques fournit des données en temps réel et est mis à jour toutes les 7 secondes.
Résumé
- Prise encharge intégrée de la protection contre les attaques par script inter-site HTML : Citrix Web App Firewall protège contre les attaques de script inter-site en surveillant une combinaison d’attributs et de balises autorisés et de modèles refusés dans la charge utile reçue. Toutes les balises autorisées par défaut intégrées, les attributs autorisés et les motifs refusés utilisés par la vérification des scripts inter-sites sont spécifiés dans le fichier /netscaler/default_custom_settings.xml.
- Personnalisation : vous pouvez modifier la liste par défaut de balises, d’attributs et de modèles pour personnaliser l’inspection de vérification de sécurité des scripts inter-site en fonction des besoins spécifiques de votre application. Effectuez une copie de l’objet signature par défaut, modifiez les entrées existantes ou ajoutez de nouvelles entrées. Liez cet objet signature à votre profil pour utiliser la configuration personnalisée.
- Modèle de sécurité hybride : les signatures et les protections de sécurité profondes utilisent les modèles de script SQL/cross-site spécifiés dans l’objet signature lié au profil. Si aucun objet de signature n’est lié au profil, les modèles de script SQL/cross-site présents dans l’objet signature par défaut sont utilisés.
- Transform—Notez ce qui suit à propos de l’opération de transformation :
L’opération de transformation fonctionne indépendamment des autres paramètres d’action de script inter-site. Si la transformation est activée et que le bloc, le journal, les statistiques et l’apprentissage sont tous désactivés, les balises de script intersite sont transformées.
Si l’action de blocage est activée, elle a priorité sur l’action de transformation.
- Relaxation et apprentissage à grains fins. Affinez la règle de relaxation pour relâcher un sous-ensemble d’éléments de script intersite de l’inspection de vérification de sécurité, mais détectez le reste. Le moteur d’apprentissage recommande un type de valeur spécifique et des expressions de valeur basées sur les données observées.
- Cliquez pour déployer : sélectionnez un ou plusieurs messages de journal des violations de script intersite dans la visionneuse syslog et déployez-les en tant que règles de relaxation.
- Charset—Le jeu de caractères par défaut du profil doit être défini en fonction des besoins de l’application. Par défaut, le jeu de caractères de profil est défini sur Anglais US (ISO-8859-1). Si une demande est reçue sans le jeu de caractères spécifié, le Web App Firewall traite la demande comme si elle était ISO-8859-1. Le caractère ouvert (<) or the close bracket character (>) ne sera pas interprété comme des balises de script inter-sites si ces caractères sont codés dans d’autres jeux de caractères. Par exemple, si une requête contient une chaîne de caractères UTF-8 “%uff1cscript%uff1e“mais que le jeu de caractères n’est pas spécifié sur la page de requête, la violation de script intersite peut ne pas être déclenchée sauf si le jeu de caractères par défaut du profil est spécifié comme Unicode.
Partager
Partager
Dans cet article
- Scripting inter-site Relaxations à grain fin
- Utilisation de la ligne de commande pour configurer la vérification HTML cross-site Scripting
- Utilisation de l’interface graphique pour configurer la vérification des scripts entre sites HTML
- Utilisation de la fonctionnalité d’apprentissage avec la vérification de script inter-site HTML
- Utilisation de la fonctionnalité de journal avec la vérification des scripts inter-sites HTML
- Statistiques pour les violations de script inter-site HTML
- Résumé
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.