Comment exclure des URL spécifiques de l'inspection XSS ou SQLi pour les requêtes HTTP lors de l'utilisation d'AWS WAF ?

Courte description

Des faux positifs surviennent parfois lors de l'inspection des règles XSS et SQLi pour les règles gérées par AWS et les règles personnalisées. Vous pouvez exclure des chemins d'URI spécifiques de l'inspection XSS et SQLi pour éviter les faux positifs. Pour ce faire, utilisez des instructions imbriquées pour rédiger la règle d'autorisation afin que la demande soit évaluée par rapport à toutes les autres règles.

Solution

Exemple de requête HTTP ou HTTPS

http://www.amazon.com/path/string1?abc=123&xyz=567

Dans la requête précédente, le chemin de l'URI est «/path/string1 ». Toute chaîne suivant '? 'est appelée chaîne de requête, telle que' abc=123&xyz=567 'dans l'exemple précédent. Dans la chaîne de requête, « abc » et «xyz » sont les paramètres de requête avec les valeurs « 123 » et « 567 », respectivement.

Exemples de règles pour autoriser des URI spécifiques à partir de l'inspection XSS ou SQLi

Remarque : Les exemples de configurations des règles suivantes sont fournis à titre indicatif uniquement. Vous devez personnaliser ces règles sur PositionalConstraint, SearchString, TextTransformations, etc. Vous pouvez utiliser une logique similaire pour autoriser des en-têtes spécifiques, des paramètres de requête, etc.

Cas 1 : utilisation des règles gérées par AWS

Le groupe de règles gérées par AWS AWSManagedRulesCommonRulesSet contient les règles suivantes :

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

Le groupe de règles AWSManagedRulesCommonRulesCommon possède une action BLOCK qui inspecte la présence d'une chaîne d'attaque XSS dans la partie correspondante de la demande. Pour plus d'informations, consultez la section Groupe de règles géré par ensemble de règles de base (CRS).

De même, le groupe de règles AWSManagedRulesSQLIRuleSet possède des règles pour inspecter les paramètres de requête, un corps et un cookie pour détecter un modèle d'attaque par injection SQLi. Pour plus d'informations, consultez Groupes de règles spécifiques aux cas d'utilisation.

Lorsqu'une demande correspond aux règles précédentes, AWS WAF génère les étiquettes correspondantes. Les étiquettes sont utilisées dans la règle définie ultérieurement dans la liste ACL Web pour exclure sélectivement des demandes spécifiques (en fonction de l'URI, dans cet exemple).

Pour autoriser des URI spécifiques, procédez comme suit :

1.    Conservez les règles suivantes du groupe de règles AWSManagedRulesCommonRulesSet en mode Nombre :

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

2.    Créez une règle d'autorisation configurée avec une priorité inférieure à celle d'AWSManagedRulesCommonRulesSet.

La logique de la règle est la suivante :

(XSS_URIPATH ou XSS_Cookie ou XSS_Body ou XSS_QueryArguments) AND (PAS sur liste blanche URIString) = BLOCK

Utilisez la configuration suivante :

{
  "Name": "whitelist-xss",
  "Priority": 10,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "OrStatement": {
            "Statements": [
              {
                "LabelMatchStatement": {
                  "Scope": "LABEL",
                  "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_URIPath"
                }
              },
              {
                "LabelMatchStatement": {
                  "Scope": "LABEL",
                  "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_Cookie"
                }
              },
              {
                "LabelMatchStatement": {
                  "Scope": "LABEL",
                  "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_Body"
                }
              },
              {
                "LabelMatchStatement": {
                  "Scope": "LABEL",
                  "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_QueryArguments"
                }
              }
            ]
          }
        },
        {
          "NotStatement": {
            "Statement": {
              "ByteMatchStatement": {
                "SearchString": "URI_SearchString",
                "FieldToMatch": {
                  "UriPath": {}
                },
                "TextTransformations": [
                  {
                    "Priority": 0,
                    "Type": "NONE"
                  }
                ],
                "PositionalConstraint": "CONTAINS"
              }
            }
          }
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "whitelist-xss"
  }
}

Suivez les étapes précédentes pour AWSManagedRulesSQLIRuleSet en remplaçant les étiquettes par des étiquettes générées par AWSManagedRulesSQLIRuleSet.

Cas 2 : utilisation de règles personnalisées XSS et SQLi

La logique de la règle est la suivante :

(XSS_URIPATH ou XSS_Cookie ou XSS_Body ou XSS_QueryArguments) AND (PAS sur liste blanche URIString) = BLOCK

Utilisez la configuration suivante pour la règle afin d'inspecter les chaînes d'attaque XSS pour la requête tout en excluant sélectivement un URI_PATH spécifique :

{
  "Name": "xss-URI",
  "Priority": 10,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "xss-URI"
  },
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "OrStatement": {
            "Statements": [
              {
                "XssMatchStatement": {
                  "FieldToMatch": {
                    "UriPath": {}
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ]
                }
              },
              {
                "XssMatchStatement": {
                  "FieldToMatch": {
                    "Cookies": {
                      "MatchPattern": {
                        "All": {}
                      },
                      "MatchScope": "ALL",
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ]
                }
              },
              {
                "XssMatchStatement": {
                  "FieldToMatch": {
                    "Body": {
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ]
                }
              },
              {
                "XssMatchStatement": {
                  "FieldToMatch": {
                    "AllQueryArguments": {}
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ]
                }
              }
            ]
          }
        },
        {
          "NotStatement": {
            "Statement": {
              "ByteMatchStatement": {
                "FieldToMatch": {
                  "UriPath": {}
                },
                "PositionalConstraint": "CONTAINS",
                "SearchString": "URI_SearchString",
                "TextTransformations": [
                  {
                    "Type": "NONE",
                    "Priority": 0
                  }
                ]
              }
            }
          }
        }
      ]
    }
  }
}

Suivez la procédure précédente lorsque vous utilisez des instructions SQLi.

Remarque : Il n'est pas recommandé d'avoir une règle avec une priorité plus élevée qui n'autorise que l'URI. Cela ne permet pas d'évaluer la demande avec l'URI_PATH autorisé par rapport à toutes les autres règles définies dans la liste ACL Web.

---

Informations connexes

Déclarations de règles AWS WAF

Déclaration de règles d'attaque par script intersite

Déclaration de règle d'attaque par injection SQL