Ajustar o WAF (Firewall de Aplicativo Web) para o Azure Front Door

O Conjunto de Regras Padrão gerenciado pela Microsoft é baseado no CRS (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 WAF precisem ser ajustadas para atender às necessidades específicas do aplicativo ou da organização que o use. Geralmente, isso é obtido pela definição de exclusões de regra, criação de regras personalizadas e até mesmo a desabilitação de regras que podem estar causando problemas ou falsos positivos. Tem algumas coisas que você pode fazer caso as solicitações que devam passar pelo WAF (Firewall de Aplicativo Web) estejam bloqueadas.

Observação

O Conjunto de Regras Gerenciadas 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 a Visão geral do WAF do Front Door e a Política do WAF para documentos do Front Door. Também verifique se você habilitou o monitoramento e o registro em log do WAF. Estes artigos explicam como o WAF funciona, como a regra do WAF define o trabalho e como acessar logs do WAF.

Noções básicas sobre os logs do WAF

A finalidade dos logs do WAF é mostrar todas as solicitações que tenham correspondência ou sejam bloqueadas pelo WAF. 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. Caso deseje, 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 começar a tratar dos falsos positivos.

Por exemplo, digamos que você tenha um tráfego legítimo contendo 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/correspondidas.

No exemplo a seguir, exploramos uma entrada de log gerada devido a uma correspondência de regra. A consulta do Log Analytics a seguir pode ser usada para localizar solicitações que tenham sido 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, vemos que essa regra está definida para bloquear solicitações que tiverem correspondência e confirmamos que a solicitação foi, de fato, bloqueada pelo WAF porque policyMode está definido como prevention.

Agora, vamos verificar as informações no campo details. É aqui que você pode ver as informações de matchVariableName e matchVariableValue. Aprendemos que 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. Abaixo, examinamos o log que foi gerado como uma resposta ao evento acima.

Você pode ver que esses são logs relacionados com base em o valor trackingReference ser o mesmo. Entre vários campos que fornecem informações gerais, como userAgent e clientIP, chamamos a atenção para os campos httpStatusCode e httpStatusDetails. Aqui, podemos comprovar que o cliente recebeu uma resposta HTTP 403, que confirma absolutamente 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 que seu aplicativo usa. 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. Ao desabilitar essas regras, não se reduz necessariamente 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 podemos 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 continuarão sendo inspecionadas normalmente.

É importante ter em mente que as exclusões são uma configuração global. Isso significa que a exclusão configurada será 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ões 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 ou uma regra individual. Uma lista de exclusões pode ser configurada usando o PowerShell, a CLI do Azure, a API REST ou o portal do Azure.

  • Exclusões em um nível de regra
    • A aplicação de 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, mas ainda serão analisadas por todas as outras regras no conjunto de regras. Esse é o nível mais granular para exclusões e pode ser usado 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 no nível do grupo de regras
    • 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, mas ainda seriam inspecionadas por regras em outros grupos, como PHP, RFI ou XSS. Esse tipo de exclusão pode ser interessante quando tivermos 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 no 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. Como essa é uma exclusão abrangente, deve ser usada com cuidado.

Neste exemplo, realizaremos uma exclusão no nível mais granular (aplicando a exclusão a uma única regra) e queremos excluir o nome da solicitação de variável de correspondência de Argumentos de postagem do corpo da solicitação que contém comment. Isso fica aparente porque 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 isso, confira Localizar nomes de atributo de solicitação.

Regras de exclusão

Exclusão de regra 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 durante a autenticação com o Azure Active Directory. Esse token, __RequestVerificationToken, geralmente é passado como um cookie de solicitação. Porém, 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 Azure AD, 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. No entanto, 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.

Exclusão de regra 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 será tomada quando uma solicitação corresponder às condições de uma regra. As ações disponíveis são: Permitir, Bloquear, Registrar e Redirecionar.

Neste exemplo, alteramos o Bloco da ação padrão para a ação de Registrar na regra 942110. Isso fará 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.

Ações de WAF

Depois de executar a mesma solicitação, podemos nos voltar aos logs e veremos que essa solicitação foi uma correspondência na ID de regra 942110 e que o campo action_s agora indica Registrar em vez de Bloquear. Em seguida, expandimos a consulta de log para incluir as informações de trackingReference_s e ver o que mais aconteceu com essa solicitação.

Log mostrando várias correspondências de regra

Curiosamente, vemos 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. Quando houver uma correspondência de regra, o mecanismo do WAF interrompe o processamento. Isso significa que outras regras personalizadas com prioridade mais baixa e regras gerenciadas não são mais executadas.

No exemplo a seguir, criamos uma regra personalizada com duas condições. A primeira condição está procurando o valor comment no corpo da solicitação. A segunda condição está procurando o valor /api/Feedbacks/ no URI de solicitação.

O uso de uma regra personalizada permite que você seja o mais granular possível ao ajustar suas regras do WAF e para lidar com falsos positivos. Nesse caso, não estamos 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. Ao incluir 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. Isso garante que o mesmo ataque, se executado em condições diferentes, ainda será inspecionado e impedido pelo mecanismo do WAF.

Registro

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

Desabilitar regras

Outra forma de contornar um falso positivo é desabilitando a regra que teve correspondência na entrada que o WAF pensou ser mal-intencionada. Como você analisou os logs do WAF e restringiu a regra para 942110, agora pode desabilitá-la no portal do Azure. Confira Personalizar regras do Firewall de Aplicativo Web 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 realmente legítimas ou quando você tem certeza de que a regra simplesmente não se aplica ao seu ambiente (como desabilitar uma regra de injeção de SQL porque você tem back-ends não SQL).

No entanto, 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.

Regras de WAF

Dica

É interessante documentar quaisquer alterações feitas na política do WAF. Inclua solicitações de exemplo para ilustrar a detecção de falsos positivos e explique claramente por que você adicionou uma regra personalizada, desabilitou uma regra ou um conjunto de regras ou adicionou uma exceção. Essa documentação pode ser útil se você reprojetar seu aplicativo no futuro e precisar verificar se suas alterações ainda são válidas. Ela também pode ajudar se você já tiver auditado ou se 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. Isso é útil quando precisamos excluir determinados campos da inspeção usando listas de exclusões no WAF.

Localizar nomes de atributo de solicitação

Neste exemplo, você pode ver o campo em que a cadeia de caracteres 1=1 foi inserida é chamada de comment. Esses dados foram passados no corpo de uma solicitação POST.

Solicitação do Fiddler mostrando o corpo

Esse é um campo que pode ser excluído. 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:

Regra de exclusão

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 Monitoramento de 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 exatamente 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 (confira Firewall de Aplicativo Web no Azure Front Door), você sabe que a regra com a propriedade action: Block está bloqueando com base nos dados correspondidos no corpo da solicitação. Você pode ver nos detalhes que houve a correspondência com um padrão (1=1) e que o campo está nomeado como comment. Siga as mesmas etapas anteriores para excluir o nome dos argumentos de postagem do corpo da solicitação que contém comment.

Localizar nomes de cabeçalho de solicitação

O Fiddler também é uma ferramenta útil para localizar nomes de cabeçalho de solicitação. Na captura de tela a seguir, você pode ver os cabeçalhos dessa solicitação GET, os quais incluem Content-Type, User-Agent e assim por diante. Você também pode usar cabeçalhos de solicitação para criar exclusões e regras personalizadas no WAF.

Solicitação do Fiddler mostrando o cabeçalho

Outra maneira de exibir cabeçalhos de solicitação e de resposta é examinando as ferramentas de desenvolvedor do seu navegador, como o Edge ou o Chrome. É possível pressionar F12 ou clicar com o botão direito do mouse em ->Inspecionar->Ferramentas para Desenvolvedores e selecionar a guia Rede. Carregue a página da Web e clique na solicitação a ser inspecionada.

Solicitação do inspetor de rede

Se a solicitação contiver cookies, a guia Cookies poderá ser selecionada 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, isso 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 e ajuste cada regra seguindo as diretrizes ao longo deste artigo.

Próximas etapas