Partilhar via

Ajustar o Firewall de Aplicativo Web do Azure para o Azure Front Door

  • Artigo

O conjunto de regras padrão gerenciado pela Microsoft é baseado no Conjunto de Regras Principais do OWASP e inclui regras de coleta do Microsoft Threat Intelligence.

Muitas vezes, espera-se que as regras do WAF (Web Application Firewall) sejam ajustadas para atender às necessidades específicas do aplicativo ou da organização que está usando o WAF. As organizações geralmente alcançam o ajuste tomando uma das seguintes ações:

  • Definição de exclusões de regras.
  • Criação de regras personalizadas.
  • Desativar regras que possam estar a causar problemas ou falsos positivos.

Este artigo descreve o que você pode fazer se as solicitações que deveriam passar pelo WAF forem bloqueadas.

Nota

O conjunto de regras gerenciado pela Microsoft não está disponível para a SKU do Azure Front Door Standard. Para obter mais informações sobre as diferentes SKUs de camadas, consulte Comparação de recursos entre camadas.

Leia a visão geral do WAF do Azure Front Door e a Política do WAF para documentos do Azure Front Door. Além disso, habilite o monitoramento e o registro em log do WAF. Estes artigos explicam como o WAF funciona, como os conjuntos de regras do WAF funcionam e como acessar logs do WAF.

Compreender os logs WAF

O objetivo dos logs do WAF é mostrar todas as solicitações correspondentes ou bloqueadas pelo WAF. É uma coleção de todas as solicitações avaliadas que são correspondidas ou bloqueadas. Se você notar que o WAF bloqueia uma solicitação que não deveria (um falso positivo), você pode fazer algumas coisas.

Primeiro, restrinja e encontre o pedido específico. Você pode configurar uma mensagem de resposta personalizada para incluir o trackingReference campo para identificar facilmente o evento e executar uma consulta de log nesse valor específico. Examine os logs para encontrar o URI, carimbo de data/hora ou IP do cliente específico da solicitação. Quando você encontrar as entradas de log relacionadas, você pode agir em falsos positivos.

Por exemplo, digamos que você tenha tráfego legítimo que contenha a cadeia de caracteres 1=1 que você deseja passar pelo WAF. Veja como é a solicitação:

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

Se você tentar a solicitação, o WAF bloqueará o tráfego que contém sua 1=1 cadeia de caracteres em qualquer parâmetro ou campo. Essa cadeia de caracteres é frequentemente associada a um ataque de injeção de SQL. Você pode examinar os logs e ver o carimbo de data/hora da solicitação e as regras que bloquearam ou corresponderam.

O exemplo a seguir mostra uma entrada de log que foi gerada com base em uma correspondência de regra. Você pode usar a seguinte consulta do Log Analytics para localizar solicitações que foram bloqueadas nas ú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'

No campo, você pode ver que o requestUri pedido foi feito para /api/Feedbacks/ especificamente. Indo mais longe, encontre o ID 942110 da ruleName regra no campo. Conhecendo o ID da regra, você pode ir ao repositório oficial do OWASP ModSecurity Core Rule set e pesquisar por esse ID de regra para revisar seu código e entender exatamente em que essa regra corresponde.

Em seguida, verificando o campo, você pode ver que essa regra está definida para bloquear solicitações após a action correspondência. Você pode confirmar que a solicitação foi bloqueada pelo WAF porque o policyMode está definido como prevention.

Agora, confira as informações em details campo. Este campo é onde você pode ver o matchVariableName e as matchVariableValue informações. Essa regra foi acionada comment porque alguém entrou 1=1 no campo do aplicativo 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\""
        }
    }
}

Também há valor em verificar os logs de acesso para expandir seu conhecimento sobre um determinado evento WAF. Em seguida, revise o log que foi gerado como resposta ao evento anterior.

Você pode ver que esses logs estão relacionados porque o trackingReference valor é o mesmo. Entre vários campos que fornecem uma visão geral, como userAgent e clientIP, observe os httpStatusCode e httpStatusDetails campos. Aqui, você pode ver que o cliente recebeu uma resposta HTTP 403, que confirma que essa solicitação foi negada e bloqueada.

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

Resolver falsos positivos

Para tomar uma decisão informada sobre como lidar com um falso positivo, é importante se familiarizar com as tecnologias que seu aplicativo usa. Por exemplo, digamos que não há um servidor SQL em sua pilha de tecnologia e você está recebendo falsos positivos relacionados a essas regras. Desativar essas regras não enfraquece necessariamente a sua segurança.

Com essas informações, e sabendo que a regra 942110 é a que correspondeu à 1=1 cadeia de caracteres no exemplo, você pode fazer algumas coisas para impedir que essa solicitação legítima seja bloqueada:

Gorjeta

Ao selecionar uma abordagem para permitir solicitações legítimas por meio do WAF, tente torná-la o mais restrita possível. Por exemplo, é melhor usar uma lista de exclusão do que desativar totalmente uma regra.

Usar listas de exclusão

Um benefício de usar uma lista de exclusão é que apenas a variável de correspondência selecionada para excluir não será mais inspecionada para determinada solicitação. Ou seja, você pode escolher entre cabeçalhos de solicitação específicos, cookies de solicitação, argumentos de cadeia de caracteres de consulta ou argumentos de postagem de corpo de solicitação para serem excluídos se uma determinada condição for atendida, em vez de excluir toda a solicitação de ser inspecionada. As demais variáveis não especificadas da solicitação são inspecionadas normalmente.

As exclusões são um cenário global. A exclusão configurada aplica-se a todo o tráfego que passa pelo WAF, não apenas a um aplicativo Web ou URI específico. Por exemplo, isso pode ser uma preocupação se 1=1 for uma solicitação válida no corpo para um determinado aplicativo Web, mas não para outros sob a mesma política WAF.

Se fizer sentido usar listas de exclusão diferentes para aplicativos diferentes, considere usar políticas WAF diferentes para cada aplicativo e aplicá-las ao front-end de cada aplicativo.

Ao configurar listas de exclusão para regras gerenciadas, você pode optar por excluir:

  • Todas as regras dentro de um conjunto de regras.
  • Todas as regras dentro de um grupo de regras.
  • Uma regra individual.

Você pode configurar uma lista de exclusão usando o PowerShell, a CLI do Azure, a API REST, o Bicep, os modelos do Azure Resource Manager ou o portal do Azure.

  • Exclusões em um nível de regra: aplicar exclusões em um nível de regra significa que as exclusões especificadas não serão analisadas apenas em relação a essa regra individual. Ele ainda será analisado por todas as outras regras do conjunto de regras. Este é o nível mais granular para exclusões. Você pode usá-lo para ajustar o conjunto de regras gerenciadas com base nas informações encontradas nos logs do WAF ao solucionar problemas de um evento.
  • Exclusões em um nível de grupo de regras: aplicar exclusões em um nível de grupo de regras significa que as exclusões especificadas não serão analisadas em relação a esse conjunto específico de tipos de regras. Por exemplo, selecionar SQLI como um grupo de regras excluído indica que as exclusões de solicitação definidas não serão inspecionadas por nenhuma das regras específicas do SQLI. Ele ainda será inspecionado por regras em outros grupos, como PHP, RFI ou XSS. Esse tipo de exclusão pode ser útil quando você tem certeza de que o aplicativo não é suscetível a tipos específicos de ataques. Por exemplo, um aplicativo que não tem nenhum banco de dados SQL pode ter todas as regras SQLI excluídas sem que isso seja prejudicial ao seu nível de segurança.
  • Exclusões em um nível de conjunto de regras: aplicar exclusões em um nível de conjunto de regras significa que as exclusões especificadas não serão analisadas em relação a nenhuma das regras de segurança disponíveis nesse conjunto de regras. Esta exclusão é abrangente, por isso use-a com cuidado.

Neste exemplo, você executa uma exclusão no nível mais granular aplicando uma exclusão a uma única regra. Você deseja excluir a variável de correspondência Request body post args name que contém comment. Você pode ver os detalhes da variável de correspondência no log do firewall: "matchVariableName": "PostParamValue:comment". O atributo é comment. Você também pode encontrar esse nome de atributo de algumas outras maneiras. Para obter mais informações, consulte Localizar nomes de atributos de solicitação.

Captura de ecrã que mostra as regras de exclusão.

Captura de tela que mostra a exclusão de regra para uma regra específica.

Ocasionalmente, há casos em que parâmetros específicos são passados para o WAF de uma maneira que pode não ser intuitiva. Por exemplo, um token é passado quando você se autentica usando o Microsoft Entra ID. O token __RequestVerificationToken geralmente é passado como um cookie de solicitação.

Em alguns casos em que os cookies estão desativados, esse token também é passado como um argumento de postagem de solicitação. Por esse motivo, para lidar com falsos positivos do token Microsoft Entra, você deve garantir que __RequestVerificationToken seja adicionado à lista de exclusão para ambos e RequestCookieNames RequestBodyPostArgsNames.

Exclusões em um nome de campo (Seletor) significa que o valor não será mais avaliado pelo WAF. O nome do campo em si continua a ser avaliado e, em casos raros, pode corresponder a uma regra WAF e desencadear uma ação.

Captura de tela que mostra a exclusão de regras para um conjunto de regras.

Alterar ações do WAF

Outra maneira de lidar com o comportamento das regras do WAF é escolhendo a ação que ele executa quando uma solicitação corresponde às condições de uma regra. As ações disponíveis são Permitir, Bloquear, Registrar e Redirecionar.

Neste exemplo, a ação padrão Bloquear foi alterada para a ação Log na regra 942110. Essa ação faz com que o WAF registre a solicitação e continue avaliando a mesma solicitação em relação às regras de prioridade inferior restantes.

Captura de tela que mostra as ações do WAF.

Depois de executar a mesma solicitação, você pode consultar novamente os logs e ver que essa solicitação era uma correspondência na ID da regra 942110. O action_s campo agora indica Log em vez de Block. A consulta de log foi então expandida para incluir as trackingReference_s informações para ver o que mais aconteceu com essa solicitação.

Captura de ecrã que mostra um registo que mostra várias correspondências de regras.

Agora você pode ver uma correspondência de regra SQLI diferente que ocorre milissegundos depois que a ID da regra 942110 foi processada. A mesma solicitação correspondeu à ID da regra 942310 e, desta vez, a ação padrão Bloquear foi acionada.

Outra vantagem de usar a ação Log durante o ajuste ou solução de problemas do WAF é que você pode identificar se várias regras dentro de um grupo de regras específico estão correspondendo e bloqueando uma determinada solicitação. Em seguida, você pode criar suas exclusões no nível apropriado, ou seja, no nível da regra ou do grupo de regras.

Usar regras personalizadas

Depois de identificar o que está causando uma correspondência de regra do WAF, você pode usar regras personalizadas para ajustar como o WAF responde ao evento. As regras personalizadas são processadas antes das regras gerenciadas. Eles podem conter mais de uma condição, e suas ações podem ser Permitir, Negar, Registrar ou Redirecionar.

Aviso

Quando uma solicitação corresponde a uma regra personalizada, o mecanismo WAF para de processar a solicitação. As regras gerenciadas não serão processadas para essa solicitação e outras regras personalizadas com prioridade menor também não.

O exemplo a seguir mostra uma regra personalizada com duas condições. A primeira condição procura o comment valor no corpo da solicitação. A segunda condição procura o /api/Feedbacks/ valor no URI da solicitação.

Usando uma regra personalizada, você pode ser o mais granular para que possa ajustar suas regras WAF e lidar com falsos positivos. Nesse caso, você não está tomando medidas apenas com base no valor do corpo da comment solicitação, que pode existir em vários sites ou aplicativos sob a mesma política WAF.

Ao incluir outra condição para também corresponder a um URI /api/Feedbacks/de solicitação específico, você garante que essa regra personalizada realmente se aplique a esse caso de uso explícito que você examinou. Desta forma, o mesmo ataque, se realizado contra condições diferentes, ainda é inspecionado e evitado pelo motor WAF.

Captura de ecrã que mostra um registo.

Ao explorar o log, você pode ver que o ruleName_s campo contém o nome dado à regra redirectcommentpersonalizada. action_s No campo, você pode ver que a ação de redirecionamento foi tomada para este evento. details_matches_s No campo, é possível ver os detalhes de ambas as condições foram combinadas.

Desativar regras

Outra maneira de contornar um falso positivo é desativar a regra que correspondia à entrada que o WAF achava maliciosa. Como você analisou os logs do WAF e reduziu a regra para 942110, pode desabilitá-la no portal do Azure. Para obter mais informações, consulte Personalizar regras do Firewall de Aplicativo Web do Azure usando o portal do Azure.

A desativação de uma regra é um benefício quando você tem certeza de que todas as solicitações que atendem a essa condição específica são solicitações legítimas ou quando tem certeza de que a regra não se aplica ao seu ambiente (como desabilitar uma regra de injeção de SQL porque você tem back-ends não SQL).

A desativação de uma regra é uma configuração global que se aplica a todos os hosts front-end associados à política WAF. Ao optar por desabilitar uma regra, você pode estar deixando vulnerabilidades expostas sem proteção ou deteção para quaisquer outros hosts front-end associados à política WAF.

Se você quiser usar o Azure PowerShell para desabilitar uma regra gerenciada, consulte a documentação do PSAzureManagedRuleOverride objeto. Se você quiser usar a CLI do Azure, consulte a az network front-door waf-policy managed-rules override documentação.

Captura de tela que mostra as regras do WAF.

Gorjeta

Documente todas as alterações feitas na sua política WAF. Inclua exemplos de solicitações para ilustrar a deteção de falsos positivos. Explique por que você adicionou uma regra personalizada, desabilitou uma regra ou um conjunto de regras ou adicionou uma exceção. Se você redesenhar seu aplicativo no futuro, talvez seja necessário verificar se as alterações ainda são válidas. Ou você pode ser auditado ou precisar justificar por que reconfigurou a política WAF a partir de suas configurações padrão.

Localizar campos de solicitação

Usando um proxy de navegador como o Fiddler, você pode inspecionar solicitações individuais e determinar quais campos específicos de uma página da Web são chamados. Essa técnica é útil quando você precisa excluir determinados campos da inspeção usando listas de exclusão no WAF.

Localizar nomes de atributos de solicitação

Neste exemplo, o campo onde a cadeia de caracteres foi inserida 1=1 é chamado comment. Esses dados foram passados no corpo de uma solicitação POST.

Captura de tela que mostra o corpo de uma solicitação do Fiddler.

Pode excluir este campo. Para saber mais sobre listas de exclusão, consulte Listas de exclusão de firewall de aplicativo Web. Neste caso, você pode excluir a avaliação configurando a seguinte exclusão:

Captura de ecrã que mostra uma regra de exclusão.

Você também pode examinar os logs do firewall para obter as informações para ver o que você precisa adicionar à lista de exclusão. Para habilitar o registro em log, consulte Monitorar métricas e logs no Azure Front Door.

Examine o PT1H.json log do firewall no arquivo para a hora em que a solicitação que você deseja inspecionar ocorreu. Os PT1H.json arquivos estão disponíveis nos contêineres da conta de armazenamento onde os logs de diagnóstico e são FrontDoorWebApplicationFirewallLog FrontDoorAccessLog armazenados.

Examine o PT1H.json log do firewall no arquivo para a hora em que a solicitação que você deseja inspecionar ocorreu. Os PT1H.json arquivos estão disponíveis nos contêineres da conta de armazenamento onde os logs de diagnóstico e são FrontdoorWebApplicationFirewallLog FrontdoorAccessLog armazenados.

Neste exemplo, você pode ver a regra que bloqueou a solicitação (com a mesma Referência de Transação) e que ocorreu ao mesmo tempo.

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

Com seu conhecimento de como os conjuntos de regras gerenciados pelo Azure funcionam, você sabe que a regra com a action: Block propriedade está sendo bloqueada com base nos dados correspondentes no corpo da solicitação. (Para obter mais informações, consulte Firewall de Aplicativo Web do Azure na Porta da Frente do Azure.) Você pode ver nos detalhes que ele correspondeu a um padrão (1=1) e o campo é chamado comment. Siga as mesmas etapas anteriores para excluir o nome do corpo da solicitação post args que contém comment.

Localizar nomes de cabeçalho de solicitação

O Fiddler é uma ferramenta útil para encontrar nomes de cabeçalhos de pedidos. A captura de tela a seguir mostra os cabeçalhos dessa solicitação GET, que incluem Content-Type e User-Agent. Você também pode usar cabeçalhos de solicitação para criar exclusões e regras personalizadas no WAF.

Captura de tela que mostra o cabeçalho de uma solicitação do Fiddler.

Outra maneira de visualizar cabeçalhos de solicitação e resposta é olhar para dentro das ferramentas de desenvolvedor do seu navegador, como o Microsoft Edge ou o Chrome. Você pode selecionar F12 ou clicar com o botão direito do mouse em Inspecionar>Ferramentas de Desenvolvedor. Carregue uma página da Web e selecione a solicitação que deseja inspecionar.

Captura de tela que mostra uma solicitação do inspetor de rede.

Se o pedido contiver cookies, selecione o separador Cookies para os visualizar no Fiddler. As informações de cookies também podem ser usadas para criar exclusões ou regras personalizadas no WAF.

Regra de pontuação de anomalias

Se você vir a regra ID 949110 durante o processo de ajuste do WAF, sua presença indica que a solicitação foi bloqueada pelo processo de pontuação de anomalia.

Analise as outras entradas de log do WAF para a mesma solicitação procurando as entradas de log com a mesma referência de rastreamento. Veja cada uma das regras que foram acionadas. Ajuste cada regra seguindo as orientações deste artigo.

Aviso

Ao atribuir um novo conjunto de regras gerenciado a uma política WAF, todas as personalizações anteriores dos conjuntos de regras gerenciados existentes, como estado da regra, ações de regra e exclusões de nível de regra, serão redefinidas para os padrões do novo conjunto de regras gerenciado. No entanto, quaisquer regras personalizadas e configurações de política permanecerão inalteradas durante a atribuição do novo conjunto de regras.

Próximos passos