¿Cómo excluyo los URI específicos de la inspección de XSS o SQLi para las solicitudes HTTP en AWS WAF?

6 minutos de lectura
0

Cuando utilizo AWS WAF, obtengo falsos positivos por inyección de código SQL (SQLi) o scripting entre sitios (XSS) en determinadas solicitudes HTTP. Quiero excluir URI específicos de la inspección de XSS o SQLi para las solicitudes HTTP.

Breve descripción

A veces, se producen falsos positivos durante la inspección de las reglas XSS y SQLi para las reglas administradas y las reglas personalizadas de AWS. Para evitar falsos positivos, excluya las rutas URI específicas de la inspección de XSS y SQLi. Para ello, utilice sentencias anidadas para escribir una regla de bloqueo con excepciones, de modo que AWS WAF evalúe la solicitud comparándola con todas las demás reglas.

Resolución

Ejemplo de solicitud HTTP o HTTPS

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

En esta solicitud, la ruta del URI es /path/string1. La cadena que sigue al signo de interrogación (?) es la cadena de consulta. En este ejemplo, la cadena de consulta es xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201.

Ejemplos de reglas para permitir URI específicos de la inspección de XSS o SQLi

Nota: Las siguientes configuraciones de reglas de ejemplo son solo de referencia. Personalice estas reglas para PositionalConstraint, SearchString, TextTransformations, etc. Puede usar una lógica similar para permitir encabezados específicos, parámetros de consulta, etc.

Caso 1: Utilizar las reglas administradas de AWS

El grupo de reglas administradas de AWS AWSManagedRulesCommonRuleSet contiene las siguientes reglas:

  • CrossSiteScripting_COOKIE
  • CrossSiteScripting_QUERYARGUMENTS
  • CrossSiteScripting_BODY
  • CrossSiteScripting_URIPATH

El grupo de reglas AWSManagedRulesCommonRuleSet tiene una acción BLOCK que inspecciona la cadena de ataque XSS en la parte correspondiente de la solicitud. Para obtener más información, consulte Grupo de reglas gestionado por el conjunto de reglas principales (CRS).

Del mismo modo, el grupo de reglas AWSManagedRulesSQLiRuleSet tiene reglas para inspeccionar los parámetros de consulta, el cuerpo, la ruta del URI y una cookie para detectar un patrón de ataque de inyección de código SQL. Para obtener más información, consulte Grupos de reglas específicos para casos de uso.

Cuando una solicitud cumple con estas reglas, AWS WAF genera las etiquetas correspondientes. A continuación, su regla personalizada en la ACL WEB puede usar estas etiquetas de reglas administradas de AWS para excluir de forma selectiva solicitudes específicas de las firmas de reglas coincidentes.

Para permitir URI específicos, complete los siguientes pasos:

1. Mantenga las siguientes reglas del grupo de reglas AWSManagedRulesCommonRuleSet en el modo Recuento:

  • CrossSiteScripting_COOKIE
  • CrossSiteScripting_QUERYARGUMENTS
  • CrossSiteScripting_BODY
  • CrossSiteScripting_URIPATH

2. Cree una regla con una acción de bloqueo con excepciones para las rutas URI. Configure la regla con una prioridad inferior a la prioridad de AWSManagedRulesCommonRuleSet. Para configurar una prioridad más baja en la consola de AWS WAF, coloque la regla en la parte inferior de la lista. Para configurar una prioridad más baja en JSON, utilice un valor de prioridad mayor.

La regla usa la siguiente lógica:

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

Utilice la siguiente configuración:

{
  "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: En este ejemplo, la OrStatement excluye los URI específicos de todas las etiquetas y partes de la solicitud web: cuerpo, encabezados, ruta del URI y argumentos de consulta. En este ejemplo, se supone que ha encontrado un falso positivo para el mismo URI en todas las partes de la solicitud web. Sin embargo, es posible que encuentre un falso positivo solo en una parte de la solicitud web, como en los argumentos de la consulta. En este caso, es una práctica recomendada de seguridad crear una regla independiente para solo una parte de la solicitud web y su etiqueta correspondiente. Para esta regla independiente, no excluya la ruta URI específica de todas las partes de la solicitud web.

Para AWSManagedRulesSQLiRuleSet, siga los mismos pasos, pero sustituya las etiquetas por etiquetas generadas por AWSManagedRulesSQLiRuleSet.

Si tiene varios URI que desea excluir de la inspección, utilice OrStatement dentro de NotStatement. Por ejemplo, para excluir /path/string1 y /path/string2, utilice la siguiente 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: Utilizar reglas XSS y SQLi personalizadas

La regla usa la siguiente lógica:

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

Utilice la siguiente configuración de reglas para inspeccionar las cadenas de ataque XSS de la solicitud, pero también excluya selectivamente un 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 procedimiento cuando utilice sentencias SQLi.

Nota: No se recomienda tener una regla con mayor prioridad que permita solo el URI. Esto impide que la solicitud con el URI_PATH permitido se evalúe con respecto a todas las demás reglas definidas en la ACL web.

Información relacionada

Conceptos básicos de declaración de reglas

Declaración de reglas de ataque de scripting entre sitios

Declaración de reglas de ataque por inyección de código SQL

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 8 meses