Compartir vía

Ajustar Azure Web Application Firewall para Azure Front Door

  • Artículo

El conjunto de reglas predeterminado administrado por Microsoft se basa en el conjunto de reglas principales de OWASP e incluye las reglas de recopilación de inteligencia sobre amenazas de Microsoft.

Es posible que las reglas del firewall de aplicaciones web (WAF) deban ajustarse para satisfacer las necesidades específicas de la aplicación u organización que utiliza el WAF. Las organizaciones suelen lograr los ajustes mediante una de las siguientes acciones:

  • Definir las exclusiones de las reglas.
  • Crear reglas personalizadas.
  • Deshabilitar las reglas que podrían estar causando problemas o falsos positivos.

En este artículo se describe lo que puede hacer si se bloquean las solicitudes que deben pasar a través del WAF.

Nota:

El conjunto de reglas administrado por Microsoft no está disponible para la SKU estándar de Azure Front Door. Para obtener más información sobre las diferentes SKU de nivel, consulte Comparación de características entre niveles.

Lea la información general del firewall de aplicaciones web de Azure Front Door y los documentos de la directiva de WAF para Front Door. Además, habilite la Supervisión y registro de WAF. En estos artículos se explica cómo funcionan el firewall de aplicaciones web y los conjuntos de reglas de WAF, y cómo acceder a los registros del firewall de aplicaciones web.

Descripción de los registros de WAF

El propósito de los registros de WAF es mostrar todas las solicitudes que coinciden con el firewall de aplicaciones web o que ha bloqueado. Es una recopilación de todas las solicitudes evaluadas que coinciden o se han bloqueado. Si observa que el firewall de aplicaciones web bloquea una solicitud que no debería (un falso positivo), puede hacer algunas cosas.

En primer lugar, restrinja y busque la solicitud específica. Puede configurar un mensaje de respuesta personalizado para incluir el campo trackingReference a fin de identificar fácilmente el evento y realizar una consulta de registro sobre ese valor específico. Examine los registros para buscar el URI, la marca de tiempo o la IP de cliente específicos de la solicitud. Cuando encuentre las entradas del registro relacionadas, puede actuar sobre los falsos positivos.

Por ejemplo, imagine que tiene un tráfico legítimo que contiene la cadena 1=1 que quiere pasar a través del WAF. La solicitud tendrá una apariencia similar a la siguiente:

POST http://afdwafdemosite.azurefd.net/api/Feedbacks HTTP/1.1
Host: afdwafdemosite.azurefd.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

UserId=20&captchaId=7&captchaId=15&comment="1=1"&rating=3

Si intenta realizar la solicitud, el firewall de aplicaciones web bloquea el tráfico que contenga la cadena 1=1 en cualquier campo o parámetro. Esta cadena se suele asociar a un ataque por inyección de código SQL. Puede examinar los registros y ver la marca de tiempo de la solicitud y las reglas que se han bloqueado o que coinciden.

En el ejemplo siguiente se muestra una entrada de registro que se generó en función de una coincidencia de regla. Puede usar la siguiente consulta de Log Analytics para buscar las solicitudes que se han bloqueado en las últimas 24 horas.

AzureDiagnostics
| where Category == 'FrontDoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

AzureDiagnostics
| where Category == 'FrontdoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

En el campo requestUri, puede ver que la solicitud se realizó específicamente para /api/Feedbacks/. Si avanzamos un poco más, encontraremos el identificador de regla 942110 en el campo ruleName. Si conoce el identificador de regla, podría ir al repositorio oficial del conjunto de reglas de núcleo ModSecurity de OWASP y buscar por ese identificador de regla para revisar su código y saber exactamente en qué coincide esta regla.

A continuación, comprobando el campo action, puede ver que esta regla está establecida para bloquear las solicitudes tras la coincidencia. Puede confirmar que el WAF bloqueó la solicitud porque policyMode está establecido en prevention.

Comprobemos ahora la información en el campo details. En este campo puede ver la información de matchVariableName y matchVariableValue. Esta regla se desencadenó porque alguien escribió 1=1 en el campo comment de la aplicación web.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

También hay cierto valor en comprobar los registros de acceso para expandir su conocimiento sobre un evento WAF determinado. A continuación, revisamos el registro que se generó como respuesta al evento anterior.

Puede ver estos registros y sus relativos porque el valor trackingReference es el mismo. Entre los diversos campos que proporcionan información general, como userAgent y clientIP, fíjese en los campos httpStatusCode y httpStatusDetails. Aquí, puede ver que el cliente recibió una respuesta HTTP 403 que confirma que esta solicitud se denegó y se bloqueó.

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorAccessLog",
    "operationName": "Microsoft.Cdn/Profiles/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorAccessLog",
    "operationName": "Microsoft.Network/FrontDoor/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

Resolución de falsos positivos

Para tomar una decisión informada ante un falso positivo, es importante familiarizarse con las tecnologías que usa la aplicación. Por ejemplo, imagine que en la pila de tecnología no hay un servidor SQL y que recibe falsos positivos relacionados con esas reglas. La deshabilitación de esas reglas no debilita necesariamente la seguridad.

Con esta información y sabiendo que la regla 942110 es la que coincide con la cadena 1=1 en el ejemplo, puede hacer algunas cosas para evitar que se bloquee esta solicitud legítima:

Sugerencia

Cuando seleccione un enfoque para permitir solicitudes legítimas a través de WAF, trate de acotarlo tanto como pueda. Por ejemplo, es mejor usar una lista de exclusión que deshabilitar una regla por completo.

Uso de listas de exclusión

Una ventaja de usar una lista de exclusión es que solo la variable de coincidencia que seleccione para excluir ya no se inspeccionará para esa solicitud determinada. Es decir, puede elegir entre encabezados de solicitud, cookies de solicitud, argumentos de cadena de consulta o argumentos de publicación del cuerpo de la solicitud específicos que se van a excluir si se cumple una condición determinada, en lugar de evitar la inspección de toda la solicitud. Las demás variables no especificadas de la solicitud se inspeccionan con normalidad.

Las exclusiones son una configuración global. La exclusión configurada se aplica a todo el tráfico que pase a través de WAF, no solo a una aplicación web o un URI específicos. Por ejemplo, esto podría ser un problema si 1=1 es una solicitud válida en el cuerpo de una aplicación web concreta, pero no para otras en la misma directiva de WAF.

Si tiene sentido usar diferentes listas de exclusión para diversas aplicaciones, considere la posibilidad de usar distintas directivas de WAF para cada aplicación y aplicarlas al front-end de cada aplicación.

Al configurar listas de exclusión para las reglas administradas, puede optar por excluir:

  • Todas las reglas de un conjunto de reglas.
  • Todas las reglas de un grupo de reglas.
  • Una regla individual.

Puede configurar una lista de exclusión mediante PowerShell, la CLI de Azure, la API de REST, Bicep, las plantillas de ARM o Azure Portal.

  • Exclusiones en un nivel de regla: La aplicación de exclusiones en un nivel de regla significa que las exclusiones especificadas no se analizarán solo en esa regla individual. Seguirá siendo analizado por todas las demás reglas del conjunto de reglas. Este es el nivel más granular para las exclusiones. Puede usarlo para ajustar bien el conjunto de reglas administrado basado en la información encontrada en los registros de WAF cuando solucione los problemas de un evento.
  • Exclusiones en un nivel de grupo de reglas:La aplicación de exclusiones en un nivel de grupo de reglas significa que las exclusiones especificadas no se analizarán en ese conjunto específico de tipos de regla. Por ejemplo, seleccionar SQLI como un grupo de reglas excluido indica que ninguna de las reglas específicas de SQLI inspeccionaría las exclusiones de solicitudes definidas. Serían siendo inspeccionadas por las reglas de otros grupos, como PHP, RFI o XSS. Este tipo de exclusión puede ser útil cuando esté seguro de que la aplicación no es susceptible a tipos de ataques específicos. Por ejemplo, una aplicación que no tiene ninguna base de datos SQL podría tener todas las reglas SQLI excluidas sin que esto sea perjudicial para su nivel de seguridad.
  • Exclusiones en un nivel de conjunto de reglas:La aplicación de exclusiones en un nivel de conjunto de reglas significa que las exclusiones especificadas no se analizarán en ninguna de las reglas de seguridad disponibles en ese conjunto de reglas. Esta exclusión es completa, así que tenga cuidado.

En este ejemplo, hace una exclusión en el nivel más granular aplicando una exclusión a una sola regla. Desea excluir la variable de coincidencia Nombre de los argumentos de publicación del cuerpo de la solicitud que contiene comment. Puede ver los detalles de la variable de coincidencia en el registro del firewall: "matchVariableName": "PostParamValue:comment". El atributo es comment. También puede encontrar este nombre de atributo de otras formas. Para saber más, consulte Búsqueda de nombres de atributo de solicitud.

Captura de pantalla que muestran las reglas de exclusión.

Captura de pantalla que muestran las reglas de exclusión para una regla específica.

En ocasiones, hay casos en los que parámetros específicos se pasan al firewall de aplicaciones web de una forma que puede no ser intuitiva. Por ejemplo, se pasa un token cuando se autentica mediante Microsoft Entra ID. El token __RequestVerificationToken normalmente se pasa como una cookie de solicitud.

En algunos casos en los que las cookies están deshabilitadas, este token también se pasa como un argumento de publicación del cuerpo de la solicitud. Por este motivo, para solucionar los falsos positivos del token de Microsoft Entra, debe asegurarse de que __RequestVerificationToken se agregue a la lista de exclusión para RequestCookieNames y RequestBodyPostArgsNames.

Las exclusiones en un nombre de campo (Selector) significan que WAF dejará de evaluar el valor. El propio nombre de campo sigue evaluándose y, en raras ocasiones, puede coincidir con una regla de WAF y desencadenar una acción.

Captura de pantalla que muestran las reglas de exclusión para un conjunto de reglas.

Cambio de acciones de WAF

Otra manera de controlar el comportamiento de las reglas de WAF es elegir la acción que hace falta cuando una solicitud coincida con las condiciones de una regla. Las acciones disponibles son: Permitir, bloquear, registrar y redirigir.

En este ejemplo, la acción predeterminada Block cambia a la acción Log en la regla 942110. Esto hace que WAF registre la solicitud y siga evaluando la misma solicitud con respecto a las reglas de prioridad inferior restantes.

Captura de pantalla que muestra las acciones de WAF.

Tras hacer la misma solicitud, puede volver a los registros y ver si la solicitud coincide con el ID de la regla 942110. El campo action_s ahora indica Registro en lugar de Bloquear. A continuación, la consulta de registro se amplía para incluir la información de trackingReference_s y ver qué más ha ocurrido con esta solicitud.

Captura de pantalla que muestra un registro en el que coinciden múltiples reglas.

Puede ver que una coincidencia de regla SQLI se produce milisegundos después de que se procesara el identificador de la regla 942110. La misma solicitud coincidía en el identificador de regla 942310 y esta vez se desencadenó la acción predeterminada Block.

Otra ventaja de usar la acción Log durante el ajuste o la solución de problemas de WAF es que puede identificar si varias reglas de un grupo de reglas específico coinciden con una solicitud determinada y la bloquean. Después, puede crear las exclusiones en el nivel adecuado, es decir, en el nivel de regla o grupo de reglas.

Uso de reglas personalizadas

Una vez que haya identificado lo que causa una coincidencia de regla de WAF, podrá usar reglas personalizadas para ajustar cómo responde WAF al evento. Las reglas personalizadas se procesan antes que las reglas administradas. Pueden contener más de una condición y sus acciones pueden ser Permitir, rechazar, registrar o redirigir.

Advertencia

Cuando una solicitud coincide con una regla personalizada, el motor de WAF deja de procesar la solicitud. Las reglas administradas no se procesarán para esta solicitud ni ninguna otra regla personalizada con una prioridad más baja.

El ejemplo siguiente muestra una regla personalizada con dos condiciones. La primera condición busca el valor comment en el cuerpo de la solicitud. La segunda condición busca el valor /api/Feedbacks/ en el URI de la solicitud.

Al usar una regla personalizada, puede ser la más granular para que pueda ajustar las reglas de WAF y tratar con falsos positivos. En este caso, no actúa solo en función del valor del cuerpo de la solicitud comment, que podría existir en varios sitios o aplicaciones en la misma directiva de WAF.

Al incluir otra condición para que coincida también en un URI de solicitud determinado /api/Feedbacks/, garantiza que esta regla personalizada se aplica realmente a este caso de uso explícito que investiga. Esto garantiza que el motor de WAF aún pueda inspeccionar y evitar el mismo ataque si se realiza en diferentes condiciones.

Captura de pantalla que muestra un registro.

Al explorar el registro, puede ver que el campo ruleName_s contiene el nombre asignado a la regla personalizada redirectcomment. En el campo action_s, puede ver que se realizó la acción Redirect para este evento. En el campo details_matches_s, puede ver los detalles de la coincidencia de ambas condiciones.

Deshabilitar reglas

Otra forma de sortear un falso positivo consiste en deshabilitar la regla que coincide con la entrada que el firewall de aplicaciones web ha considerado malintencionada. Como ha analizado los registros de WAF y ha restringido la regla a 942110, puede deshabilitarla en Azure Portal. Para más información, consulte Personalización de las reglas de Azure Web Application Firewall mediante Azure Portal.

Deshabilitar una regla es una ventaja cuando está seguro de que todas las solicitudes que cumplen esa condición específica son solicitudes legítimas, o cuando está seguro de que la regla no se aplica a su entorno (por ejemplo, deshabilitar una regla de inyección de código SQL porque tiene back-ends que no son de SQL).

Deshabilitar una regla es una configuración global que se aplica a todos los hosts de front-end asociados a la directiva de WAF. Al elegir deshabilitar una regla, es posible que deje las vulnerabilidades expuestas sin protección ni detección para cualquier otro host de front-end asociado a la directiva de WAF.

Si desea usar Azure PowerShell para deshabilitar una regla administrada, consulte la documentación del objeto PSAzureManagedRuleOverride. Si desea usar la CLI de Azure, consulte la documentación az network front-door waf-policy managed-rules override.

Captura de pantalla que muestra las reglas de WAF.

Sugerencia

Documente los cambios que realice en la directiva de WAF. Incluya solicitudes de ejemplo para ilustrar la detección de falsos positivos. Explique por qué agregó una regla personalizada, deshabilitó una regla o un conjunto de reglas o agregó una excepción. Si rediseña la aplicación en el futuro, puede que sea necesario comprobar que los cambios siguen siendo válidos. O puede que sea necesario justificar por qué ha reconfigurado la directiva de WAF desde su configuración predeterminada.

Buscar campos de solicitud

Al usar un proxy de explorador como Fiddler, puede inspeccionar solicitudes individuales y determinar a qué campos específicos de una página web se llama. Esta técnica es útil cuando debe excluir determinados campos de la inspección mediante listas de exclusión en el WAF.

Búsque nombres de atributo de solicitud

En este ejemplo, el campo donde se ha escrito la cadena 1=1 se denomina comment. Estos datos se pasaron en el cuerpo de una solicitud POST.

Captura de pantalla que muestra el cuerpo de una solicitud Fiddler.

Puede excluir este campo. Para saber más sobre las lista de exclusión, consulte Listas de exclusión del firewall de aplicaciones web. En este caso puede excluir la evaluación mediante la configuración de la exclusión siguiente:

Captura de pantalla que muestran una regla de exclusión.

También puede examinar los registros del firewall para obtener la información y ver lo que tiene que agregar a la lista de exclusión. Para habilitar el registro, consulte Supervisión de métricas y registros en Azure Front Door.

Examine el registro del firewall en el archivo PT1H.json para la hora a la que se haya producido la solicitud que quiere inspeccionar. Los archivos PT1H.json están disponibles en los contenedores de cuenta de almacenamiento donde se almacenan los registros de diagnóstico FrontDoorWebApplicationFirewallLog y FrontDoorAccessLog.

Examine el registro del firewall en el archivo PT1H.json para la hora a la que se haya producido la solicitud que quiere inspeccionar. Los archivos PT1H.json están disponibles en los contenedores de cuenta de almacenamiento donde se almacenan los registros de diagnóstico FrontdoorWebApplicationFirewallLog y FrontdoorAccessLog.

En este ejemplo, puede ver la regla que bloqueó la solicitud (con la misma referencia de transacción) y que se produjo al mismo tiempo.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Con su conocimiento del funcionamiento de los conjuntos de reglas administrados por Azure, sabe que la regla con la propiedad action: Block se bloquea en función de los datos coincidentes en el cuerpo de la solicitud. (Para saber más, consulte Azure Web Application Firewall en Azure Front Door). Puede ver en los detalles que coinciden con un patrón (1=1) y el campo se denomina comment. Siga los mismos pasos anteriores para excluir el nombre de los argumentos de publicación del cuerpo de la solicitud comment.

Busque nombres de encabezados de solicitud

Fiddler es una herramienta útil para buscar nombres de encabezado de solicitud. En la captura de pantalla siguiente se muestran los encabezados de esta solicitud GET, que incluyen Content-Type y User-Agent. También puede usar encabezados de solicitud para crear exclusiones y reglas personalizadas en WAF.

Captura de pantalla que muestra el encabezado de una solicitud Fiddler.

Otra manera de ver los encabezados de solicitud y respuesta consiste en buscar dentro de las herramientas de desarrollo del explorador, como Microsoft Edge o Chrome. Puede seleccionar F12 o hacer clic con el botón derecho en Inspeccionar>herramientas de desarrollo. Seleccione la pestaña Red. Cargue una página web y seleccione la solicitud que desea inspeccionar.

Captura de pantalla que muestra una solicitud de inspeccion de red.

Si la solicitud contiene cookies,seleccione la pestaña Cookies para verlas en Fiddler. La información de las cookies también se puede usar para crear exclusiones o reglas personalizadas en WAF.

Regla de puntuación de anomalías

Si ve el identificador de regla 949110 durante el proceso de ajuste de WAF, su presencia indica que el proceso de puntuación de anomalías bloqueó la solicitud.

Revise las demás entradas de registro de WAF que tengan la misma solicitud; para ello, busque las entradas de registro con la misma referencia de seguimiento. Examine cada una de las reglas que se desencadenaron. Ajuste cada regla siguiendo las instrucciones de este artículo.

Advertencia

Al asignar un nuevo conjunto de reglas administrado a una directiva WAF, todas las personalizaciones anteriores de los conjuntos de reglas administrados existentes, como el estado de regla, las acciones de regla y las exclusiones de nivel de regla se restablecerán a los nuevos valores predeterminados del conjunto de reglas administrados. Sin embargo, las reglas personalizadas y la configuración de directiva no se verán afectadas durante la nueva asignación del conjunto de reglas.

Pasos siguientes