Partager via

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

  • Article

Il peut arriver que l’Azure Web Application Firewall d’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. Quand ces jetons sont utilisés dans un en-tête de demande, ils peuvent contenir des caractères spéciaux susceptibles de déclencher la détection d’un faux positif par une ou plusieurs règles du pare-feu d’applications web. 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.

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 demande. 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.

Variables de correspondance

Vous pouvez ajouter les attributs de demande suivants à une exclusion :

  • Nom de l’en-tête de la demande
  • Nom de cookie de la demande
  • Nom des arguments de chaîne de la demande
  • Nom des arguments POST du corps de la demande
  • Nom des arguments JSON du corps de la demande (pris en charge sur DRS 2.0 ou version ultérieure)

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 du champ sont toujours évalués. Pour plus d’informations, consultez Exclusion d’autres attributs de demande.

Opérateurs

Vous pouvez spécifier une correspondance exacte avec l’en-tête ou le corps d’une demande, un cookie ou un attribut de chaîne de requête. Ou 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 : correspond à tous les champs de la demande qui contiennent la valeur de sélecteur 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, vous pouvez utiliser l’opérateur Equals any pour configurer une exclusion qui s’applique à tous les en-têtes de demande.

Respect de la casse

Les noms d’en-tête et de cookie se 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 afficher la détection dans le contenu initial du corps. Actuellement, vous ne pouvez pas créer d’exclusions pour le contenu du corps initial.

Définir des règles d’exclusion basées sur les journaux Azure Web Application Firewall

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 de journaux WAF et les sélecteurs d’exclusion correspondants que vous pouvez créer.

matchVariableName des journaux WAF Exclusion de la 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 Nom des arguments JSON du corps de la demande Égal à SOME_NAME

Exclusions pour les corps de demande JSON

À partir de DRS version 2.0, les corps de demande JSON sont inspectés par le WAF. 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, vous pouvez créer une exclusion avec une variable de correspondance Request body JSON args name, un opérateur Equals et un sélecteur 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.

En particulier, quand la valeur matchVariableName est CookieName, HeaderName, PostParamName, ou QueryParamName, cela signifie que le nom du champ, plutôt que sa valeur, a déclenché la règle. L’exclusion de la règle ne propose pas de prise en charge pour ces valeurs matchVariableName pour l’instant.

Étapes suivantes