Web Application Firewall avec les listes d'exclusion d'Azure Front Door

S’applique à : ✔️ Front Door Premium

Parfois, Azure Web Application Firewall dans Azure Front Door bloque une demande légitime. Au moment de régler votre pare-feu d’applications web (WAF), vous pouvez le configurer de sorte qu’il autorise les demandes de votre application. Les listes d’exclusion WAF vous permettent d’omettre certains attributs de demande dans une évaluation WAF. Le reste de la requête est évalué comme étant normal.

Par exemple, Microsoft Entra ID fournit des jetons qui sont utilisés pour l’authentification. Lorsque ces jetons sont utilisés dans un en-tête de requête, ils peuvent contenir des caractères spéciaux qui déclenchent une détection de faux positifs par une ou plusieurs règles WAF. Vous pouvez ajouter l’en-tête à une liste d’exclusions, ce qui indique au WAF d’ignorer l’en-tête. Le WAF inspecte toujours le reste de la demande à la recherche de contenu suspect éventuel.

Étendues d’exclusion

Vous pouvez créer des exclusions dans les étendues suivantes :

  • Ensemble de règles : Ces exclusions s’appliquent à toutes les règles d’un ensemble de règles.
  • Groupe de règles : Ces exclusions s’appliquent à toutes les règles d’une catégorie particulière dans un ensemble de règles. Par exemple, vous pouvez configurer une exclusion qui s’applique à toutes les règles d’injection SQL.
  • Règle : ces exclusions s’appliquent à une seule règle.

Conseil / Astuce

Rendez les exclusions aussi étroites et spécifiques que possible pour éviter de laisser accidentellement la place aux attaquants pour exploiter votre système. Lorsque vous devez ajouter une règle d’exclusion, utilisez des exclusions par règle dans la mesure du possible.

Sélecteurs d’exclusion

Les sélecteurs d’exclusion identifient les parties des demandes auxquelles l’exclusion s’applique. Le pare-feu d’applications web ignore toutes les détections qu’il trouve dans les parties spécifiées de la requête. Vous pouvez spécifier plusieurs sélecteurs d’exclusion dans une même exclusion.

Chaque sélecteur d’exclusion spécifie une variable de correspondance, un opérateur et un sélecteur. Plusieurs correspondances dans une seule exclusion sont traitées comme des expressions « OU ».

Variables de correspondance

Ajoutez les attributs de requête suivants à une exclusion :

  • Nom de l’en-tête de la demande
  • Nom du cookie de la requête
  • Nom des arguments de chaîne de requête
  • Nom des paramètres POST dans le corps de la requête
  • Nom des arguments JSON dans le corps de la requête (pris en charge sur DRS 2.0 ou plus)

Les valeurs des champs que vous utilisez ne sont pas évaluées par rapport aux règles WAF, mais leurs noms sont évalués. Les listes d’exclusion désactivent l’inspection de la valeur du champ. Toutefois, les noms des champs sont toujours évalués. Pour plus d’informations, consultez Exclusion d’autres attributs de demande.

Opérateurs

Spécifiez un en-tête de requête, un corps, un cookie ou un attribut de chaîne de requête exact à mettre en correspondance. Vous pouvez de manière optionnelle spécifier des correspondances partielles. Les opérateurs suivants sont pris en charge pour les critères de correspondance :

  • Égal à : correspond à tous les champs de la demande qui correspondent exactement à la valeur de sélecteur spécifiée. Par exemple, pour sélectionner l’en-tête bearerToken, utilisez l’opérateur Equals avec le sélecteur défini sur bearerToken.
  • Commence par : correspond à tous les champs de la demande qui commencent par la valeur de sélecteur spécifiée.
  • Se termine par : correspond à tous les champs de la demande qui se terminent par la valeur de sélecteur spécifiée.
  • Contient : fait correspondre tous les champs de requête qui contiennent la valeur de sélection spécifiée.
  • Égal à tout : correspond à tous les champs de la demande. Quand vous utilisez l’opérateur Equals any, la valeur du sélecteur est automatiquement définie sur *. Par exemple, utilisez l’opérateur Equals any pour configurer une exclusion qui s’applique à tous les en-têtes de requête.

Sensibilité à la casse

Les noms d'en-tête et de cookie ne sont pas sensibles à la casse. Les chaînes de requête, les arguments POST et les arguments JSON respectent la casse.

Inspection du contenu du corps

Certaines règles managées évaluent la charge utile brute du corps de la demande, avant qu’il soit analysé dans des arguments POST ou des arguments JSON. Ainsi, dans certaines situations, vous pouvez voir des entrées de journal ayant une valeur matchVariableName de InitialBodyContents ou DecodedInitialBodyContents.

Par exemple, supposons que vous créez une exclusion avec une variable de correspondance Request body POST args et un sélecteur pour identifier et ignorer les arguments POST nommé FOO. Vous ne voyez plus d'entrées de journal avec une valeur matchVariableName de PostParamValue:FOO. Toutefois, si un argument POST nommé FOO contient du texte qui déclenche une règle, le journal peut indiquer la détection dans le contenu initial du message. Vous ne pouvez actuellement pas créer d’exclusions pour le contenu initial.

Définir des règles d’exclusion basées sur les journaux du pare-feu d'application web Azure

Vous pouvez utiliser les journaux pour afficher les détails d’une demande bloquée, notamment les parties de la demande qui ont déclenché la règle. Pour plus d’informations, consultez Analyse et journalisation du pare-feu d’applications web Azure.

Parfois, une règle WAF spécifique génère des détections de faux positifs à partir des valeurs incluses dans un en-tête de demande, un cookie, un argument POST, un argument de chaîne de requête ou un champ JSON dans un corps de la demande. Si ces détections de faux positifs se produisent, vous pouvez configurer la règle afin qu’elle exclue de son évaluation la partie appropriée de la demande.

Le tableau suivant présente des exemples de valeurs issues des journaux WAF et les sélecteurs d’exclusion correspondants que vous pouvez créer.

matchVariableName dans les journaux WAF Exclusion d'une règle dans le portail
CookieValue :SOME_NAME Nom de cookie de la demande Égal à SOME_NAME
HeaderValue : SOME_NAME Nom de l’en-tête de la demande Égal à SOME_NAME
PostParamValue : SOME_NAME Nom des arguments POST du corps de la demande Égal à SOME_NAME
QueryParamValue : SOME_NAME Nom des arguments de chaîne de requête Égal à SOME_NAME
JsonValue :SOME_NAME Corps de la requête: nom des arguments JSON doit être égal à SOME_NAME

Exclusions pour les corps de demande JSON

À compter de drS version 2.0, le WAF inspecte les corps de requête JSON. Par exemple, considérez ce corps de la demande JSON :

{
  "posts": [
    {
      "id": 1,
      "comment": ""
    },
    {
      "id": 2,
      "comment": "\"1=1\""
    }
  ]
}

La demande inclut une séquence de caractères de commentaire SQL, que le WAF détecte comme une attaque potentielle par injection de code SQL.

Si vous déterminez que la demande est légitime, créez une exclusion avec une variable de correspondance Request body JSON args name, un opérateur de Equals, et un sélecteur de posts.comment.

Exclure d’autres attributs de demande

Si votre entrée de journal WAF affiche une valeur matchVariableName qui n’est pas dans le tableau précédent, vous ne pouvez pas créer d’exclusion. Par exemple, vous ne pouvez pas créer d’exclusions pour les noms de cookies, les noms d’en-tête, les noms de paramètres POST ou les noms de paramètres de requête.

Envisagez plutôt d’effectuer l’une des actions suivantes :

  • Désactivez les règles qui donnent des faux positifs.
  • Créez une règle personnalisée qui autorise explicitement ces demandes. Les demandes contournent toutes les inspections WAF.

Lorsque la matchVariableName valeur est CookieName, HeaderNameou PostParamName, ou QueryParamName, signifie le nom du champ, plutôt que sa valeur, a déclenché la règle. L’exclusion de règle ne prend pas en charge ces matchVariableName valeurs.

Étapes suivantes