Ottimizzare Web application firewall di Azure per Frontdoor di Azure

  • Articolo

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 monitoraggio e 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 dovrebbe bloccare (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 campo trackingReference in modo da 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 tenta la richiesta, il WAF blocca il traffico contenente la stringa 1=1 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'

Nel campo requestUri è possibile vedere che la richiesta è stata effettuata per /api/Feedbacks/ in modo specifico. Per altre informazioni, trovare l'ID regola 942110 nel campo ruleName. Conoscendo 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 campo action, è 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é il policyMode è impostato su prevention.

Controllare ora le informazioni nel campo details. Questo campo consente di visualizzare il matchVariableName e le informazioni matchVariableValue. Questa regola è stata attivata perché un utente immette 1=1 nel campo comment 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 valore trackingReference è lo stesso. Tra i vari campi che forniscono informazioni generali, ad esempio userAgent e clientIP, si notino i campi httpStatusCode 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 necessariamente indebolisce la sicurezza.

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

Suggerimento

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

Usare elenchi di esclusione

Un vantaggio di usare un elenco di esclusione è che solo la variabile di corrispondenza selezionata per l’esclusione non verrà più esaminata 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 la variabile di corrispondenza Corpo della richiesta post args name 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 che mostra le regole di esclusione.

Screenshot che mostra l'esclusione delle regole per una regola specifica.

Occasionalmente, ci sono casi in cui parametri specifici vengono passati al WAF in un modo che potrebbe non essere intuitivo. 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 RequestCookieNames che per RequestBodyPostArgsNames.

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 che mostra l'esclusione delle regole per un set di regole.

Modificare le azioni WAF

Un altro modo per gestire il comportamento delle regole WAF consiste nello 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 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 che mostra le azioni WAF.

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 campo action_s indica ora Log anziché Blocca. La query di log è stata quindi espansa per includere le informazioni di trackingReference_s per vedere cos'altro è successo con questa richiesta.

Screenshot che mostra un log che mostra più corrispondenze tra regole.

È 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. Per questa richiesta le regole gestite non verranno elaborate e neanche 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 valore comment nel corpo della richiesta. La seconda condizione cerca il valore /api/Feedbacks/ 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 richiesta comment, 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 di richiesta /api/Feedbacks/, assicurarsi che questa regola personalizzata si applichi realmente 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 che mostra un log.

Quando si esplora il log, si noterà che il campo ruleName_s contiene il nome assegnato alla regola personalizzata redirectcomment. Nel campo action_s è possibile osservare che è stata eseguita l'azione reindirizzamento per questo evento. Nel campo details_matches_s è possibile visualizzare i dettagli di 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 nel 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 documentazione az network front-door waf-policy managed-rules override.

Screenshot che mostra le regole WAF.

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, perché è 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 stringa 1=1 è denominato comment. Questi dati sono stati passati nel corpo di una richiesta POST.

Screenshot che mostra il corpo di una richiesta Fiddler.

È 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 che mostra una regola di esclusione.

È 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 firewall nel file PT1H.json per l'ora in cui si desidera controllare la richiesta. I file PT1H.json sono disponibili nei contenitori dell'account di archiviazione in cui vengono archiviati i log di diagnostica FrontDoorWebApplicationFirewallLog e FrontDoorAccessLog.

Esaminare il log del firewall nel file PT1H.json per l'ora in cui si desidera controllare la richiesta. I file PT1H.json sono disponibili nei contenitori dell'account di archiviazione in cui vengono archiviati i log di diagnostica FrontdoorWebApplicationFirewallLog 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 gestiti da Azure, si sa che la regola con la proprietà action: Block 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 che mostra l'intestazione di una richiesta Fiddler.

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 che mostra una richiesta di Controllo di rete.

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 sua 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.

Avviso

Quando si assegna un nuovo set di regole gestite a un criterio WAF, tutte le personalizzazioni precedenti dei set di regole gestite esistenti, ad esempio lo stato della regola, le azioni delle regole e le esclusioni a livello di regola verranno reimpostate sulle impostazioni predefinite del nuovo set di regole gestite. Tuttavia, tutte le regole personalizzate e le impostazioni dei criteri rimarranno invariate durante la nuova assegnazione del set di regole.

Passaggi successivi