Ottimizzare Web application firewall (WAF) di Azure per Frontdoor di Azure

Si applica a: ✔️ Front Door Standard/Premium ✔️ Front Door (versione classica)

Il set di regole predefinito gestito da Microsoft si basa sul set di regole di base di OWASP Core Rule Set e include le regole di raccolta delle minacce di Microsoft Threat Intelligence.

Spesso è necessario regolare le regole del firewall delle applicazioni web (WAF) per adattarle alle esigenze specifiche della propria applicazione o organizzazione. Le azioni di accordatura più comuni includono:

  • Definizione delle esclusioni delle regole.
  • Creazione di regole personalizzate.
  • Disabilitare le regole che causano problemi o falsi positivi.

Questo articolo descrive cosa puoi fare se il WAF blocca le richieste che dovrebbero passare.

Nota

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

Leggi la panoramica di Frontdoor di Azure WAF e l'articolo sui 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.

Comprendere l'impatto dell'ambito di applicazione dei criteri prima di ottimizzare

Prima di modificare regole, esclusioni o azioni, identifica l'ambito in cui hai associato la politica:

  • Livello profilo: le modifiche possono influire su tutto il traffico protetto nel profilo.
  • Livello di dominio: le modifiche influenzano il traffico per le associazioni di dominio selezionate.
  • Livello di percorso: le modifiche riguardano solo i percorsi abbinati e sono l'opzione più mirata.

Se si applicano più ambiti a una richiesta, la policy a livello di percorso ha la precedenza sulla policy a livello di dominio, e la policy a livello di dominio ha la precedenza sulla policy a livello di profilo.

Per la maggior parte delle missioni, si inizia con una regolazione di base all'ambito del profilo e si sposta le eccezioni all'ambito del dominio o della rotta per ridurre il raggio operativo di esplosione.

Informazioni sui log di WAF

Lo scopo dei log WAF è mostrare ogni richiesta che il WAF corrisponde o blocca. I log raccolgono tutte le richieste valutate che il WAF intercetta o blocca. Se noti che il WAF blocca una richiesta che non dovrebbe (un falso positivo), puoi intraprendere diverse azioni.

Prima di tutto, individua e restringi la richiesta specifica. Puoi configurare un messaggio di risposta personalizzato per includere il trackingReference campo, così da poter facilmente identificare l'evento ed eseguire una query di log su quel 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 intervenire sui falsi positivi.

Ad esempio, supponiamo che tu abbia traffico legittimo che contiene la stringa 1=1 che vuoi far passare attraverso il tuo 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.

L'esempio seguente mostra una voce di log generata in base alla corrispondenza di una regola. Puoi utilizzare la seguente query Log Analytics per trovare le richieste bloccate dal WAF 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. Andando oltre, trova l'ID regola 942110 nel campo ruleName. Conoscendo l'ID della regola, puoi andare nel repository ufficiale OWASP ModSecurity Core Rule Set e cercare per quell'ID per esaminare il codice e capire esattamente con quale corrispondenza questa regola.

Controllando il action campo, puoi vedere che questa regola è impostata per bloccare le richieste al momento del matching. È 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. Ad esempio, se lo stack di tecnologie non include un server SQL e si ottengono falsi positivi correlati a tali regole, la disabilitazione di tali regole non indeboli necessariamente 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 dell'uso di una lista di esclusione è che il WAF smette di ispezionare la variabile di corrispondenza che selezioni per l'esclusione di quella richiesta. Puoi scegliere intestazioni specifiche della richiesta, cookie della richiesta, parametri della stringa di query o parametri POST del corpo della richiesta da escludere se è soddisfatta una determinata condizione, invece di escludere l'intera richiesta dall'ispezione. 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, questa condizione potrebbe essere un problema se 1=1 è una richiesta valida nel corpo per una determinata app web, ma non per altre sotto la stessa politica 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, il interfaccia della riga di comando di Azure, l'API REST, Bicep, Azure Resource Manager o il portale di Azure.

  • Esclusioni a livello di regola: Applicare esclusioni a livello di regola significa che le esclusioni specificate non si applicano a quella regola individuale. Tutte le altre regole del set di regole analizzano comunque la richiesta. Questo livello fornisce la maggiore granularità per le esclusioni. Usalo per ottimizzare il set di regole gestito in base alle informazioni che trovi nei log WAF quando ti risolvi un evento.
  • Esclusioni a livello di gruppo di regole: Applicare esclusioni a livello di gruppo di regole significa che le esclusioni specificate non si applicano a quel specifico insieme di tipi di regole. Ad esempio, selezionare SQLI come gruppo di regole escluse indica che le esclusioni definite delle richieste non vengono ispezionate da nessuna delle regole specifiche di SQLI. Le regole in altri gruppi, come PHP, RFI o XSS, continuano a ispezionare la richiesta. 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 insieme di regole: Applicare esclusioni a livello di insieme di regole significa che le esclusioni specificate non si applicano a nessuna delle regole di sicurezza disponibili in quel 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 Request body 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 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.

Nei casi in cui i cookie sono disabilitati, questo token viene passato anche come argomento post richiesta. 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 su un nome di campo (Selettore) significano che il valore non viene 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 di una regola all'interno di 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 contenente più corrispondenze di 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 cosa causa una corrispondenza tra regole WAF, usa regole personalizzate per modificare come il WAF risponde 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 includi un'altra condizione per corrispondere anche a un particolare URI di richiesta /api/Feedbacks/, ti assicuri che questa regola personalizzata si applichi realmente a questo caso d'uso esplicito che hai verificato. 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 con corrispondenza.

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

Disabilitare una regola si applica a tutto il traffico valutato secondo l'ambito di quell'associazione di politiche. Quando scegli di disabilitare una regola, potresti lasciare vulnerabilità esposte senza protezione o rilevamento per altri traffici coperti dallo stesso ambito.

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

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 hai inserito la 1=1 stringa si chiama comment. Questi dati vengono inseriti nel corpo di una richiesta POST.

Screenshot che mostra il contenuto di una richiesta su 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.

Puoi anche esaminare i log del firewall per ottenere le informazioni necessarie da aggiungere alla lista delle esclusioni. Per abilitare la registrazione dei log, 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 tua conoscenza del funzionamento dei set di regole gestiti da Azure, sai che la regola con la proprietà action: Block blocca in base ai dati corrispondenti nel corpo della richiesta. (Per maggiori informazioni, vedi Web application firewall di Azure in Frontdoor di Azure.) Vedi nei dettagli che corrispondeva a un pattern (1=1) e il campo è chiamato 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 individuare i nomi degli header delle richieste. Lo screenshot seguente mostra le intestazioni per questa richiesta GET, che includono Content-Type e User-Agent. È anche possibile utilizzare le intestazioni delle richieste 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 punteggio delle 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. Affinare ogni regola seguendo le indicazioni riportate in questo articolo.

Quando si regolano le richieste in distribuzioni con ambito misto, annota nelle note dell'incidente l'ambito di applicazione effettivo del criterio (profilo, dominio o percorso). Questo aiuta a prevenire future regressioni quando i team aggiungono o modificano associazioni.

Avviso

Quando si assegna un nuovo regolamento gestito a una policy WAF, tutte le personalizzazioni precedenti dei set di regole gestite esistenti, come stato delle regole, azioni delle regole ed esclusioni a livello di regola, vengono resettate ai valori predefiniti del nuovo set di regole gestite. Tuttavia, eventuali regole personalizzate e impostazioni dei criteri restano inalterate durante l'assegnazione del nuovo set di regole.

Contenuti correlati

Passaggi successivi

  • Last updated on