Compartilhar via

Ajustar o Firewall de Aplicativo Web para o Azure Front Door

  • Artigo

O conjunto de regras padrão gerenciado pela Microsoft é baseado no Conjunto de Regras Principal do OWASP e inclui regras de Coleta de Inteligência contra Ameaças da Microsoft.

Geralmente, espera-se que as regras do firewall do aplicativo Web (WAF) precisem ser ajustadas para atender às necessidades específicas do aplicativo ou da organização que o use. As organizações geralmente alcançam o ajuste tomando uma das seguintes ações:

  • Definindo exclusões de regra.
  • Criando regras personalizadas.
  • Desabilitando regras que podem estar causando problemas ou falsos positivos.

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

Observação

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

Primeiro, verifique se você leu os documentos Visão geral do WAF do Front Door e Política do WAF para documentos do Front Door. Também habilite o Monitoramento e registro em log do Azure WAF. Estes artigos explicam como o WAF funciona, como a regra do WAF define o trabalho e como acessar logs do WAF.

Entenda os logs do WAF

A finalidade dos logs do WAF é mostrar todas as solicitações que tenham correspondência ou sejam bloqueadas por ele. Trata-se de uma coleção de todas as solicitações avaliadas que tenham correspondência ou sejam bloqueadas. Caso note que o WAF bloqueia uma solicitação que não deveria (um falso positivo), tem algumas coisas que você pode fazer.

Primeiro, restrinja e localize a solicitação específica. Você pode configurar uma mensagem de resposta personalizada para incluir o campo trackingReference para identificar facilmente o evento e executar uma consulta de log nesse valor específico. Analise os logs para localizar o URI específico, o carimbo de data/hora ou o IP do cliente da solicitação. Ao encontrar as entradas de log relacionadas, você pode tratar dos falsos positivos.

Por exemplo, digamos que você tenha um tráfego legítimo que contém a cadeia de caracteres 1=1 que você deseja que passe pelo WAF. Esta é a aparência da 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ê testar a solicitação, o WAF bloqueará o tráfego que contém a cadeia de caracteres 1=1 em qualquer parâmetro ou campo. Essa cadeia de caracteres é frequentemente associada a um ataque de injeção de SQL. É possível analisar os logs e ver o carimbo de data/hora da solicitação, além das regras que foram bloqueadas ou correspondidas.

O exemplo a seguir mostra uma entrada de log que foi gerada com base em uma correspondência de regra. Você pode usar a consulta do Log Analytics a seguir 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 requestUri, você pode ver que a solicitação foi feita especificamente para /api/Feedbacks/. Seguindo adiante, encontramos a ID da regra 942110 no campo ruleName. Conhecendo a ID da regra, você poderia ir para o Repositório oficial do Conjunto de regras principais do ModSecurity do OWASP e pesquisar por essa ID de regra para examinar seu código e entender exatamente ao que essa regra corresponde.

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

Agora, verifique as informações no campo details. É aqui que você pode ver as informações de matchVariableName e matchVariableValue. Essa regra foi acionada porque alguém inseriu 1=1 no campo comment 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á um valor na verificação dos logs de acesso para expandir seu conhecimento sobre um determinado evento do WAF. A seguir, examine o log que foi gerado como uma resposta ao evento acima.

Você pode ver que esses logs estão relacionados porque o valor trackingReference é o mesmo. Entre vários campos que fornecem informações gerais, como userAgent e clientIP, preste atenção nos campos httpStatusCode e httpStatusDetails. Aqui você pode ver que o cliente recebeu uma resposta HTTP 403. Isso 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 embasada sobre a manipulação de um falso positivo, é importante se familiarizar com as tecnologias usadas pelo aplicativo. Por exemplo, digamos que não haja um SQL Server em sua pilha de tecnologia e que você esteja obtendo falsos positivos relacionados a essas regras. Desabilitar essas regras não necessariamente reduz a segurança.

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

Dica

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

Usar listas de exclusões

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

As exclusões são uma configuração global. A exclusão configurada é aplicada a todo o tráfego que passar 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 de um determinado aplicativo Web, mas não em outros sob a mesma política do WAF.

Se fizer sentido usar diferentes listas de exclusão para aplicativos diferentes, cogite usar políticas do 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 de Resource Manager do Azure 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 somente em relação a essa regra individual. Elas ainda serão analisada por todas as outras regras no conjunto de regras. Esse é o nível mais granular para exclusões. Você pode usá-lo para ajustar o conjunto de regras gerenciado com base nas informações encontradas nos logs do WAF ao solucionar um evento.
  • Exclusões em um nível de regra de grupo: A aplicação de 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ídas indica que as exclusões de solicitação definidas não seriam 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 interessante quando você tiver 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 poderia ter todas as regras SQLI excluídas sem que isso prejudique seu nível de segurança.
  • Exclusões em um nível de conjunto de regras: A aplicação de exclusões em um nível de conjunto de regras significa que as exclusões especificadas não serão analisadas com base em nenhuma das regras de segurança disponíveis nesse conjunto de regras. Essa exclusão é abrangente, portanto use-a com cuidado.

Nesse exemplo, você executa uma exclusão no nível mais granular aplicando a exclusão a uma única regra. Você deseja excluir a variável de correspondência Corpo da solicitação 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 outras maneiras. Para obter mais informações, consulte Localizar nomes de atributo de solicitação.

Captura de tela que mostra a exclusão de regras.

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

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

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

As exclusões em um nome de campo (Seletor) significa que o valor não será mais avaliado pelo WAF. O próprio nome do campo continua sendo avaliado e, em casos raros, pode corresponder a uma regra do WAF e ativar 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 é tomada 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, o Bloco da ação padrão foi alterado para a ação de Registrar 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 mais baixa restantes.

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

Depois de executar a mesma solicitação, você pode consultar os logs e ver se a solicitação correspondia à regra 942110. O campo action_s agora indica Log em vez de Bloquear. A consulta de log foi extendida para incluir as informações de trackingReference_s e ver o que mais aconteceu com essa solicitação.

Captura de tela que mostra um log mostrando várias correspondências de regra.

Agora você pode ver que uma correspondência de regra de SQLI diferente ocorre milissegundos após a ID de regra 942110 ter sido processada. A mesma solicitação correspondeu à ID de regra 942310 e, dessa vez, a ação padrão Bloquear que foi ativada.

Outra vantagem de usar a ação de Registrar durante o ajuste ou a solução de problemas do WAF é que você pode identificar se várias regras dentro de um grupo de regras específico estão tendo correspondência 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. Elas 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 nem outras regras personalizadas com prioridade mais baixa.

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

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

Quando você inclui outra condição para corresponder também a um URI de solicitação específico /api/Feedbacks/, garantimos que essa regra personalizada realmente se aplique a esse caso de uso explícito que analisamos. Dessa forma o mesmo ataque, se executado em condições diferentes, ainda é inspecionado e impedido pelo mecanismo do WAF.

Captura de tela mostrando um log.

Ao explorar o log, você pode ver que o campo ruleName_s contém o nome fornecido para a regra personalizada redirectcomment. No campo action_s, você pode ver que a ação Redirecionar foi executada para esse evento. No campo details_matches_s, você pode ver os que detalhes de ambas as condições tiveram correspondência.

Desabilitar regras

Outra forma de contornar um falso positivo é desabilitar a regra que teve correspondência na entrada que o WAF pensou ser mal-intencionada. Como os logs do WAF foram analisados e a regra foi restringida para 942110, é possível desabilitá-la no portal do Azure. Para obter mais informações, consulte Personalizar regras de Firewall de Aplicativo Web do Azure usando o portal do Azure.

Desabilitar uma regra é benéfico quando você tem certeza de que todas as solicitações que atendem a essa condição específica são legítimas ou quando você 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).

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

Caso queira usar o Azure PowerShell para desabilitar uma regra gerenciada, confira a documentação do objeto PSAzureManagedRuleOverride. Caso queira usar CLI do Azure, confira a documentação az network front-door waf-policy managed-rules override.

Captura de tela que mostra as regras do WAF.

Dica

Documente quaisquer alterações feitas na política do WAF. Inclua solicitações de exemplo para ilustrar a detecção de falsos positivos. Explique por que você adicionou uma regra personalizada, desabilitou uma regra ou conjunto de regras ou adicionou uma exceção. Se você reprojetar seu aplicativo no futuro, pode precisar verificar se suas alterações ainda são válidas. Você também pode ser auditado ou pode precisar justificar por que você reconfigurou a política do WAF de suas configurações padrão.

Localizar campos de solicitação

Ao usar 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ões no WAF.

Localizar nomes de atributo de solicitação

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

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

Você pode excluir esse campo. Para saber mais sobre listas de exclusões, confira Listas de exclusões do Firewall do Aplicativo Web. É possível excluir a avaliação nesse caso configurando a seguinte exclusão:

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

Também é possível examinar os logs do firewall para obter as informações e ver o que precisa ser adicionado à lista de exclusões. Para habilitar o registro em log, confira Monitorar métricas e logs no Azure Front Door.

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

Examine o log do firewall no arquivo PT1H.json a respeito da hora em que a solicitação que você deseja inspecionar ocorreu. Os arquivos PT1H.json estão disponíveis nos contêineres da conta de armazenamento em que os logs de diagnóstico FrontdoorWebApplicationFirewallLog e FrontdoorAccessLog estão 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 o seu conhecimento sobre como os conjuntos de regras gerenciadas pelo Azure funcionam, você sabe que a regra com a propriedade action: Block está bloqueando com base nos dados correspondidos no corpo da solicitação. (Para obter mais informações, consulte Firewall de Aplicativo Web do Azure no Azure Front Door.) 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 dos argumentos de postagem do corpo da solicitação que contém comment.

Nomes do cabeçalho da solicitação

O Fiddler também é uma ferramenta útil para localizar nomes de cabeçalho de solicitação. 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 Fiddler.

Outra maneira de exibir cabeçalhos de solicitação e de resposta é examinando as 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 do Desenvolvedor. Selecione a guia Rede. Carregue uma página da Web e selecione a solicitação que você deseja inspecionar.

Captura de tela que mostra a Solicitação do inspetor de rede.

Se a solicitação contiver cookies, selecione a guia Cookies para exibi-los no Fiddler. As informações dos cookies também podem ser usadas para criar exclusões ou regras personalizadas no WAF.

Modo de pontuação de anomalias

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

Examine as outras entradas de log do WAF para a mesma solicitação, pesquisando as entradas de log com a mesma referência de acompanhamento. Examine cada uma das regras que foram disparadas. Ajuste cada regra seguindo as diretrizes neste artigo.

Aviso

Ao atribuir um novo conjunto de regras gerenciado a uma política de WAF, todas as personalizações anteriores dos conjuntos de regras gerenciados existentes, como estado de 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 configurações de política e regras personalizadas permanecerão inalteradas durante a atribuição do novo conjunto de regras.

Próximas etapas