Ottimizzare Web application firewall di Azure per Frontdoor di Azure

Articolo
07/27/2023

Il set di regole predefinite gestito da Microsoft si basa sul set di regole di base OWASP e include le regole di raccolta di Microsoft Threat Intelligence.

È spesso previsto che le regole web application firewall (WAF) siano ottimizzate in base alle esigenze specifiche dell'applicazione o dell'organizzazione che usa waf. Le organizzazioni in genere ottengono l'ottimizzazione eseguendo una delle azioni seguenti:

Definizione delle esclusioni delle regole.
Creazione di regole personalizzate.
Disabilitazione di regole che potrebbero causare problemi o falsi positivi.

Questo articolo descrive le operazioni che è possibile eseguire se le richieste che devono passare attraverso il WAF vengono bloccate.

Nota

Il set di regole gestito da Microsoft non è disponibile per lo SKU Standard di Frontdoor di Azure. Per altre informazioni sui diversi SKU di livello, vedere Confronto delle funzionalità tra livelli.

Leggere la panoramica di Frontdoor di Azure WAF e i documenti di Criteri WAF per Frontdoor di Azure. Abilitare anche il monitoraggio e la registrazione di WAF. Questi articoli illustrano come funzionano i set di regole WAF, come funzionano i set di regole WAF e come accedere ai log WAF.

Informazioni sui log WAF

Lo scopo dei log waf è mostrare ogni richiesta corrispondente o bloccata dal WAF. Si tratta di una raccolta di tutte le richieste valutate corrispondenti o bloccate. Se si nota che WAF blocca una richiesta che non deve (un falso positivo), è possibile eseguire alcune operazioni.

Prima di tutto, restringere e trovare la richiesta specifica. È possibile configurare un messaggio di risposta personalizzato per includere il trackingReference campo per identificare facilmente l'evento ed eseguire una query di log su tale valore specifico. Esaminare i log per trovare l'URI, il timestamp o l'INDIRIZZO IP client specifico della richiesta. Quando si trovano le voci di log correlate, è possibile agire su falsi positivi.

Si supponga, ad esempio, di avere traffico legittimo che contiene la stringa 1=1 che si vuole passare attraverso il WAF. Ecco l'aspetto della richiesta:

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 si prova la richiesta, WAF blocca il traffico che contiene la 1=1 stringa in qualsiasi parametro o campo. Questa stringa è spesso associata a un attacco SQL injection. È possibile esaminare i log e visualizzare il timestamp della richiesta e le regole bloccate o corrispondenti.

Nell'esempio seguente viene illustrata una voce di log generata in base a una corrispondenza di una regola. È possibile usare la query di Log Analytics seguente per trovare le richieste bloccate nelle ultime 24 ore.

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

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

requestUri Nel campo è possibile vedere che la richiesta è stata effettuata /api/Feedbacks/ in modo specifico. Per altre informazioni, trovare l'ID 942110 regola nel ruleName campo . Conoscere l'ID regola, è possibile passare al repository ufficiale OWASP ModSecurity Core Rule Set e cercare in base a tale ID regola per esaminarne il codice e comprendere esattamente ciò che corrisponde a questa regola.

Quindi, controllando il action campo, è possibile vedere che questa regola è impostata per bloccare le richieste al momento della corrispondenza. È possibile verificare che la richiesta sia stata bloccata dal WAF perché policyMode è impostata su prevention.

Controllare ora le informazioni nel details campo. Questo campo consente di visualizzare le matchVariableName informazioni e matchVariableValue . Questa regola è stata attivata perché un utente immette 1=1 nel comment campo dell'app 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\""
        }
    }
}

È anche possibile controllare i log di accesso per espandere le conoscenze relative a un determinato evento WAF. Esaminare quindi il log generato come risposta all'evento precedente.

È possibile vedere che questi log sono correlati perché il trackingReference valore è lo stesso. Tra i vari campi che forniscono informazioni generali, ad esempio userAgent e clientIP, si notino i httpStatusCode campi e httpStatusDetails . Qui è possibile notare che il client ha ricevuto una risposta HTTP 403, che conferma che la richiesta è stata negata e bloccata.

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

Risolvere i falsi positivi

Per prendere una decisione informata sulla gestione di un falso positivo, è importante acquisire familiarità con le tecnologie usate dall'applicazione. Si supponga, ad esempio, che non sia presente un server SQL nello stack di tecnologie e che si ottengano falsi positivi correlati a tali regole. La disabilitazione di queste regole non indeboli necessariamente la sicurezza.

Con queste informazioni e la conoscenza che la regola 942110 è quella che corrisponde alla 1=1 stringa nell'esempio, è possibile eseguire alcune operazioni per impedire che questa richiesta legittima venga bloccata:

Usare elenchi di esclusione. Per altre informazioni sugli elenchi di esclusione, vedere Web application firewall di Azure con elenchi di esclusione di Frontdoor di Azure.
Modificare le azioni WAF. Per altre informazioni sulle azioni che è possibile eseguire quando una richiesta corrisponde alle condizioni di una regola, vedere Azioni WAF.
Usare regole personalizzate. Per altre informazioni sulle regole personalizzate, vedere Regole personalizzate per Web application firewall di Azure con Frontdoor di Azure.
Disabilitare le regole.

Suggerimento

Quando si seleziona un approccio per consentire richieste legittime tramite WAF, provare a renderlo più stretto possibile. Ad esempio, è preferibile usare un elenco di esclusione che disabilitare completamente una regola.

Usare elenchi di esclusione

Un vantaggio dell'uso di un elenco di esclusione è che solo la variabile di corrispondenza selezionata da escludere non verrà più controllata per la richiesta specificata. Ciò significa che è possibile scegliere tra intestazioni di richiesta specifiche, cookie di richiesta, argomenti della stringa di query o argomenti post del corpo della richiesta da escludere se viene soddisfatta una determinata condizione, anziché escludere l'intera richiesta da esaminare. Le altre variabili non specificate della richiesta vengono esaminate normalmente.

Le esclusioni sono un'impostazione globale. L'esclusione configurata si applica a tutto il traffico che passa attraverso il WAF, non solo a un'app Web o a un URI specifico. Ad esempio, questo potrebbe essere un problema se 1=1 è una richiesta valida nel corpo di una determinata app Web, ma non per altri con gli stessi criteri WAF.

Se è opportuno usare elenchi di esclusione diversi per applicazioni diverse, è consigliabile usare criteri WAF diversi per ogni applicazione e applicarli al front-end di ogni applicazione.

Quando si configurano elenchi di esclusione per le regole gestite, è possibile scegliere di escludere:

Tutte le regole all'interno di un set di regole.
Tutte le regole all'interno di un gruppo di regole.
Una singola regola.

È possibile configurare un elenco di esclusione usando PowerShell, l'interfaccia della riga di comando di Azure, l'API REST, Bicep, i modelli di Azure Resource Manager o il portale di Azure.

Esclusioni a livello di regola: l'applicazione di esclusioni a livello di regola significa che le esclusioni specificate non verranno analizzate solo in base a tale singola regola. Verrà comunque analizzato da tutte le altre regole nel set di regole. Questo è il livello più granulare per le esclusioni. È possibile usarlo per ottimizzare il set di regole gestite in base alle informazioni disponibili nei log waf quando si risolve un evento.
Esclusioni a livello di gruppo di regole: l'applicazione di esclusioni a livello di gruppo di regole significa che le esclusioni specificate non verranno analizzate in base a quel set specifico di tipi di regole. Se ad esempio si seleziona SQLI come gruppo di regole escluso, le esclusioni di richieste definite non verranno esaminate da alcuna delle regole specifiche di SQLI. Verrà comunque controllato da regole in altri gruppi, ad esempio PHP, RFI o XSS. Questo tipo di esclusione può essere utile quando si è certi che l'applicazione non sia soggetta a tipi specifici di attacchi. Ad esempio, un'applicazione che non dispone di database SQL potrebbe avere tutte le regole SQLI escluse senza danneggiarne il livello di sicurezza.
Esclusioni a livello di set di regole: l'applicazione di esclusioni a livello di set di regole indica che le esclusioni specificate non verranno analizzate in base alle regole di sicurezza disponibili in tale set di regole. Questa esclusione è completa, quindi usarla con attenzione.

In questo esempio si esegue un'esclusione al livello più granulare applicando un'esclusione a una singola regola. Si vuole escludere il nome del corpo della variabile di corrispondenza Request post args che contiene comment. È possibile visualizzare i dettagli della variabile di corrispondenza nel log del firewall: "matchVariableName": "PostParamValue:comment". L'attributo è comment. È anche possibile trovare il nome di questo attributo in altri modi. Per altre informazioni, vedere Trovare i nomi degli attributi della richiesta.

Screenshot that shows exclusion rules.

Screenshot that shows rule exclusion for a specific rule.

In alcuni casi, in alcuni casi, i parametri specifici vengono passati nel WAF in modo che non siano intuitivi. Ad esempio, un token viene passato quando si esegue l'autenticazione usando Microsoft Entra ID. Il token __RequestVerificationToken viene in genere passato come cookie di richiesta.

In alcuni casi in cui i cookie sono disabilitati, questo token viene passato anche come argomento post di richiesta. Per questo motivo, per risolvere i falsi positivi del token Microsoft Entra, è necessario assicurarsi che __RequestVerificationToken venga aggiunto all'elenco di esclusione sia per che RequestBodyPostArgsNamesper RequestCookieNames .

Le esclusioni in un nome di campo (selettore) indicano che il valore non verrà più valutato dal WAF. Il nome del campo stesso continua a essere valutato e in rari casi potrebbe corrispondere a una regola WAF e attivare un'azione.

Screenshot that shows rule exclusion for a rule set.

Modificare le azioni WAF

Un altro modo per gestire il comportamento delle regole WAF consiste nel scegliere l'azione eseguita quando una richiesta corrisponde alle condizioni di una regola. Le azioni disponibili sono Consenti, Blocca, Log e Reindirizzamento.

In questo esempio, l'azione predefinita Blocca è stata modificata nell'azione Log sulla regola 942110. Questa azione fa sì che WAF registri la richiesta e continui a valutare la stessa richiesta rispetto alle regole di priorità inferiori rimanenti.

Screenshot that shows WAF actions.

Dopo aver eseguito la stessa richiesta, è possibile fare riferimento ai log e verificare che questa richiesta sia stata una corrispondenza nell'ID regola 942110. Il action_s campo indica ora Log invece di Block. La query di log è stata quindi espansa per includere le trackingReference_s informazioni per vedere cos'altro è successo con questa richiesta.

Screenshot that shows a log showing multiple rule matches.

È ora possibile visualizzare una corrispondenza diversa della regola SQLI che si verifica in millisecondi dopo l'elaborazione dell'ID regola 942110. La stessa richiesta corrisponde all'ID regola 942310 e questa volta è stata attivata l'azione predefinita Blocca .

Un altro vantaggio dell'uso dell'azione Log durante l'ottimizzazione o la risoluzione dei problemi di WAF è che è possibile identificare se più regole all'interno di un gruppo di regole specifico corrispondono e bloccano una determinata richiesta. È quindi possibile creare le esclusioni a livello appropriato, ovvero a livello di regola o gruppo di regole.

Usare regole personalizzate

Dopo aver identificato la causa di una corrispondenza di una regola WAF, è possibile usare regole personalizzate per modificare la risposta del WAF all'evento. Le regole personalizzate vengono elaborate prima delle regole gestite. Possono contenere più di una condizione e le relative azioni possono essere Consenti, Nega, Log o Reindirizzamento.

Avviso

Quando una richiesta corrisponde a una regola personalizzata, il motore WAF interrompe l'elaborazione della richiesta. Le regole gestite non verranno elaborate per questa richiesta e nessuna delle altre regole personalizzate con priorità più bassa.

Nell'esempio seguente viene illustrata una regola personalizzata con due condizioni. La prima condizione cerca il comment valore nel corpo della richiesta. La seconda condizione cerca il /api/Feedbacks/ valore nell'URI della richiesta.

Usando una regola personalizzata, è possibile essere la più granulare in modo da poter ottimizzare le regole WAF e gestire i falsi positivi. In questo caso, non si esegue alcuna azione solo in base al valore del corpo della comment richiesta, che può esistere in più siti o app con lo stesso criterio WAF.

Quando si include un'altra condizione per la corrispondenza anche in un particolare URI /api/Feedbacks/di richiesta, assicurarsi che questa regola personalizzata venga effettivamente applicata a questo caso d'uso esplicito che è stato esaminato. In questo modo, lo stesso attacco, se eseguito contro condizioni diverse, viene comunque controllato e impedito dal motore WAF.

Screenshot that shows a log.

Quando si esplora il log, è possibile notare che il ruleName_s campo contiene il nome assegnato alla regola redirectcommentpersonalizzata . action_s Nel campo è possibile vedere che l'azione Reindirizzamento è stata eseguita per questo evento. details_matches_s Nel campo è possibile visualizzare i dettagli per entrambe le condizioni corrispondenti.

Disabilitare le regole

Un altro modo per aggirare un falso positivo consiste nel disabilitare la regola che corrisponde all'input che il WAF pensava fosse dannoso. Poiché sono stati analizzati i log waf e la regola è stata ridotta a 942110, è possibile disabilitarla nella portale di Azure. Per altre informazioni, vedere Personalizzare le regole di Web application firewall di Azure usando il portale di Azure.

La disabilitazione di una regola è un vantaggio quando si è certi che tutte le richieste che soddisfano tale condizione specifica siano richieste legittime o quando si è certi che la regola non si applica all'ambiente, ad esempio disabilitando una regola di inserimento SQL perché si dispone di back-end non SQL.

La disabilitazione di una regola è un'impostazione globale che si applica a tutti gli host front-end associati ai criteri WAF. Quando si sceglie di disabilitare una regola, è possibile che le vulnerabilità vengano esposte senza protezione o rilevamento per altri host front-end associati ai criteri WAF.

Se si vuole usare Azure PowerShell per disabilitare una regola gestita, vedere la documentazione dell'oggetto PSAzureManagedRuleOverride . Per usare l'interfaccia della riga di comando di Azure, vedere la az network front-door waf-policy managed-rules override documentazione.

Screenshot that shows WAF rules.

Suggerimento

Documentare le modifiche apportate ai criteri WAF. Includere richieste di esempio per illustrare il rilevamento dei falsi positivi. Spiegare perché è stata aggiunta una regola personalizzata, è stata disabilitata una regola o un set di regole oppure è stata aggiunta un'eccezione. Se si riprogetta l'applicazione in futuro, potrebbe essere necessario verificare che le modifiche siano ancora valide. In alternativa, potrebbe essere necessario controllare o giustificare il motivo per cui è stato riconfigurato il criterio WAF dalle impostazioni predefinite.

Trovare i campi della richiesta

Usando un proxy del browser come Fiddler, è possibile esaminare le singole richieste e determinare quali campi specifici di una pagina Web vengono chiamati. Questa tecnica è utile quando è necessario escludere determinati campi dall'ispezione usando elenchi di esclusione nel WAF.

Trovare i nomi degli attributi della richiesta

In questo esempio il campo in cui è stata immessa la 1=1 stringa è denominato comment. Questi dati sono stati passati nel corpo di una richiesta POST.

Screenshot that shows the body of a Fiddler request.

È possibile escludere questo campo. Per altre informazioni sugli elenchi di esclusione, vedere Elenchi di esclusione di Web application firewall. È possibile escludere la valutazione in questo caso configurando l'esclusione seguente:

Screenshot that shows an exclusion rule.

È anche possibile esaminare i log del firewall per ottenere le informazioni necessarie per visualizzare gli elementi da aggiungere all'elenco di esclusione. Per abilitare la registrazione, vedere Monitorare le metriche e i log in Frontdoor di Azure.

Esaminare il log del PT1H.json firewall nel file per l'ora in cui si desidera controllare la richiesta. I PT1H.json file sono disponibili nei contenitori dell'account di archiviazione in cui FrontDoorWebApplicationFirewallLog sono archiviati i log di diagnostica e FrontDoorAccessLog .

Esaminare il log del PT1H.json firewall nel file per l'ora in cui si desidera controllare la richiesta. I PT1H.json file sono disponibili nei contenitori dell'account di archiviazione in cui FrontdoorWebApplicationFirewallLog sono archiviati i log di diagnostica e FrontdoorAccessLog .

In questo esempio è possibile visualizzare la regola che ha bloccato la richiesta (con lo stesso riferimento alla transazione) e che si è verificata contemporaneamente.

{
    "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 la conoscenza del funzionamento dei set di regole gestite da Azure, si sa che la regola con la action: Block proprietà blocca in base ai dati corrispondenti nel corpo della richiesta. Per altre informazioni, vedere Web application firewall di Azure in Frontdoor di Azure. È possibile visualizzare nei dettagli che corrisponde a un criterio (1=1) e il campo è denominato comment. Seguire gli stessi passaggi precedenti per escludere il corpo della richiesta dopo il nome args che contiene comment.

Trovare i nomi delle intestazioni della richiesta

Fiddler è uno strumento utile per trovare i nomi delle intestazioni delle richieste. Lo screenshot seguente mostra le intestazioni per questa richiesta GET, che includono Content-Type e User-Agent. È anche possibile usare le intestazioni della richiesta per creare esclusioni e regole personalizzate nel WAF.

Screenshot that shows the header of a Fiddler request.

Un altro modo per visualizzare le intestazioni di richiesta e risposta consiste nell'esaminare gli strumenti di sviluppo del browser, ad esempio Microsoft Edge o Chrome. È possibile selezionare F12 o fare clic con il pulsante destro del mouse su Ispeziona>strumenti di sviluppo. Selezionare la scheda Rete . Caricare una pagina Web e selezionare la richiesta da esaminare.

Screenshot that shows a Network inspector request.

Se la richiesta contiene cookie, selezionare la scheda Cookie per visualizzarli in Fiddler. Le informazioni sui cookie possono essere usate anche per creare esclusioni o regole personalizzate nel WAF.

Regola di assegnazione dei punteggi anomalie

Se durante il processo di ottimizzazione del WAF viene visualizzato l'ID regola 949110, la relativa presenza indica che la richiesta è stata bloccata dal processo di assegnazione dei punteggi anomalie.

Esaminare le altre voci di log WAF per la stessa richiesta cercando le voci di log con lo stesso riferimento di rilevamento. Esaminare ognuna delle regole attivate. Ottimizzare ogni regola seguendo le indicazioni riportate in questo articolo.

Passaggi successivi

Informazioni sul web application firewall di Azure.
Informazioni su come creare un'istanza di Frontdoor di Azure.