Personnaliser Azure Web Application Firewall pour Azure Front Door

Article
08/02/2023

L’ensemble de règles par défaut géré par Microsoft est basé sur l’ensemble de règles OWASP Core (CRS) et comprend les règles de collecte de Microsoft Threat Intelligence.

Il est souvent nécessaire de paramétrer les règles du pare-feu d’applications web (WAF) pour répondre aux besoins particuliers de l’application ou de l’organisation qui l’utilise. En général, les organisations procèdent au réglage en effectuant l’une des actions suivantes :

Définition d’exclusions de règle.
Création de règles personnalisées.
Désactivation des règles susceptibles de générer des problèmes ou des faux positifs.

Cet article décrit ce que vous pouvez faire si les requêtes qui doivent passer par le WAF sont bloquées.

Remarque

L’ensemble de règles gérées par Microsoft n’est pas disponible pour la référence SKU Azure Front Door Standard. Pour plus d’informations sur les références SKU de niveaux différents, reportez-vous à la section Comparaison des fonctionnalités entre les niveaux.

Lisez les sections Vue d’ensemble du WAF sur Azure Front Door et Stratégie WAF pour Front Door. Activez également la Surveillance et la journalisation WAF. Ces articles expliquent le fonctionnement du WAF ainsi que ses ensembles de règles, et l’accès aux journaux du WAF.

Comprendre les journaux du WAF

L’objectif des journaux du WAF est de répertorier chaque requête mise en correspondance ou bloquée par le WAF. Il s’agit d’une collecte de toutes les requêtes évaluées qui sont mises en correspondance ou bloquées. Si vous remarquez que le WAF bloque une demande à tort (faux positif), vous pouvez agir de différentes manières.

Tout d’abord, recherchez la requête en question par élimination. Afin d’identifier facilement l’événement et d’exécuter une requête de journal sur cette valeur spécifique, vous pouvez configurer un message de réponse personnalisé pour inclure le champ trackingReference. Parcourez les journaux pour trouver l’URI, l’horodatage ou l’adresse IP du client de la requête. Lorsque vous avez trouvé les entrées de journal associées, vous pouvez agir sur les faux positifs.

Par exemple, supposez qu’un trafic légitime contienne la chaîne 1=1 que vous voulez faire transiter par votre WAF. La requête se présente ainsi :

POST http://afdwafdemosite.azurefd.net/api/Feedbacks HTTP/1.1
Host: afdwafdemosite.azurefd.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

UserId=20&captchaId=7&captchaId=15&comment="1=1"&rating=3

Si vous tentez la demande, le WAF bloque le trafic qui contient votre chaîne 1=1 dans n’importe quel paramètre ou champ. Il s’agit d’une chaîne souvent associée à une attaque par injection de code SQL. Vous pouvez parcourir les journaux et trouver l’horodatage de la requête et les règles responsables du blocage ou de la mise en correspondance.

L’exemple suivant représente une entrée de journal qui a été générée pour une mise en correspondance de règle. Vous pouvez utiliser la requête Log Analytics suivante pour rechercher les requêtes bloquées au cours des dernières 24 heures.

AzureDiagnostics
| where Category == 'FrontDoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

AzureDiagnostics
| where Category == 'FrontdoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

Dans le champ requestUri, vous pouvez voir que la demande a été effectuée spécifiquement à /api/Feedbacks/. En poussant plus loin notre exploration, nous retrouvons l’ID de règle 942110 dans le champ ruleName. Avec l’ID de règle, vous pouvez accéder au référentiel officiel de l’ensemble de règles OWASP ModSecurity Core et effectuer une recherche sur cet ID de règle, afin d’examiner son code et de comprendre exactement la mise en correspondance de cette règle.

Ensuite, consultez le champ action pour voir que la règle est définie pour bloquer les requêtes lors de la mise en correspondance. Vous pouvez confirmer que le WAF a bloqué la requête, car policyMode est défini sur prevention.

À présent, vérifiez les informations dans le champ details. Celui-ci vous permet d’accéder aux informations matchVariableName et matchVariableValue. La règle a été déclenchée à cause de l’entrée 1=1 dans le champ comment de l’application web.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Il est également intéressant de vérifier les journaux d’accès pour approfondir sa compréhension d’un événement de WAF donné. Ensuite, consultez le journal qui a été généré en réponse à l’événement ci-dessus.

Vous pouvez constater que ces journaux sont associés, car la valeur trackingReference est identique. Parmi les différents champs qui fournissent des insights généraux (comme userAgent et clientIP), attardons-nous sur les champs httpStatusCode et httpStatusDetails. Ceux-ci révèlent que le client a reçu une réponse HTTP 403, ce qui confirme que la requête a été rejetée et bloquée.

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorAccessLog",
    "operationName": "Microsoft.Cdn/Profiles/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorAccessLog",
    "operationName": "Microsoft.Network/FrontDoor/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

Résoudre les faux positifs

Pour prendre une décision avisée sur le traitement d’un faux positif, il est important de se familiariser avec les technologies qu’utilise l’application. Par exemple, supposons que votre pile de technologies ne comporte pas de serveur SQL Server et que vous obtenez des faux positifs liés à ces règles. La désactivation de ces règles n’affaiblit pas nécessairement votre sécurité.

Sachant cela, et étant donné que la règle 942110 est celle qui a mis en correspondance la chaîne 1=1 dans l’exemple, nous pouvons prendre quelques mesures pour éviter le blocage de cette requête légitime :

Utiliser les listes d’exclusions. Pour plus d’informations sur les listes d’exclusions, consultez la section Listes d’exclusions Azure Web Application Firewall avec Azure Front Door.
Changer les actions du WAF. Pour plus d’informations sur les actions qui peuvent être effectuées lorsqu’une requête correspond aux conditions d’une règle, consultez la section Actions WAF.
Utiliser des règles personnalisées. Pour plus d’informations sur les règles personnalisées, consultez la section Règles personnalisées pour un pare-feu d’applications web avec Azure Front Door.
Désactiver les règles.

Conseil

Lorsque vous choisissez une approche visant à autoriser les requêtes légitimes avec le WAF, essayez de la rendre aussi restrictive que possible. Par exemple, il est préférable d’utiliser une liste d’exclusions plutôt que de désactiver une règle entièrement.

Utiliser les listes d’exclusions

Un des avantages de l’utilisation d’une liste d’exclusion réside dans le fait que seule la variable de correspondance que vous sélectionnez pour l’exclusion n’est plus inspectée pour cette requête donnée. Autrement dit, vous pouvez choisir entre des éléments spécifiques à exclure, comme les en-têtes de requête, les cookies de requête, les arguments de chaîne de requête ou les arguments de publication de corps de requête, si une certaine condition est remplie, plutôt que d’exclure la requête entière de l’inspection. Les autres variables non spécifiées de la requête sont toujours inspectées normalement.

Les exclusions sont un paramètre global. L’exclusion configurée s’applique à tout le trafic transitant par le WAF, et pas seulement à une application web ou un URI particulier. Un problème peut se poser, par exemple si 1=1 est une requête valide dans le corps pour une application web donnée, mais pas pour les autres subissant la même stratégie WAF.

S’il est judicieux d’utiliser différentes listes d’exclusion pour différentes applications, prévoyez d’utiliser des stratégies WAF différentes pour chaque application et de les appliquer au serveur front-end de chaque application.

Lorsque vous configurez des listes d’exclusions pour des règles gérées, vous pouvez choisir d’exclure :

Toutes les règles d’un ensemble de règles.
Toutes les règles d’un groupe de règles.
Un utilisateur individuel.

Vous pouvez configurer une liste d’exclusions avec PowerShell, Azure CLI, l’API REST, Bicep, les modèles Azure Resource Manager et le portail Azure.

Exclusions au niveau de la règle : l’application d’exclusions au niveau de la règle signifie que les exclusions spécifiées ne seront pas analysées par rapport à cette seule règle. Elles seront toujours analysées par toutes les autres règles de l’ensemble de règles. Il s’agit du niveau le plus granulaire pour les exclusions. Vous pouvez l’utiliser pour personnaliser l’ensemble de règles géré en fonction des informations des journaux du WAF lorsque vous dépannez un événement.
Exclusions au niveau du groupe de règles : l’application d’exclusions au niveau du groupe de règles signifie que les exclusions spécifiées ne seront pas analysées par rapport à cet ensemble précis de types de règles. Par exemple, si vous sélectionnez SQLI en tant que groupe de règles exclues, les exclusions de requête définies ne seront inspectées par aucune des règles propres à SQLI. Elles continueront d’être inspectées par les règles d’autres groupes, tels que PHP, RFI ou XSS. Ce type d’exclusion peut être utile lorsque vous êtes assuré que l’application n’est pas sujette à des types d’attaques particuliers. Par exemple, une application ne disposant pas de base de données SQL peut voir toutes les règles SQLI exclues sans que cela nuise à son niveau de sécurité.
Exclusions au niveau de l’ensemble de règles : l’application d’exclusions au niveau de l’ensemble de règles signifie que les exclusions spécifiées ne seront pas analysées par rapport aux règles de sécurité disponibles dans cet ensemble de règles. Vous devez utiliser ce type d’exclusion avec précaution, car il est exhaustif.

Dans cet exemple, vous effectuez une exclusion au niveau le plus granulaire en appliquant une exclusion à une seule règle. Pour exclure la variable de mise en correspondance Nom des arguments de publication du corps de la requête qui contient comment. Le résultat est visible dans les journaux du pare-feu où figurent les détails de la variable de mise en correspondance : "matchVariableName": "PostParamValue:comment". L'attribut est comment. Il existe d’autres façons de rechercher ce nom d’attribut. Pour plus d’informations, consultez la section Rechercher les noms d’attributs d’une requête.

Capture d’écran représentant les règles d’exclusion.

Capture d’écran représentant l’exclusion de règle pour une règle donnée.

Parfois, certains paramètres spécifiques peuvent être transmis au WAF de manière peu intuitive. Par exemple, un jeton est transmis lorsque vous vous authentifiez à l’aide de Microsoft Entra ID. Le jeton __RequestVerificationToken est généralement passé sous la forme d’un cookie de requête.

Dans certains cas où les cookies sont désactivés, ce jeton est également transmis comme argument de publication de la requête. Ainsi, pour traiter les faux positifs du jeton Microsoft Entra, vous devez vous assurer que __RequestVerificationToken est ajouté à la liste d’exclusions pour RequestCookieNames et RequestBodyPostArgsNames.

Avec les exclusions sur un nom de champ (sélecteur), la valeur n’est plus évaluée par le WAF. Toutefois, le nom du champ continue d’être évalué. Dans de rares cas, il peut correspondre à une règle WAF et déclencher une action.

Capture d’écran représentant l’exclusion de règle pour un ensemble de règles.

Changer les actions WAF

Pour gérer le comportement des règles WAF, vous pouvez aussi choisir l’action que le pare-feu va effectuer lorsqu’une requête correspond aux conditions d’une règle. Les actions disponibles sont : Autoriser, Bloquer, Journaliser et Rediriger.

Dans cet exemple, nous avons remplacé l’action par défaut Bloquer par l’action Journaliser dans la règle 942110. Cela entraîne la journalisation de la requête par le WAF, et la poursuite de l’évaluation de cette même requête par rapport aux règles de priorité inférieure restantes.

Capture d’écran représentant les actions du WAF.

Après avoir effectué la même requête, vous pouvez revenir aux journaux et constater que ladite requête présente une correspondance avec l’ID de règle 942110. Le champ action_s indique maintenant Journaliser à la place de Bloquer. Nous avons ensuite développé la requête de journal pour inclure les informations trackingReference_s et savoir ce qui s’est produit d’autre avec cette requête.

Capture d’écran représentant un journal avec plusieurs correspondances de règles.

Vous pouvez constater qu’une autre correspondance de règle SQLI se produit quelques millisecondes après le traitement de l’ID de règle 942110. La même requête a correspondu à l’ID de règle 942310, et cette fois-ci, l’action par défaut Bloquer a été déclenchée.

Pouvoir déterminer si plusieurs règles au sein d’un groupe de règles particulier correspondent et bloquent une requête donnée constitue un autre avantage de l’utilisation de l’action Bloquer lors du paramétrage ou du dépannage du WAF. Vous pouvez ensuite créer vos exclusions au niveau approprié, à savoir celui de la règle ou du groupe de règles.

Utiliser des règles personnalisées

Après avoir identifié l’origine d’une correspondance de règle WAF, vous pouvez utiliser des règles personnalisées pour ajuster la manière dont le WAF répond à l’événement. Les règles personnalisées sont traitées avant les règles gérées. Elles peuvent contenir plusieurs conditions, et Autoriser, Refuser, Journaliser ou Rediriger constituent leurs actions possibles.

Avertissement

Lorsqu’une requête correspond à une règle personnalisée, le moteur WAF cesse de la traiter. Les règles gérées ne seront pas traitées pour cette requête ; les autres règles personnalisées de priorité inférieure non plus.

L’exemple suivant représentante une règle personnalisée avec deux conditions. La première condition recherche la valeur comment dans le corps de la requête. La deuxième condition recherche la valeur /api/Feedbacks/ dans l’URI de la requête.

Vous pouvez utiliser une règle personnalisée de la façon la plus granulaire possible, afin d’affiner vos règles WAF et de traiter les faux positifs. Dans ce cas, n’effectuez aucune action qui se baserait uniquement sur la valeur du corps de la requête comment, comme cela peut exister sur plusieurs sites ou applications appliquant la même stratégie WAF.

Inclure une autre condition pour qu’elle corresponde également à un URI de requête particulier /api/Feedbacks/ vous assure que cette règle personnalisée s’applique véritablement au cas d’usage explicite que vous avez pris en compte. Ainsi, une même attaque (si elle est effectuée dans des conditions différentes) sera toujours inspectée et contrée par le moteur du WAF.

Capture d’écran représentant un journal.

Lorsque vous explorez le journal, vous pouvez remarquer que le champ ruleName_s contient le nom donné à la règle personnalisée redirectcomment. Dans le champ action_s, vous pouvez constater que l’action Rediriger a été effectuée pour cet événement. Dans le champ details_matches_s, vous pouvez constater que les informations des deux conditions ont été mises en correspondance.

Désactiver les règles

Pour contourner un faux positif, vous pouvez aussi désactiver la règle qui a mis en correspondance l’entrée considérée malveillante par le WAF. Comme vous avez analysé les journaux du WAF et identifié la règle 942110, vous pouvez la désactiver sur le portail Azure. Pour plus d’informations, consultez la section Personnaliser les règles Azure Web Application Firewall avec le portail Azure.

La désactivation d’une règle est avantageuse lorsque vous êtes sûr que toutes les requêtes répondant à cette condition particulière sont légitimes ou que la règle ne s’applique tout simplement pas à l’environnement (par exemple, la désactivation d’une règle d’injection SQL lorsque vous disposez de back-ends non-SQL).

La désactivation d’une règle est un paramètre global qui s’applique à tous les hôtes front-end associés à la stratégie WAF. Lorsque vous choisissez de désactiver une règle, vous risquez de laisser des vulnérabilités exposées sans protection ni détection pour d’autres hôtes front-end associés à la stratégie WAF.

Si vous souhaitez utiliser Azure PowerShell pour désactiver une règle gérée, consultez la documentation de l’objet PSAzureManagedRuleOverride. Si vous souhaitez utiliser l’interface Azure CLI, consultez la documentation az network front-door waf-policy managed-rules override.

Capture d’écran représentant les règles de WAF.

Conseil

Il est judicieux de documenter tous les changements que vous apportez à la stratégie WAF. Incluez des exemples de requête pour illustrer la détection de faux positifs. Expliquez pourquoi vous avez ajouté une règle personnalisée, désactivé une règle ou un ensemble de règles, ou ajouté une exception. Si vous repensez votre application à l’avenir, vous devez vérifier que vos changements sont toujours valides. Vous pouvez être audité ou avoir besoin de justifier la raison pour laquelle vous avez reconfiguré la stratégie WAF à partir de ses paramètres par défaut.

Rechercher des champs de requête

Avec un proxy de navigateur (comme Fiddler), vous pouvez inspecter les différentes requêtes et identifier quels champs spécifiques d’une page web sont appelés. Cette technique est utile lorsqu’il faut exclure certains champs de l’inspection à l’aide de listes d’exclusions dans le WAF.

Rechercher les noms d’attributs d’une requête

Dans cet exemple, le champ dans lequel la chaîne 1=1 a été entrée s’appelle comment. Ces données ont été transmises dans le corps d’une requête POST.

Capture d’écran représentant le corps d’une requête Fiddler.

Vous pouvez exclure ce champ. Pour en savoir plus sur les listes d’exclusions, consultez Listes d’exclusions du pare-feu d’applications web. Vous pouvez exclure l’évaluation dans ce cas en configurant l’exclusion suivante :

Capture d’écran représentant une règle d’exclusion.

L’examen des journaux du pare-feu peut vous renseigner sur les éléments que vous devez ajouter à la liste d’exclusion. Pour activer la journalisation, consultez Supervision des journaux et des métriques dans Azure Front Door.

Examinez le journal du pare-feu dans le fichier PT1H.json pendant l’heure à laquelle s’est produite la requête que vous voulez inspecter. Les fichiers PT1H.json sont disponibles dans les conteneurs du compte de stockage où sont stockés les journaux de diagnostic FrontDoorWebApplicationFirewallLog et FrontDoorAccessLog.

Examinez le journal du pare-feu dans le fichier PT1H.json pendant l’heure à laquelle s’est produite la requête que vous voulez inspecter. Les fichiers PT1H.json sont disponibles dans les conteneurs du compte de stockage où sont stockés les journaux de diagnostic FrontdoorWebApplicationFirewallLog et FrontdoorAccessLog.

Dans cet exemple, vous pouvez voir la règle qui a bloqué la requête (avec la même référence de transaction) et qui s’est produite exactement au même moment.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Du fait de vos connaissances sur le fonctionnement des ensembles de règles gérées par Azure, vous savez que la règle dotée de la propriété action: Block bloque en fonction des données qui ont été mises en correspondance dans le corps de la requête. (Pour plus d’informations, consultez Azure Web Application Firewall dans Azure Front Door.) Les informations révèlent qu’il met en correspondance un modèle (1=1) et que le champ est nommé comment. Suivez les mêmes étapes que précédemment pour exclure le nom des arguments de publication du corps de la requête qui contient comment.

Rechercher les noms d’en-tête d’une requête

Fiddler est un outil utile quand il s’agit de rechercher les noms d’en-tête d’une requête. La capture d’écran suivante représente les en-têtes de la requête GET, avec Content-Type et User-Agent. Vous pouvez également utiliser des en-têtes de requête pour créer des exclusions et des règles personnalisées dans le WAF.

Capture d’écran représentant l’en-tête d’une requête Fiddler.

Pour examiner les en-têtes de requête et de réponse, vous pouvez aussi regarder dans les outils de développement de votre navigateur (comme Microsoft Edge ou Chrome). Vous pouvez sélectionner F12 ou cliquer avec le bouton droit sur Inspecter >Outils de développement. Sélectionnez l’onglet Réseau. Chargez une page web et sélectionnez la requête à inspecter.

Capture d’écran représentant une requête Network Inspector.

Si la requête contient des cookies, sélectionnez l’onglet Cookies pour les examiner dans Fiddler. Les informations sur les cookies peuvent également être utilisées pour créer des exclusions ou des règles personnalisées dans le WAF.

Règle de scoring d’anomalie

Si l’ID de règle 949110 s’affiche pendant le processus de paramétrage de votre WAF, cela indique que la requête a été bloquée par le processus de scoring d’anomalie.

Passez en revue les autres entrées du journal du WAF pour la même requête, en recherchant les entrées de journal avec la même référence de suivi. Examinez chacune des règles déclenchées. Personnalisez chaque règle en suivant les instructions du présent article.

Avertissement

Lors de l’attribution d’un nouvel ensemble de règles gérées à une stratégie WAF, toutes les personnalisations précédentes des ensembles de règles gérées existants, telles que l’état de la règle, les actions de règle et les exclusions de niveau de la règle, seront réinitialisées sur les valeurs par défaut du nouvel ensemble de règles gérées. Toutefois, toutes les règles personnalisées et les paramètres de stratégie resteront inchangés lors de l’attribution du nouvel ensemble de règles.

Étapes suivantes

En savoir plus sur le pare-feu d’application web Azure.
Découvrez comment créer une instance Azure Front Door.

Partage via

Personnaliser Azure Web Application Firewall pour Azure Front Door

Comprendre les journaux du WAF

Résoudre les faux positifs

Utiliser les listes d’exclusions

Changer les actions WAF

Utiliser des règles personnalisées

Désactiver les règles

Rechercher des champs de requête

Rechercher les noms d’attributs d’une requête

Rechercher les noms d’en-tête d’une requête

Règle de scoring d’anomalie

Étapes suivantes

Commentaires

Ressources supplémentaires

Partage via

Personnaliser Azure Web Application Firewall pour Azure Front Door

Comprendre les journaux du WAF

Résoudre les faux positifs

Utiliser les listes d’exclusions

Changer les actions WAF

Utiliser des règles personnalisées

Désactiver les règles

Rechercher des champs de requête

Rechercher les noms d’attributs d’une requête

Rechercher les noms d’en-tête d’une requête

Rechercher les noms de cookie d’une requête

Règle de scoring d’anomalie

Étapes suivantes

Commentaires

Ressources supplémentaires