Vérification par injection HTML SQL

De nombreuses applications Web possèdent des formulaires Web qui utilisent SQL pour communiquer avec des serveurs de bases de données relationnelles. Un code malveillant ou un pirate informatique peut utiliser un formulaire Web non sécurisé pour envoyer des commandes SQL au serveur Web. La vérification par injection SQL HTML de Web App Firewall fournit des défenses spéciales contre l’injection de code SQL non autorisé susceptible de compromettre la sécurité. Si le Web App Firewall détecte un code SQL non autorisé dans une demande utilisateur, il transforme la demande, pour rendre le code SQL inactif, ou bloque la demande. Le Web App Firewall examine la charge utile de la requête pour le code SQL injecté à trois emplacements : 1) corps POST, 2) en-têtes et 3) cookies. Pour examiner une partie de requête dans les demandes de code SQL injecté, configurez un paramètre de profil de pare-feu d’application « InspectQueryContentTypes » pour les types de contenu spécifiques.

Un ensemble par défaut de mots-clés et de caractères spéciaux fournit des mots-clés connus et des caractères spéciaux couramment utilisés pour lancer des attaques SQL. Vous pouvez ajouter de nouveaux modèles et modifier le jeu par défaut pour personnaliser l’inspection des vérifications SQL. Le Web App Firewall propose différentes options d’action pour mettre en œuvre la protection par injection SQL. Outre les actions Bloquer, Log, Stats et Learn, le profil Web App Firewall offre également la possibilité de transformer les caractères spéciaux SQL pour rendre une attaque inoffensive.

Outre les actions, plusieurs paramètres peuvent être configurés pour le traitement par injection SQL. Vous pouvez vérifier la présence de caractères génériques SQL. Vous pouvez modifier le type d’injection SQL et sélectionner l’une des 4 options (SQLKeyword, SqlsplChar, SqlsplCharAndKeyword, SQLSplCharOrKeyword) pour indiquer comment évaluer les mots-clés SQL et les caractères spéciaux SQL lors du traitement de la charge utile. Le paramètre Gestion des commentaires SQL vous permet de spécifier le type de commentaires qui doivent être inspectés ou exemptés lors de la détection par injection SQL.

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.

Les options suivantes sont disponibles pour configurer une protection SQL Injection optimisée pour votre application :

Block—L’action de bloc n’est déclenchée que si l’entrée correspond à la spécification de type d’injection SQL. Par exemple, si SQLSplCharANDKeyword est configuré comme type d’injection SQL, une requête n’est pas bloquée si elle ne contient pas de mots-clés, même si des caractères spéciaux SQL sont détectés dans l’entrée. Une telle demande est bloquée si le type d’injection SQL est défini sur SqlsplCharou SqlsplCharOrKeyword.

Log—Si vous activez la fonction de journal, la vérification SQL Injection génère des messages de journal indiquant les actions qu’elle effectue. Si l’action de blocage est désactivée, un message de journal distinct est généré pour chaque champ de saisie dans lequel la violation SQL 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 demande est généré pour l’opération de transformation, même lorsque des caractères spéciaux SQL sont transformés 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 de nouvelles règles de relaxation ou modifier celles existantes.

Apprendre : si vous n’êtes pas sûr des règles de relaxation SQL qui conviennent le mieux à votre application, vous pouvez utiliser la fonctionnalité d’apprentissage pour générer des recommandations basées sur les données apprises. Le moteur d’apprentissage du Web App Firewall surveille le trafic et fournit des recommandations d’apprentissage SQL en fonction des 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.

Caractères spéciaux Transform SQL : le Web App Firewall considère trois caractères, les guillemets simples (‘), les barres obliques (\)inverses et les points-virgules (;) comme des caractères spéciaux pour le traitement des vérifications de sécurité SQL. La fonction de transformation SQL modifie le code d’injection SQL dans une requête HTML pour s’assurer que la requête est rendue inoffensive. La demande HTML modifiée est ensuite envoyée au serveur. Toutes les règles de transformation par défaut sont spécifiées dans le fichier /netscaler/default_custom_settings.xml.

L’opération de transformation rend le code SQL inactif en apportant les modifications suivantes à la demande :

• Guillemets simples (‘) vers guillemets droits doubles («).
• Barre oblique inverse (\) pour double barre oblique inverse (\).
• Le point-virgule (;) est complètement supprimé.

Ces trois caractères (chaînes spéciales) sont nécessaires pour émettre des commandes vers un serveur SQL. À moins qu’une commande SQL ne soit préfacée par une chaîne spéciale, la plupart des serveurs SQL ignorent cette commande. Par conséquent, les modifications que le Web App Firewall effectue lorsque la transformation est activée empêchent un attaquant d’injecter du code SQL actif. Une fois ces modifications apportées, la demande peut être transmise en toute sécurité à votre site Web protégé. Lorsque les formulaires Web de votre site Web protégé peuvent légitimement contenir des chaînes spéciales SQL, mais que les formulaires Web ne dépendent pas des chaînes spéciales pour fonctionner correctement, vous pouvez désactiver le blocage et activer la transformation pour empêcher le blocage des données de formulaire Web légitimes sans réduire la protection que l’application Web Le pare-feu fournit à vos sites Web protégés.

L’opération de transformation fonctionne indépendamment du paramètre du type d’injection SQL. Si la transformation est activée et que le type d’injection SQL est spécifié comme mot-clé SQL, les caractères spéciaux SQL sont transformés même si la requête ne contient aucun mot-clé.

Conseil

Vous activez normalement la transformation ou le blocage, mais pas les deux. Si l’action de blocage est activée, elle a priorité sur l’action de transformation. Si le blocage est activé, l’activation de la transformation est redondante.

Vérifier les caractères génériques SQL —Lescaractères génériques peuvent être utilisés pour élargir les sélections d’une instruction SQL (SQL-SELECT). Ces opérateurs de caractères génériques peuvent être utilisés avec des opérateurs LIKEet NOT LIKE pour comparer une valeur à des valeurs similaires. Le pourcentage (%) et le trait de soulignement (_) sont fréquemment utilisés comme caractères génériques. Le signe pour cent est analogue au caractère générique astérisque (*) utilisé avec MS-DOS et pour faire correspondre zéro, un ou plusieurs caractères dans un champ. Le trait de soulignement est similaire au point d’interrogation MS-DOS (?) caractère générique. Il correspond à un seul nombre ou caractère dans une expression.

Par exemple, vous pouvez utiliser la requête suivante pour effectuer une recherche de chaîne afin de rechercher tous les clients dont le nom contient le caractère D.

SELECT * from customer WHERE name like “%D%”:

L’exemple suivant combine les opérateurs pour rechercher les valeurs de salaire dont la deuxième et la troisième position sont égales à 0.

SELECT * from customer WHERE salary like ‘_00%’:

Différents fournisseurs de SGBD ont étendu les caractères génériques en ajoutant des opérateurs supplémentaires. Le pare-feu NetScaler Web App peut protéger contre les attaques lancées en injectant ces caractères génériques. Les 5 caractères génériques par défaut sont le pourcentage (%), le trait de soulignement (_), le signe d’insertion (^), le crochet ouvrant ([) et le crochet fermant (]). Cette protection s’applique aux profils HTML et XML.

Les caractères génériques par défaut sont une liste de littéraux spécifiés dans *Signatures par défaut :

• <wildchar type=”LITERAL”>%</wildchar>
• <wildchar type=”LITERAL”>_</wildchar>
• <wildchar type=”LITERAL”>^</wildchar>
• <wildchar type=”LITERAL”>[</wildchar>
• <wildchar type=”LITERAL”>]</wildchar>

Les caractères génériques d’une attaque peuvent être PCRE, comme [^A-F]. Le Web App Firewall prend également en charge les caractères génériques PCRE, mais les caractères génériques littéraux ci-dessus sont suffisants pour bloquer la plupart des attaques.

Remarque :

La vérification des caractères génériques SQL est différente de la vérification des caractères spéciaux SQL. Cette option doit être utilisée avec précaution afin d’éviter les faux positifs.

Demande de vérification contenant le type d’injection SQL : le Web App Firewall propose 4 options pour mettre en œuvre le niveau de rigueur souhaité pour l’inspection par injection SQL, en fonction des besoins individuels de l’application. La demande est vérifiée par rapport à la spécification du type d’injection pour détecter les violations SQL. Les 4 options de type d’injection SQL sont les suivantes :

• Caractère spécial et mot-cléSQL : un mot-clé SQL et un caractère spécial SQL doivent être présents dans l’entrée pour déclencher une violation SQL. Ce paramètre le moins restrictif est également le paramètre par défaut.
• Caractère spécial SQL : au moins un des caractères spéciaux doit être présent dans l’entrée pour déclencher une violation SQL.
• Mot clé SQL : au moins un des mots-clés SQL spécifiés doit être présent dans l’entrée pour déclencher une violation SQL. Ne sélectionnez pas cette option sans avoir dûment pris en considération. Pour éviter les faux positifs, assurez-vous qu’aucun des mots-clés n’est attendu dans les entrées.
• Caractère spécial ou mot clé SQL : le mot clé ou la chaîne de caractères spéciaux doit être présent dans l’entrée pour déclencher la violation du contrôle de sécurité.

Conseil :

Si vous configurez le Web App Firewall pour rechercher les entrées contenant un caractère spécial SQL, le pare-feu Web App ignore les champs de formulaire Web qui ne contiennent pas de caractères spéciaux. Étant donné que la plupart des serveurs SQL ne traitent pas les commandes SQL qui ne sont pas précédées d’un caractère spécial, l’activation de cette option peut réduire considérablement la charge sur le Web App Firewall et accélérer le traitement sans mettre en danger vos sites Web protégés.

Gestion des commentaires SQL : par défaut, le Web App Firewall vérifie tous les commentaires SQL à la recherche de commandes SQL injectées. Cependant, de nombreux serveurs SQL ignorent tout élément d’un commentaire, même s’il est précédé d’un caractère spécial SQL. Pour un traitement plus rapide, si votre serveur SQL ignore les commentaires, vous pouvez configurer le Web App Firewall pour ignorer les commentaires lors de l’examen des demandes de SQL injecté. Les options de gestion des commentaires SQL sont les suivantes :

• ANSI—Ignorez les commentaires SQL au format ANSI, qui sont normalement utilisés par les bases de données SQL basées sur UNIX. Par exemple :

  • — (Deux traits d’union) - Il s’agit d’un commentaire qui commence par deux traits d’union et se termine par la fin de la ligne.

  • {} - Accolades (Les accolades enferment le commentaire. Le {précède le commentaire, et le} le suit. Les accolades peuvent délimiter les commentaires sur une ou plusieurs lignes, mais les commentaires ne peuvent pas être imbriqués)

  • /* */ : C style comments (Does not allow nested comments). Please note /*! <comment that begin with slash followed by asterisk and exclamation mark is not a comment > */

  • MySQL Server prend en charge certaines variantes de commentaires de style C. Ceux-ci vous permettent d’écrire du code qui inclut des extensions MySQL, mais qui est toujours portable, en utilisant les commentaires de la forme suivante : /*! MySQL-specific code */

  • . # : Commentaires Mysql : Il s’agit d’un commentaire qui commence par # caractère.

• Imbriqué—Ignorer les commentaires SQL imbriqués, qui sont normalement utilisés par Microsoft SQL Server. Par exemple ; — (Deux traits d’union) et /* */ (Autorise les commentaires imbriqués)
• ANSI/imbriqué—Ignorer les commentaires qui respectent les normes ANSI et SQL de commentaires imbriqués. Les commentaires qui correspondent uniquement à la norme ANSI, ou uniquement à la norme imbriquée, sont toujours vérifiés pour détecter le code SQL injecté.
• Vérifier tous les commentaires : permet de vérifier l’intégralité de la demande de code SQL injecté sans rien ignorer. C’est le réglage par défaut.

Conseil

Habituellement, vous ne devez pas choisir l’option imbriquée ou l’option ANSI/imbriquée, sauf si votre base de données principale s’exécute sur Microsoft SQL Server. La plupart des autres types de logiciels SQL Server ne reconnaissent pas les commentaires imbriqués. Si des commentaires imbriqués apparaissent dans une demande dirigée vers un autre type de serveur SQL, ils peuvent indiquer une tentative de violation de la sécurité sur ce serveur.

Vérifier les en-têtes de demande : activez cette option si, en plus d’examiner l’entrée dans les champs du formulaire, vous souhaitez examiner les en-têtes de demande pour des attaques par injection HTML SQL. Si vous utilisez l’interface graphique, vous pouvez activer ce paramètre dans le volet Paramètres avancés -> Paramètres de profil du profil Pare-feu de l’application Web.

Remarque :

Si vous activez l’indicateur d’en-tête Check Request, vous devrez peut-être configurer une règle de relaxation pour l’en-tête User-Agent. La présence du mot-clé SQL like et du caractère spécial SQL point-virgule (; ) peut déclencher des requêtes fausses positives et bloquer qui contiennent cet en-tête. Avertissement

Si vous activez à la fois la vérification et la transformation des en-têtes de requête, tous les caractères spéciaux SQL présents dans les en-têtes sont également transformés. Les en-têtes Accept, Accept-Charset, Accept-Encoding, Accept-Language, Expect et User-Agent contiennent normalement des points-virgules ( ;). L’activation simultanée de la vérification et de la transformation des en-têtes de demande peut entraîner des erreurs

InspectQueryContentTypes  : configurez cette option si vous souhaitez examiner la partie requête de requête pour les attaques par injection SQL pour les types de contenu spécifiques. Si vous utilisez l’interface graphique, vous pouvez configurer ce paramètre dans le volet Paramètres avancés -> Paramètres du profil du profil App Firewall.

SQL 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 d’inspection SQL Injection. Vous pouvez complètement contourner l’inspection d’un ou de plusieurs de ces champs en configurant les règles de relaxation pour la vérification SQL Injection.

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 SQL. La relaxation fine SQL fournit la possibilité d’autoriser des modèles spécifiques et de bloquer le reste. Par exemple, le Web App Firewall possède actuellement un ensemble par défaut de plus de 100 mots-clés SQL. Étant donné que les pirates peuvent utiliser ces mots-clés dans des attaques SQL Injection, le Web App Firewall les signale comme des menaces potentielles. Vous pouvez détendre un ou plusieurs mots-clés considérés comme sûrs pour un emplacement spécifique. Le reste des mots-clés SQL potentiellement dangereux sont toujours vérifiés pour l’emplacement cible et continuent de déclencher les violations de vérification de sécurité. Vous avez maintenant un contrôle beaucoup plus serré.

Les commandes utilisées dans les relaxations comportent des paramètres facultatifs pour le type de valeur et l’expression de valeur. Vous pouvez spécifier si l’expression de valeur est une expression régulière ou une chaîne littérale. Le type de valeur peut être laissé vide ou vous avez une option pour sélectionner Mot-clé ou SpecialString ou WildChar.

Avertissement :

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 l’URL que vous souhaitez ajouter en tant qu’exception, et rien d’autre. L’utilisation imprudente des caractères génériques, et en particulier du métacaractère d’astérisque de points (.*) ou de la combinaison de caractères génériques, peut avoir des résultats que vous ne souhaitez pas, tels que le blocage de l’accès au contenu Web que vous n’aviez pas l’intention de bloquer ou autoriser une attaque que la vérification d’injection HTML SQL 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 SQL peut être : 1) Mot-clé, 2) SpecialString ou 3) WildChar.
• Vous pouvez définir plusieurs règles de relaxation par combinaison nom de champ/URL.

Utilisation de la ligne de commande pour configurer le contrôle d’injection SQL

Pour configurer les actions d’injection SQL et d’autres paramètres à l’aide de la ligne de commande :

Dans l’interface de ligne de commande, vous pouvez utiliser la commande set appfw profile ou la commande add appfw profile pour configurer les protections SQL Injection. Vous pouvez activer les actions de blocage, d’apprentissage, de journalisation et de statistiques et spécifier si vous souhaitez transformer les caractères spéciaux utilisés dans les chaînes d’attaque SQL Injection pour désactiver l’attaque. Sélectionnez le type de modèle d’attaque SQL (mots-clés, caractères génériques, chaînes spéciales) que vous souhaitez détecter dans les charges utiles et indiquez si vous souhaitez que le Web App Firewall inspecte également les en-têtes de requête pour les violations SQL Injection. Utilisez la commande unset appfw profile pour rétablir les paramètres configurés à leurs valeurs par défaut. Chacune des commandes suivantes ne définit qu’un seul paramètre, mais vous pouvez inclure plusieurs paramètres dans une seule commande :

• set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• <name> -SQLInjectionAction (([block] [learn] [log] [stats]) | [none])
• set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• <name> -SQLInjectionTransformSpecialChars (**ON** | OFF)
• set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• <name> -**SQLInjectionCheckSQLWildChars** (**ON** |**OFF**)
• set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• **<name> -**SQLInjectionType** ([**SQLKeyword**] | [**SQLSplChar**] | [**SQLSplCharANDKeyword**] | [**SQLSplCharORKeyword**])
• set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• <name> -**SQLInjectionParseComments** ([**checkall**] | [**ansi|nested**] | [**ansinested**])
• **set application firewall profile “Parameter descriptions provided at the bottom of the page.”
• <name> -CheckRequestHeaders (ON | OFF) Les descriptions des paramètres sont fournies en bas de la page.
• <name> - CheckRequestQueryNonHtml (ON | OFF) Les descriptions des paramètres sont fournies en bas de la page.

Pour configurer une règle de relaxation SQL Injection à l’aide de l’interface de commande

Utilisez la commande bind ou unbind pour ajouter ou supprimer une liaison, comme suit :

• bind appfw profile <name> -SQLInjection <String> [isRegex(REGEX| NOTREGE)] <formActionURL> [-location <location>] [-valueType (Keywor|SpecialString|Wildchar) [<valueExpression>][-isValueRegex (REGEX | NOTREGEX) ]]

• unbind appfw profile <name> -SQLInjection <String> <formActionURL> [-location <location>] [-valueTyp (Keyword|SpecialString|Wildchar) [<valueExpression>]]

Remarque :

Vous pouvez trouver la liste des mots-clés SQL à partir du contenu du fichier de signatures par défaut en affichant l’objet de signature de vue, qui contient la liste des mots-clés SQL et des caractères spéciaux SQL.

Utilisation de l’interface graphique pour configurer la vérification de sécurité SQL Injection

Dans l’interface graphique, vous pouvez configurer le contrôle de sécurité Injection SQL dans le volet du profil associé à votre application.

Pour configurer ou modifier la vérification d’injection SQL à l’aide de l’interface graphique

1. Accédez à Pare-feu d’application > Profils, mettez en surbrillance le profil cible, puis cliquez sur Modifier.
2. Dans le volet Paramètres avancés, cliquez sur Contrôles de sécurité.

Le tableau de contrôle de sécurité affiche les paramètres d’action actuellement configurés pour tous les contrôles de sécurité. Deux options de configuration s’offrent à vous :

a. Si vous souhaitez activer ou désactiver les actions Block, Log, Stats et Learn pour HTML SQL Injection, vous pouvez sélectionner ou désactiver des cases à cocher dans le tableau, cliquer sur OK, puis cliquer sur Enregistrer et fermer pour fermer le volet de contrôle de sécurité.

b. Si vous souhaitez configurer d’autres options pour cette vérification de sécurité, double-cliquez sur Injection HTML SQL, ou sélectionnez la ligne et cliquez sur Paramètres d’action, pour afficher les options suivantes :

Transformer le caractère spécial SQL—Transformez tous les caractères spéciaux SQL dans la requête.

Vérifiez la présence de caractères génériques SQL : considérez les caractères génériques SQL dans la charge utile comme des modèles d’attaque.

Check Request Containing : type d’injection SQL (SQLKeyword, SQLSplChar, SQLSplCharAndKeyword ou SQLSplCharOrKeyword) à vérifier.

Gestion des commentaires SQL : type de commentaires (cocher tous les commentaires, ANSI, imbriqué ou ANSI/imbriqué) à vérifier.

Après avoir modifié l’un des paramètres ci-dessus, cliquez sur OK pour enregistrer les modifications et revenir au tableau Contrôles de sécurité. Vous pouvez procéder à la configuration d’autres contrôles 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 Contrôle de sécurité.

Pour configurer une règle de relaxation d’injection SQL à l’aide de l’interface graphique

• Accédez à Application Firewall > 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 Injection HTML SQL ou sélectionnez-la et cliquez sur Modifier.
• Dans la boîte de dialogueRègles de relaxation pour injection SQL HTML, effectuez des opérations d’ajout, demodification, desuppression, d’activation ou de désactivationdes règles de relaxation.

Remarque

Lorsque vous ajoutez une nouvelle règle, le champ Expression de la valeur n’est pas affiché, sauf si vous sélectionnez l’option Mot-clé ou SpecialString ou WildChar dans le champ Type de valeur.

Pour gérer les règles de relaxation par injection SQL à 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 SQL Injection et cliquer sur Visualizer. Le visualiseur des 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.

Afficher ou personnaliser les modèles d’injection à l’aide de l’interface graphique

Vous pouvez utiliser l’interface graphique pour afficher ou personnaliser les modèles d’injection.

Les modèles SQL par défaut sont spécifiés dans le fichier de signatures par défaut. Si vous ne liez aucun objet signature à votre profil, les modèles d’injection par défaut spécifiés dans l’objet signatures par défaut seront utilisés par le profil pour le traitement du contrôle de sécurité par injection de commandes. Les règles et les 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 modifier ou modifier ces modèles, effectuez une copie de l’objet sSignatures par défaut pour créer un objet Signature défini par l’utilisateur. Apportez des modifications aux modèles d’injection de commandes dans le nouvel objet Signature défini par l’utilisateur et utilisez cet objet signature dans votre profil qui traite le trafic pour lequel vous souhaitez utiliser ces modèles personnalisés.

Pour plus d’informations, voir Signatures.

Pour afficher les schémas d’injection par défaut à l’aide de l’interface graphique :

1. Accédez à Application Firewall > Signatures, sélectionnez *Signatures par défaut, puis cliquez sur Modifier.

2. Cliquez sur Gérer les modèles CMD/SQL/XSS. Le tableau Gérer les chemins de script SQL/inter-sites affiche les modèles relatifs à l’injection CMD/SQL/XS :

1. Sélectionnez une ligne et cliquez sur Gérer les éléments pour afficher les modèles d’injection correspondants (mots-clés, chaînes spéciales, règles de transformation ou caractères génériques) utilisés par la vérification d’injection de la commande Web App Firewall.

Utilisation de la fonctionnalité d’apprentissage avec la vérification d’injection SQL

Lorsque l’action d’apprentissage est activée, le moteur d’apprentissage du Web App Firewall surveille le trafic et apprend les violations déclenchées. Vous pouvez inspecter périodiquement ces règles apprises. Après mûre réflexion, vous pouvez déployer la règle apprise en tant que règle de relaxation d’injection SQL.

Amélioration del’apprentissage par injection SQL : une améliorationde l’apprentissage du Web App Firewall a été introduite dans la version 11.0 du logiciel NetScaler. Pour déployer une relaxation fine par injection SQL, le Web App Firewall propose un apprentissage précis de l’injection SQL. Le moteur d’apprentissage formule des recommandations concernant le type de valeur observé (mot-clé, SpecialString, Wildchar) et l’expression de valeur correspondante observée dans les champs d’entrée. 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.

Important

Le moteur d’apprentissage du pare-feu 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 SQL Injection.

Remarque Pour contourner l’enregistrement SQL de l’en-tête User-Agent, utilisez la règle de relaxation suivante :

bind appfw profile your_profile_name -SQLInjection User-Agent " .*" -location HEADER

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> SQLInjection
• rm appfw learningdata <profilename> -SQLInjection <string> <formActionURL> [<location>] [<valueType> <valueExpression>]
• export appfw learningdata <profilename> SQLInjection

Pour afficher ou utiliser les données apprises à l’aide de l’interface graphique

1. Accédez à Pare-feu d’application > Profils, mettez en surbrillance le profil cible, puis cliquez sur Modifier.

2. Dans le volet Paramètres avancés, cliquez sur Règles apprises. Vous pouvez sélectionner l’entrée Injection HTML SQL dans le tableau Règles apprises et double-cliquer dessus pour accéder aux règles apprises. 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 annuler une règle, vous pouvez la sélectionner et cliquer sur le bouton Ignorer. Vous ne pouvez modifier qu’une 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 SQL Injection dans le tableau Règles apprises et en cliquant sur Visualizer 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 la prise de mesures sur un groupe de règles en un seul clic. Le principal 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 d’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 sous forme d’assouplissements. Vous pouvez également ignorer les règles pour les ignorer.

Utilisation de la fonctionnalité de journal avec le contrôle d’injection SQL

Lorsque l’action de journalisation est activée, les violations du contrôle de sécurité d’injection SQL HTML sont consignées dans le journal d’audit en tant que violations APPFW_SQL. 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

Passez à l’interpréteur de commandes et repérez ns.logs dans le dossier /var/log/ pour accéder aux messages de journal relatifs aux violations SQL Injection :

> Shell

# tail -f /var/log/ns.log | grep APPFW_SQL

Exemple de message de journal HTML SQL Injection lorsque la demande est transformée

Jun 26 21:08:41 <local0.info> 10.217.31.98 CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_SQL|6|src=10.217.253.62 geolocation=Unknown spt=54001 method=GET request=http://aaron.stratum8.net/FFC/login.php?login_name=%27+or&passwd=and+%3B&drinking_pref=on&text_area=select+*+from+%5C+%3B&loginButton=ClickToLogin&as_sfid=AAAAAAXjnGN5gLH-hvhTOpIySEIqES7BjFRs5Mq0fwPp-3ZHDi5yWlRWByj0cVbMyy-Ens2vaaiULKOcUri4OD4kbXWwSY5s7I3QkDsrvIgCYMC9BMvBwY2wbNcSqCwk52lfE0k%3D&as_fid=feeec8758b41740eedeeb6b35b85dfd3d5def30c msg= Special characters seen in fields cn1=74 cn2=762 cs1=pr_ffc cs2=PPE1 cs3=9ztIlf9p1H7p6Xtzn6NMygTv/QM0002 cs4=ALERT cs5=2015 act=transformed
<!--NeedCopy-->

Exemple de message de journal HTML SQL Injection lorsque la demande de publication est bloquée

Jun 26 21:30:34 <local0.info> 10.217.31.98 CEF:0|Citrix|NetScaler|NS11.0|APPFW|APPFW_SQL|6|src=10.217.253.62 geolocation=Unknown spt=9459 method=POST request=http://aaron.stratum8.net/FFC/login_post.php msg=SQL Keyword check failed for field text_area="(')" cn1=78 cn2=834 cs1=pr_ffc cs2=PPE1 cs3=eVJMMPtZ2XgylGrHjkx3rZLfBCI0002 cs4=ALERT cs5=2015 act=blocked
<!--NeedCopy-->

Remarque

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

Exemple :

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

SQL Keyword check failed for field text=\"select a name from testbed1;(;)\".*<blocked>

Dans les versions d’amélioration de 10.5.e prenant en charge le streaming côté demande et la version 11.0 ultérieure, nous consignons uniquement le nom du champ, le mot-clé et le caractère spécial (le cas échéant) dans le message de journal, comme indiqué ci-dessous :

SQL Keyword check failed for field **text="select(;)" <blocked>

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

Pour accéder aux messages du journal à l’aide de l’interface graphique

L’interface graphique 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, puis cliquez sur Contrôles de sécurité. Mettez en surbrillance la ligne Injection HTML SQL et cliquez sur Journaux. Lorsque vous accédez aux journaux directement à partir de la vérification par injection HTML SQL 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 à NetScaler > Système > Audit. Dans la section Messages d’audit, cliquez sur le lien Messages Syslog pour afficher le Syslog Viewer, qui affiche tous les messages du journal, y compris les autres journaux de violations des contrôles de sécurité. Ceci est utile pour le débogage lorsque plusieurs violations de contrôle de sécurité peuvent être déclenchées pendant le traitement des demandes.
• Accédez à Pare-feu des applications > Stratégies > Audit. Dans la section Messages d’audit, cliquez sur le lien Messages Syslog pour afficher le Syslog Viewer, qui affiche tous les messages du journal, y compris les autres journaux de violations des contrôles 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 journal pour la vérification HTML SQL Injection, filtrez en sélectionnant APPFW dans la liste déroulante Options du 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_SQL et que vous cliquez sur le bouton Appliquer, seuls les messages de journal relatifs aux violations de vérification de sécurité d’injection SQL apparaissent dans la visionneuse Syslog.

Si vous placez le curseur sur la ligne d’un message de journal spécifique, plusieurs options, telles que Module, Type d’événement, IDd’événement,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.

La fonctionnalitéCliquer pour déployer n’est disponible que dans l’interface graphique. Vous pouvez utiliser la visionneuse Syslog non seulement pour afficher les journaux, mais également pour déployer des règles de relaxation d’injection SQL HTML 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. La fonctionnalité Cliquer pour déployer n’est disponible que pour les messages de journal générés par l’action Bloquer (ou ne pas bloquer). Vous ne pouvez pas déployer de 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 apparaît dans le coin supérieur droit de la case Syslog Viewer 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. Les optionsModifier et déployer, Déployeret Tout déployer sont disponibles en tant qu’options d’action.

Les règles d’injection SQL déployées à l’aide de l’option Cliquer pour déployer n’incluent pas les recommandations de relaxation du grain fin.

Pour utiliser la fonctionnalité Cliquer pour déployer dans l’interface graphique :

1. Dans la visionneuse Syslog, sélectionnez Pare-feu d’application dans les options du module.
2. Sélectionnez APP_SQL comme type d’événement pour filtrer les messages de journal correspondants.
3. Cochez la case pour identifier la règle à déployer.
4. Utilisez la liste déroulante d’options Action pour déployer la règle de relaxation.
5. Vérifiez que la règle apparaît dans la section de règle de relaxation correspondante.

Statistiques relatives aux violations d’injection SQL

Lorsque l’action de statistiques est activée, le compteur pour la vérification d’injection SQL est incrémenté lorsque le Web App Firewall effectue 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 SQL Injection 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 de trois le compteur de statistiques pour les violations et les journaux, car chaque violation génère un message de journal distinct.

Pour afficher les statistiques de vérification SQL Injection à 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>

Pour afficher les statistiques d’injection HTML SQL à l’aide de l’interface graphique

1. Accédez à Système > Sécurité > Pare-feu d’application.
2. Dans le volet droit, accédez au lien de statistiques.
3. Utilisez la barre de défilement pour afficher les statistiques relatives aux violations et aux journaux d’injection SQL HTML. Le tableau des statistiques fournit des données en temps réel et est mis à jour toutes les 7 secondes.

Résumé

Notez les points suivants concernant la vérification par injection SQL :

• Support intégré pour la protection par injection SQL : NetScaler Web App Firewall protège contre l’injection SQL en surveillant une combinaison de mots clés SQL et de caractères spéciaux dans les paramètres du formulaire. Tous les mots-clés SQL, caractères spéciaux, caractères génériques et règles de transformation par défaut sont spécifiés dans le fichier /netscaler/default_custom_settings.xml.
• Personnalisation : vous pouvez modifier les mots-clés, les caractères spéciaux, les caractères génériques et les règles de transformation par défaut pour personnaliser l’inspection du contrôle de sécurité SQL 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 de signature à votre profil pour utiliser la configuration personnalisée.
• Modèle de sécurité hybride : les signatures et les protections de sécurité avancées utilisent les modèles de script SQL/intersite spécifiés dans l’objet de signature lié au profil. Si aucun objet de signature n’est lié au profil, les modèles de script SQL/intersite présents dans l’objet de signature par défaut sont utilisés.
• Transform—Notez les points suivants concernant l’opération de transformation :
  • L’opération de transformation fonctionne indépendamment des autres paramètres d’action SQL Injection. Si la transformation est activée et que le bloc, le journal, les statistiques et l’apprentissage sont tous désactivés, les caractères spéciaux SQL sont transformés.
  • Lorsque la transformation SQL est activée, les demandes des utilisateurs sont envoyées aux serveurs principaux après la transformation des caractères spéciaux SQL en mode non bloqué. Si l’action de blocage est activée, elle a priorité sur l’action de transformation. Si le type d’injection est spécifié en tant que caractère spécial SQL et que le bloc est activé, la demande est bloquée malgré l’action de transformation.
• Relaxation et apprentissage à grains fins : affinez la règle de relaxation pour détendre un sous-ensemble d’éléments SQL de l’inspection des contrôles de sécurité, mais détecter 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 SQL dans la visionneuse syslog et déployez-les en tant que règles de relaxation.