Como faço para excluir URIs específicos da inspeção de XSS ou SQLi para solicitações HTTP no AWS WAF?

Breve descrição

Às vezes, ocorrem falsos positivos durante a inspeção de regras XSS e SQLi para Regras gerenciadas pela AWS e regras personalizadas. Para evitar falsos positivos, exclua caminhos de URI específicos da inspeção de XSS e SQLi. Para isso, use instruções aninhadas para escrever uma regra de bloqueio com exceções para que o AWS WAF avalie a solicitação em relação a todas as outras regras.

Resolução

Exemplo de solicitação HTTP ou HTTPS

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

Nessa solicitação, o caminho do URI é /path/string1. A sequência de caracteres que segue o ponto de interrogação (?) é a string de consulta. Neste exemplo, a string de consulta é xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201.

Exemplos de regras para permitir URIs específicos da inspeção XSS ou SQLi

Observação: os exemplos de configurações de regras a seguir são apenas para referência. Personalize essas regras para PositionalConstraint, SearchString, TextTransformations e assim por diante. Você pode usar uma lógica semelhante para permitir cabeçalhos específicos, parâmetros de consulta e assim por diante.

Caso 1: usar as Regras gerenciadas pela AWS

O grupo de Regras gerenciadas pela AWS AWSManagedRulesCommonRuleSet contém as seguintes regras:

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

O grupo de regras AWSManagedRulesCommonRuleSet tem uma ação BLOCK que inspeciona uma string de ataque XSS na parte correspondente da solicitação. Para obter mais informações, consulte Grupo de regras gerenciadas do conjunto de regras principais (CRS).

Da mesma forma, o grupo de regras AWSManagedRulesSQLiRuleSet tem regras para inspecionar os parâmetros da consulta, o corpo, o caminho do URI e um cookie para um padrão de ataque de injeção de SQLi. Para obter mais informações, consulte Grupos de regras específicos para casos de uso.

Quando uma solicitação corresponde a essas regras, o AWS WAF gera os rótulos correspondentes. Em seguida, sua regra personalizada na WEB ACL pode usar esses rótulos de Regras gerenciadas pela AWS para excluir seletivamente solicitações específicas das assinaturas de regras correspondentes.

Para permitir URIs específicos, conclua as seguintes etapas:

1. Mantenha as seguintes regras do grupo de regras AWSManagedRulesCommonRuleSet no modo de Contagem:

• CrossSiteScripting_COOKIE
• CrossSiteScripting_QUERYARGUMENTS
• CrossSiteScripting_BODY
• CrossSiteScripting_URIPATH

2. Crie uma regra com uma ação de bloqueio com exceções para caminhos de URI. Configure a regra com uma prioridade menor que a prioridade de AWSManagedRulesCommonRuleSet. Para configurar uma prioridade menor no console do AWS WAF, coloque a regra na parte inferior da lista. Para configurar uma prioridade menor no JSON, use um valor de Prioridade maior.

A regra usa a seguinte lógica:

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

Use a configuração a seguir:

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

Observação: neste exemplo, OrStatement exclui URIs específicos de todos os rótulos e partes da solicitação da web: corpo, cabeçalhos, caminho do URI e argumentos da consulta. Este exemplo pressupõe que você encontrou um falso positivo para o mesmo URI em todas as partes da solicitação da web. No entanto, você pode encontrar um falso positivo em apenas uma parte da solicitação da web, como em argumentos de consulta. Nesse caso, é prática recomendada de segurança criar uma outra regra apenas para uma parte da solicitação da web e o rótulo correspondente. Nessa outra regra, não exclua o caminho específico do URI de todas as partes da solicitação da web.

Para AWSManagedRulesSQLiRuleSet, use as mesmas etapas, mas substitua os rótulos pelos rótulos gerados por AWSManagedRulesSQLiRuleSet.

Se tiver vários URIs que deseja excluir da inspeção, use OrStatement em NotStatement. Por exemplo, para excluir /path/string1 e /path/string2, use o seguinte 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: usar regras personalizadas de XSS e SQLi

A regra usa a seguinte lógica:

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

Use a configuração de regras a seguir para inspecionar as cadeias de caracteres de ataque XSS da solicitação, mas também exclua seletivamente um URI_PATH específico:

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

Siga este procedimento ao usar instruções SQLi.

Observação: não é prática recomendada ter uma regra com maior prioridade que permita apenas o URI. Isso impedirá que a solicitação com URI_PATH permitido seja avaliada em relação a todas as outras regras definidas na Web ACL.

Informações relacionadas

Princípios básicos da declaração de regras

Declaração de regra de ataque de script entre sites

Declaração de regra de ataque de injeção de SQL