Come si escludono URI specifici da ispezioni XSS o SQLi per le richieste HTTP quando si utilizza AWS WAF?

Breve descrizione

Talvolta si verificano falsi positivi durante l'ispezione delle regole XSS e SQLi per le regole gestite AWS e regole personalizzate. Per evitare falsi positivi, escludere percorsi URI specifici dall'ispezione XSS e SQLi. A tale scopo, utilizzare istruzioni annidate per scrivere una regola di autorizzazione con eccezioni, in modo che AWS WAF valuti la richiesta rispetto a tutte le altre regole.

Risoluzione

Esempio di richiesta HTTP o HTTPS

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

Nella richiesta precedente, il percorso dell'URI è /path/string1. La stringa che segue il punto interrogativo (?) è denominata stringa di query. In questo esempio, la stringa di query è xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201.

Regole di esempio per autorizzare URI specifici dalle ispezioni XSS o SQLi

Nota: Le seguenti configurazioni di regole di esempio sono indicate solo come riferimento. Personalizza queste regole per informazioni come ** PositionalConstraint**, ** SearchString ** e TextTransformations. Puoi utilizzare una logica simile per consentire configurazioni come intestazioni e parametri di query specifici.

Caso 1: Utilizzo delle regole gestite AWS

Il gruppo di regole gestite AWS AWSManagedRulesCommonRuleSet contiene le seguenti regole:

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

Il gruppo di regole AWSManagedRulesCommonRuleSet dispone di un'azione BLOCK che verifica la presenza di una stringa di attacco XSS nella parte corrispondente della richiesta. Per ulteriori informazioni, consulta Core rule set (CRS) managed rule group.

Allo stesso modo, il gruppo di regole AWSManagedRulesSQLiRuleSet dispone di regole per ispezionare i parametri di query, il corpo, il percorso URI e un cookie per un modello di attacco di iniezione SQLi. Per ulteriori informazioni, consulta Use-case specific rule groups.

Quando una richiesta soddisfa queste regole, AWS WAF genera le etichette corrispondenti. Quindi, la tua regola personalizzata nell'ACL WEB può utilizzare queste etichette di regole gestite da AWS per escludere selettivamente richieste specifiche dalle firme delle regole corrispondenti.

Per autorizzare URI specifici, completa i seguenti passaggi:

1. Mantieni le seguenti regole dal gruppo di regole AWSManagedRulesCommonRuleSet in modalità Count:
   CrossSiteScripting_COOKIE
   CrossSiteScripting_QUERYARGUMENTS
   CrossSiteScripting_BODY
   CrossSiteScripting_URIPATH
2. Crea una regola con un'azione di blocco con eccezioni per i percorsi URI. Configura la regola con una priorità inferiore rispetto alla priorità di AWSManagedRulesCommonRuleSet. Per configurare una priorità inferiore nella console AWS WAF, posiziona la regola più in basso nell'elenco. Per configurare una priorità inferiore in JSON, usa un valore Priority più grande.
   La logica della regola è la seguente: (XSS_URIPATH or XSS_Cookie or XSS_Body or XSS_QueryArguments) AND (NOT allowlisted URIString) = BLOCK
   Usa la seguente configurazione:

   {
     "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"
     }
   }

   Nota: in questo esempio,OrStatement esclude URI specifici da tutte le etichette e parti della richiesta web: corpo, intestazioni, percorso URI e argomenti di query. Questo esempio presuppone che sia stato rilevato un falso positivo per lo stesso URI in tutte le parti della richiesta web. Tuttavia, è possibile riscontrare un falso positivo solo in una parte della richiesta web, ad esempio negli argomenti delle query. In questo caso, è consigliabile creare una regola separata per una sola parte della richiesta web e l'etichetta corrispondente. Per questa regola separata, non escludere il percorso URI specifico da tutte le parti della richiesta web.

Per AWSManagedRulesSQLiRuleSet, segui gli stessi passaggi, ma sostituisci le etichette con le etichette generate da AWSManagedRulesSQLiRuleSet.

Se vuoi escludere più URI dall'ispezione, usa OrStatement all'interno di NotStatement. Ad esempio, per escludere /path/string1 e /path/string2, usa il seguente 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"
            }
          }
        ]
      }
    }
  }
}

Caso 2: Usa regole XSS e SQLi personalizzate

La logica della regola è la seguente:

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

Usa la seguente configurazione delle regole per ispezionare le stringhe di attacco XSS per la richiesta, ma escludi anche selettivamente un URI_PATH specifico:

{
  "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
                  }
                ]
              }
            }
          }
        }
      ]
    }
  }
}

Segui questa procedura quando usi le istruzioni SQLi.

Nota: non è consigliabile avere una regola con priorità più alta che autorizzi solo l'URI. Ciò impedisce alla richiesta URI_PATH autorizzata di essere valutata rispetto a tutte le altre regole definite nell'ACL Web.

Informazioni correlate

Rule statement basics

Cross-site scripting attack rule statement

SQL injection attack rule statement