Wie schließe ich bestimmte URIs von der XSS- oder SQLi-Inspektion für HTTP-Anfragen in AWS WAF aus?

Kurzbeschreibung

Falsch-positive Ereignisse treten manchmal während der Überprüfung von XSS- und SQLi-Regeln für AWS Managed Rules und benutzerdefinierte Regeln auf. Um falsch-positive Ereignisse zu vermeiden, schließen Sie bestimmte URI-Pfade von der XSS- und SQLi-Inspektion aus. Verwenden Sie dazu verschachtelte Anweisungen, um eine Sperrregel mit Ausnahmen zu schreiben, sodass AWS WAF die Anfrage anhand aller anderen Regeln bewertet.

Auflösung

Beispiel für eine HTTP- oder HTTPS-Anfrage

http://www.amazon.com/path/string1?xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201

In der vorherigen Anfrage lautet der URI-Pfad /path/string1. Die Zeichenfolge, die auf das Fragezeichen (?) folgt, ist die Abfragezeichenfolge. In diesem Beispiel lautet die Abfragezeichenfolge xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201.

Beispielregeln zum Zulassen bestimmter URIs aus der XSS- oder SQLi-Überprüfung

Um bestimmte URIs für XSS- oder SQLi-Inspektionen zuzulassen, können Sie von AWS verwaltete Regeln oder benutzerdefinierte XSS- und SQLi-Regeln verwenden.

Hinweis: Die folgenden beispielhaften Regelkonfigurationen dienen nur als Referenz. Passen Sie diese Regeln für Informationen wie PositionalConstraint, SearchString und TextTransformations für Ihren Anwendungsfall an. Sie können eine ähnliche Logik verwenden, um Konfigurationen wie spezifische Header und Abfrageparameter zuzulassen.

Von AWS verwaltete Regeln verwenden

Die von AWS verwaltete Regelgruppe AWSManagedRulesCommonRuleSet enthält die folgenden Regeln:

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

Die Regelgruppe AWSManagedRulesCommonRuleSet verfügt über eine BLOCK-Aktion, die den entsprechenden Teil der Anforderung auf eine XSS-Angriffszeichenfolge untersucht. Weitere Informationen findest du unter Verwaltete Regelgruppe „Core Rule Set“ (CRS).

Ebenso verfügt die Regelgruppe AWSManagedRulesSQLiRuleSet über Regeln zur Überprüfung von Abfrageparametern, des Texts, des URI-Pfads und eines Cookies auf ein Angriffsmuster durch SQL-Injektion (SQLi). Weitere Informationen findest du unter Use-case spezifische Regelgruppen.

Wenn eine Anforderung mit diesen Regeln übereinstimmt, generiert AWS WAF die entsprechenden Labels. Anschließend kann deine benutzerdefinierte Regel in der Web-ACL diese Labels der von AWS verwalteten Regeln verwenden, um bestimmte Anforderungen gezielt von übereinstimmenden Regelsignaturen auszuschließen.

Führe die folgenden Schritte aus, um bestimmte URIs zuzulassen:

1. Lege die folgenden Regeln aus der Regelgruppe AWSManagedRulesCommonRuleSet auf den Count-Modus fest:
   CrossSiteScripting_COOKIE
   CrossSiteScripting_QUERYARGUMENTS
   CrossSiteScripting_BODY
   CrossSiteScripting_URIPATH
2. Erstelle eine Regel mit einer BLOCK-Aktion mit Ausnahmen für URI-Pfade. Konfiguriere die Regel mit einer niedrigeren Priorität als die Priorität von AWSManagedRulesCommonRuleSet. Um in der AWS WAF-Konsole eine niedrigere Priorität zu konfigurieren, platziere die Regel weiter unten in der Liste. Um eine niedrigere Priorität in JSON zu konfigurieren, verwende einen größeren Wert für Priority (Priorität).
   Die Regel verwendet die folgende Logik: (XSS_URIPATH or XSS_Cookie or XSS_Body or XSS_QueryArguments) AND (NOT allowlisted URIString) = BLOCK
   Verwende die folgende Konfiguration:

   {
     "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": "/path/string1",
                   "FieldToMatch": {
                     "UriPath": {}
                   },
                   "TextTransformations": [
                     {
                       "Priority": 0,
                       "Type": "NONE"
                     }
                   ],
                   "PositionalConstraint": "CONTAINS"
                 }
               }
             }
           }
         ]
       }
     },
     "Action": {
       "Block": {}
     },
     "VisibilityConfig": {
       "SampledRequestsEnabled": true,
       "CloudWatchMetricsEnabled": true,
       "MetricName": "whitelist-xss"
     }
   }

   Hinweis: In diesem Beispiel schließt OrStatement bestimmte URIs aus allen Labels und Teilen der Webanforderung aus, z. B. Text, Header, URI-Pfad und Abfrageargumente. In diesem Beispiel wird davon ausgegangen, dass du bei derselben URI in allen Teilen der Webanforderung auf einen Fehlalarm gestoßen bist. Möglicherweise tritt ein Fehlalarm jedoch nur in einem Teil der Webanforderung auf, z. B. in den Abfrageargumenten. In diesem Fall ist es eine bewährte Sicherheitspraxis, eine separate Regel nur für einen Teil der Webanforderung und das entsprechende Label zu erstellen. Schließe für diese separate Regel den spezifischen URI-Pfad nicht aus allen Teilen der Webanforderung aus.

Befolge für AWSManagedRulesSQLiRuleSet dieselben Schritte, ersetze die Labels jedoch durch von AWSManagedRulesSQLiRuleSet generierte Labels.

Wenn du mehrere URIs hast, die du von der Inspektion ausschließen möchtest, verwende OrStatement innerhalb von NotStatement. Um beispielsweise /path/string1 und /path/string2 auszuschließen, verwende das folgende NotStatement:

{
  "NotStatement": {
    "Statement": {
      "OrStatement": {
        "Statements": [
          {
            "ByteMatchStatement": {
              "SearchString": "/path/string1",
              "FieldToMatch": {
                "UriPath": {}
              },
              "TextTransformations": [
                {
                  "Priority": 0,
                  "Type": "NONE"
                }
              ],
              "PositionalConstraint": "CONTAINS"
            }
          },
          {
            "ByteMatchStatement": {
              "SearchString": "/path/string2",
              "FieldToMatch": {
                "UriPath": {}
              },
              "TextTransformations": [
                {
                  "Priority": 0,
                  "Type": "NONE"
                }
              ],
               PositionalConstraint": "CONTAINS"
            }
          }
        ]
      }
    }
  }
}

Benutzerdefinierte XSS- und SQLi-Regeln verwenden

Die Regel in diesem Beispiel verwendet die folgende Logik:

(XSS_URIPATH or XSS_Cookie or XSS_Body or XSS_QueryArguments) AND (NOT allowlisted URIString) = BLOCK

Verwende die folgende Regelkonfiguration, um XSS-Angriffszeichenfolgen für die Anforderung zu überprüfen und zudem einen bestimmten URI_PATH gezielt auszuschließen:

{
  "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": "/path/string1",
                "TextTransformations": [
                  {
                    "Type": "NONE",
                    "Priority": 0
                  }
                ]
              }
            }
          }
        }
      ]
    }
  }
}

Gehe ebenso vor, wenn du SQLi-Anweisungen verwendest.

Hinweis: Erstelle keine Regel mit hoher Priorität, die Datenverkehr nur basierend auf der URI zulässt. Dies ist keine bewährte Praxis, da dadurch die Auswertung aller anderen Regeln in der Web-ACL für Anforderungen umgangen wird, die mit diesem URI-Pfad übereinstimmen. 

Weitere Informationen

Verwenden von Regelanweisungen in AWS WAF

Cross-Site-Scripting-Angriffsregel-Anweisung

SQL-Injection-Angriff-Regelanweisung

Wie verwende ich AWS WAF, um den Zugriff auf bestimmte URI-Pfade zuzulassen oder zu blockieren?