Justera Azure Web Application Firewall (WAF) för Azure Front Door

Artikel
07/27/2023

Den Microsoft-hanterade standardregeluppsättningen baseras på OWASP Core Rule Set och innehåller Microsoft Threat Intelligence-insamlingsregler.

Det förväntas ofta att WAF-regler (Web Application Firewall) måste justeras så att de passar de specifika behoven för det program eller den organisation som använder WAF. Organisationer uppnår ofta justering genom att vidta någon av följande åtgärder:

Definiera regelundantag.
Skapa anpassade regler.
Inaktivera regler som kan orsaka problem eller falska positiva identifieringar.

Den här artikeln beskriver vad du kan göra om begäranden som ska skickas via din WAF blockeras.

Kommentar

Den Microsoft-hanterade regeluppsättningen är inte tillgänglig för Azure Front Door Standard SKU. Mer information om SKU:er på olika nivåer finns i Funktionsjämförelse mellan nivåer.

Läs översikten över Azure Front Door WAF och WAF Policy för Azure Front Door-dokument . Aktivera även WAF-övervakning och loggning. De här artiklarna förklarar hur WAF fungerar, hur WAF-regeluppsättningar fungerar och hur du får åtkomst till WAF-loggar.

Förstå WAF-loggar

Syftet med WAF-loggar är att visa varje begäran som matchas eller blockeras av WAF. Det är en samling av alla utvärderade begäranden som matchas eller blockeras. Om du märker att WAF blockerar en begäran om att den inte ska (en falsk positiv identifiering) kan du göra några saker.

Först ska du begränsa och hitta den specifika begäran. Du kan konfigurera ett anpassat svarsmeddelande så att det trackingReference innehåller fältet för att enkelt identifiera händelsen och utföra en loggfråga på det specifika värdet. Titta igenom loggarna för att hitta den specifika URI:n, tidsstämpeln eller klient-IP-adressen för begäran. När du hittar de relaterade loggposterna kan du agera på falska positiva identifieringar.

Anta till exempel att du har legitim trafik som innehåller strängen 1=1 som du vill skicka genom din WAF. Så här ser begäran ut:

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

Om du provar begäran blockerar WAF trafik som innehåller din 1=1 sträng i valfri parameter eller fält. Den här strängen är ofta associerad med en SQL-inmatningsattack. Du kan titta igenom loggarna och se tidsstämpeln för begäran och de regler som blockerade eller matchade.

I följande exempel visas en loggpost som genererades baserat på en regelmatchning. Du kan använda följande Log Analytics-fråga för att hitta begäranden som har blockerats under de senaste 24 timmarna.

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

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

I fältet requestUri kan du se att begäran gjordes specifikt /api/Feedbacks/ . Gå vidare och leta upp regel-ID:t 942110 i fältet ruleName . Om du känner till regel-ID:t kan du gå till den officiella lagringsplatsen för OWASP ModSecurity Core Rule Set och söka efter det regel-ID:t för att granska koden och förstå exakt vad den här regeln matchar.

Genom att kontrollera fältet action kan du sedan se att den här regeln är inställd på att blockera begäranden vid matchning. Du kan bekräfta att begäran har blockerats av WAF eftersom är policyMode inställd på prevention.

Kontrollera nu informationen i fältet details . I det här fältet kan du se matchVariableName informationen och matchVariableValue . Den här regeln utlöstes eftersom någon indata 1=1 i comment webbappens fält.

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

Det finns också ett värde i att kontrollera åtkomstloggarna för att utöka dina kunskaper om en viss WAF-händelse. Granska sedan loggen som genererades som ett svar på föregående händelse.

Du kan se att dessa loggar är relaterade eftersom värdet trackingReference är detsamma. Bland olika fält som ger allmän insikt, till exempel userAgent och clientIP, märker du fälten httpStatusCode och httpStatusDetails . Här kan du se att klienten tog emot ett HTTP 403-svar, vilket bekräftar att denna begäran nekades och blockerades.

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

Lösa falska positiva identifieringar

Om du vill fatta ett välgrundat beslut om att hantera falska positiva identifieringar är det viktigt att bekanta dig med de tekniker som programmet använder. Anta till exempel att det inte finns någon SQL-server i din teknikstack och att du får falska positiva identifieringar relaterade till dessa regler. Att inaktivera dessa regler försvagar inte nödvändigtvis din säkerhet.

Med den här informationen och kunskapen om att regel 942110 är den som matchade strängen 1=1 i exemplet kan du göra några saker för att förhindra att den här legitima begäran blockeras:

Använd undantagslistor. Mer information om undantagslistor finns i Azure Web Application Firewall med undantagslistor i Azure Front Door.
Ändra WAF-åtgärder. Mer information om vilka åtgärder som kan vidtas när en begäran matchar villkoren för en regel finns i WAF-åtgärder.
Använd anpassade regler. Mer information om anpassade regler finns i Anpassade regler för Azure Web Application Firewall med Azure Front Door.
Inaktivera regler.

Dricks

När du väljer en metod för att tillåta legitima begäranden via WAF kan du försöka göra det så smalt som möjligt. Det är till exempel bättre att använda en undantagslista än att inaktivera en regel helt.

Använda undantagslistor

En fördel med att använda en undantagslista är att endast den matchningsvariabel som du väljer att exkludera inte längre kontrolleras för den angivna begäran. Du kan alltså välja mellan specifika begärandehuvuden, begärandecookies, frågesträngsargument eller begärandetextinläggsargument som ska undantas om ett visst villkor uppfylls, i stället för att utesluta att hela begäran inspekteras. De andra icke-specificerade variablerna i begäran inspekteras normalt.

Undantag är en global inställning. Det konfigurerade undantaget gäller för all trafik som passerar via din WAF, inte bara en specifik webbapp eller URI. Detta kan till exempel vara ett problem om 1=1 det är en giltig begäran i brödtexten för en viss webbapp, men inte för andra under samma WAF-princip.

Om det är klokt att använda olika undantagslistor för olika program kan du överväga att använda olika WAF-principer för varje program och tillämpa dem på varje programs klientdel.

När du konfigurerar undantagslistor för hanterade regler kan du välja att exkludera:

Alla regler i en regeluppsättning.
Alla regler i en regelgrupp.
En enskild regel.

Du kan konfigurera en undantagslista med hjälp av PowerShell, Azure CLI, REST API, Bicep, Azure Resource Manager-mallar eller Azure Portal.

Undantag på regelnivå: Om undantag tillämpas på regelnivå innebär det att de angivna undantagen inte analyseras enbart mot den enskilda regeln. Den analyseras fortfarande av alla andra regler i regeluppsättningen. Det här är den mest detaljerade nivån för undantag. Du kan använda den för att finjustera den hanterade regeluppsättningen baserat på den information du hittar i WAF-loggarna när du felsöker en händelse.
Undantag på regelgruppsnivå: Om undantag tillämpas på regelgruppsnivå innebär det att de angivna undantagen inte analyseras mot den specifika uppsättningen regeltyper. Om du till exempel väljer SQLI som en undantagen regelgrupp visas de definierade undantagen för begäranden som inte kontrolleras av någon av de SQLI-specifika reglerna. Den kommer fortfarande att inspekteras av regler i andra grupper, till exempel PHP, RFI eller XSS. Den här typen av undantag kan vara användbar när du är säker på att programmet inte är känsligt för specifika typer av attacker. Till exempel kan ett program som inte har några SQL-databaser ha alla SQLI-regler undantagna utan att det är skadligt för dess säkerhetsnivå.
Undantag på en regeluppsättningsnivå: Om undantag tillämpas på en regeluppsättningsnivå innebär det att de angivna undantagen inte analyseras mot någon av de säkerhetsregler som är tillgängliga i regeluppsättningen. Det här undantaget är omfattande, så använd det noggrant.

I det här exemplet utför du ett undantag på den mest detaljerade nivån genom att tillämpa ett undantag på en enda regel. Du vill undanta matchningsvariabeln Begärandetext efter args-namn som innehåller comment. Du kan se matchningsvariabelinformationen i brandväggsloggen: "matchVariableName": "PostParamValue:comment". Attributet är comment. Du kan också hitta det här attributnamnet på några andra sätt. Mer information finns i Hitta namn på begärandeattribut.

Skärmbild som visar undantagsregler.

Skärmbild som visar regelundantag för en specifik regel.

Ibland finns det fall där specifika parametrar skickas till WAF på ett sätt som kanske inte är intuitivt. Till exempel skickas en token när du autentiserar med hjälp av Microsoft Entra-ID. Token __RequestVerificationToken skickas vanligtvis som en cookie för begäran.

I vissa fall där cookies är inaktiverade skickas även denna token som ett begärandepostargument. Därför måste du se till att __RequestVerificationToken läggs till i exkluderingslistan för både RequestCookieNames och RequestBodyPostArgsNamesför att åtgärda falska positiva identifieringar för Microsoft Entra-token.

Undantag för ett fältnamn (Väljare) innebär att värdet inte längre utvärderas av WAF. Själva fältnamnet fortsätter att utvärderas och i sällsynta fall kan det matcha en WAF-regel och utlösa en åtgärd.

Skärmbild som visar regelundantag för en regeluppsättning.

Ändra WAF-åtgärder

Ett annat sätt att hantera beteendet för WAF-regler är genom att välja den åtgärd som krävs när en begäran matchar en regels villkor. De tillgängliga åtgärderna är Tillåt, Blockera, Logga och Omdirigering.

I det här exemplet ändrades standardåtgärden Blockera till loggåtgärden på regel 942110. Den här åtgärden gör att WAF loggar begäran och fortsätter att utvärdera samma begäran mot de återstående reglerna med lägre prioritet.

Skärmbild som visar WAF-åtgärder.

När du har kört samma begäran kan du gå tillbaka till loggarna och se att den här begäran var en matchning i regel-ID 942110. Fältet action_s anger nu Logg i stället för Blockera. Loggfrågan expanderades sedan för att inkludera trackingReference_s informationen för att se vad mer som hände med den här begäran.

Skärmbild som visar en logg som visar flera regelmatchningar.

Nu kan du se en annan SQLI-regelmatchning som inträffar millisekunder efter att regel-ID 942110 har bearbetats. Samma begäran matchade på regel-ID 942310 och den här gången utlöstes standardåtgärden Blockera .

En annan fördel med att använda loggåtgärden under WAF-justering eller felsökning är att du kan identifiera om flera regler i en specifik regelgrupp matchar och blockerar en viss begäran. Du kan sedan skapa dina undantag på lämplig nivå, dvs. på regel- eller regelgruppsnivå.

Använda anpassade regler

När du har identifierat vad som orsakar en WAF-regelmatchning kan du använda anpassade regler för att justera hur WAF svarar på händelsen. Anpassade regler bearbetas före hanterade regler. De kan innehålla mer än ett villkor och deras åtgärder kan vara Tillåt, Neka, Logga eller Omdirigering.

Varning

När en begäran matchar en anpassad regel slutar WAF-motorn att bearbeta begäran. Hanterade regler bearbetas inte för den här begäran och inte heller andra anpassade regler med lägre prioritet.

I följande exempel visas en anpassad regel med två villkor. Det första villkoret söker comment efter värdet i begärandetexten. Det andra villkoret söker /api/Feedbacks/ efter värdet i begärande-URI:n.

Genom att använda en anpassad regel kan du vara den mest detaljerade så att du kan finjustera dina WAF-regler och hantera falska positiva identifieringar. I det här fallet vidtar du inte bara åtgärder baserat på värdet för begärandetexten comment , som kan finnas på flera webbplatser eller appar enligt samma WAF-princip.

När du inkluderar ett annat villkor som även matchar en viss URI /api/Feedbacks/för begäran ser du till att den här anpassade regeln verkligen gäller för det här explicita användningsfallet som du har granskat. På så sätt inspekteras samma attack, om den utförs mot olika förhållanden, fortfarande och förhindras av WAF-motorn.

Skärmbild som visar en logg.

När du utforskar loggen kan du se att fältet ruleName_s innehåller namnet på den anpassade regeln redirectcomment. I fältet action_s kan du se att omdirigeringsåtgärden har vidtagits för den här händelsen. I fältet details_matches_s kan du se att informationen för båda villkoren matchades.

Inaktivera regler

Ett annat sätt att komma runt ett falskt positivt är att inaktivera regeln som matchade indata som WAF trodde var skadlig. Eftersom du parsade WAF-loggarna och begränsade regeln till 942110 kan du inaktivera den i Azure Portal. Mer information finns i Anpassa Azure Web Application Firewall-regler med hjälp av Azure Portal.

Att inaktivera en regel är en fördel när du är säker på att alla begäranden som uppfyller det specifika villkoret är legitima begäranden eller när du är säker på att regeln inte gäller för din miljö (till exempel att inaktivera en SQL-inmatningsregel eftersom du har icke-SQL-serverdelar).

Att inaktivera en regel är en global inställning som gäller för alla klientdelsvärdar som är associerade med WAF-principen. När du väljer att inaktivera en regel kanske du lämnar sårbarheter exponerade utan skydd eller identifiering för andra klientdelsvärdar som är associerade med WAF-principen.

Om du vill använda Azure PowerShell för att inaktivera en hanterad regel kan du läsa objektdokumentationen PSAzureManagedRuleOverride . Om du vill använda Azure CLI kan du läsa dokumentationen az network front-door waf-policy managed-rules override .

Skärmbild som visar WAF-regler.

Dricks

Dokumentera eventuella ändringar som du gör i din WAF-princip. Inkludera exempelbegäranden för att illustrera identifieringen av falska positiva identifieringar. Förklara varför du har lagt till en anpassad regel, inaktiverat en regel eller regeluppsättning eller lagt till ett undantag. Om du gör om programmet i framtiden kan du behöva kontrollera att ändringarna fortfarande är giltiga. Eller så kan du bli granskad eller behöva motivera varför du konfigurerade om WAF-principen från standardinställningarna.

Sök efter fält för begäran

Genom att använda en webbläsarproxy som Fiddler kan du granska enskilda begäranden och avgöra vilka specifika fält på en webbsida som anropas. Den här tekniken är användbar när du behöver undanta vissa fält från inspektion med hjälp av undantagslistor i WAF.

Hitta namn på begärandeattribut

I det här exemplet kallas commentfältet där strängen 1=1 angavs . Dessa data skickades i brödtexten i en POST-begäran.

Skärmbild som visar brödtexten i en Fiddler-begäran.

Du kan exkludera det här fältet. Mer information om undantagslistor finns i Undantagslistor för brandvägg för webbprogram. Du kan exkludera utvärderingen i det här fallet genom att konfigurera följande undantag:

Skärmbild som visar en undantagsregel.

Du kan också granska brandväggsloggarna för att hämta informationen för att se vad du behöver lägga till i undantagslistan. Information om hur du aktiverar loggning finns i Övervaka mått och loggar i Azure Front Door.

Undersök brandväggsloggen PT1H.json i filen under den timme som begäran som du vill inspektera inträffade. Filerna PT1H.json är tillgängliga i lagringskontocontainrarna där FrontDoorWebApplicationFirewallLog diagnostikloggarna och FrontDoorAccessLog lagras.

Undersök brandväggsloggen PT1H.json i filen under den timme som begäran som du vill inspektera inträffade. Filerna PT1H.json är tillgängliga i lagringskontocontainrarna där FrontdoorWebApplicationFirewallLog diagnostikloggarna och FrontdoorAccessLog lagras.

I det här exemplet kan du se regeln som blockerade begäran (med samma transaktionsreferens) och som inträffade samtidigt.

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

Med dina kunskaper om hur Azure-hanterade regeluppsättningar fungerar vet du att regeln med action: Block egenskapen blockerar baserat på de data som matchas i begärandetexten. (Mer information finns i Azure Web Application Firewall i Azure Front Door.) Du kan se i informationen att det matchade ett mönster (1=1) och att fältet heter comment. Följ samma föregående steg för att undanta begärandetexten efter args-namnet som innehåller comment.

Hitta namn på begärandehuvud

Fiddler är ett användbart verktyg för att hitta namn på begäranderubriker. Följande skärmbild visar rubrikerna för den här GET-begäran, inklusive Content-Type och User-Agent. Du kan också använda begärandehuvuden för att skapa undantag och anpassade regler i WAF.

Skärmbild som visar rubriken för en Fiddler-begäran.

Ett annat sätt att visa begärande- och svarshuvuden är att titta i utvecklarverktygen i webbläsaren, till exempel Microsoft Edge eller Chrome. Du kan välja F12 eller högerklicka på Granska>utvecklarverktyg. Välj fliken Nätverk . Läs in en webbsida och välj den begäran som du vill granska.

Skärmbild som visar en begäran om nätverkskontroll.

Om begäran innehåller cookies väljer du fliken Cookies för att visa dem i Fiddler. Cookieinformation kan också användas för att skapa undantag eller anpassade regler i WAF.

Regel för avvikelsebedömning

Om du ser regel-ID 949110 under justeringsprocessen för waf anger dess närvaro att begäran blockerades av avvikelsebedömningsprocessen .

Granska de andra WAF-loggposterna för samma begäran genom att söka efter loggposterna med samma spårningsreferens. Titta på var och en av de regler som utlöstes. Justera varje regel genom att följa riktlinjerna i den här artikeln.

Varning

När du tilldelar en ny hanterad regeluppsättning till en WAF-princip återställs alla tidigare anpassningar från befintliga hanterade regeluppsättningar, till exempel regeltillstånd, regelåtgärder och undantag på regelnivå till standardinställningarna för den nya hanterade regeluppsättningen. Anpassade regler och principinställningar påverkas dock inte under tilldelningen av den nya regeluppsättningen.

Nästa steg

Läs mer om Azure Web Application Firewall.
Lär dig hur du skapar en instans av Azure Front Door.

Dela via

Justera Azure Web Application Firewall (WAF) för Azure Front Door

Förstå WAF-loggar

Lösa falska positiva identifieringar

Använda undantagslistor

Ändra WAF-åtgärder

Använda anpassade regler

Inaktivera regler

Sök efter fält för begäran

Hitta namn på begärandeattribut

Hitta namn på begärandehuvud

Regel för avvikelsebedömning

Nästa steg

Feedback

Ytterligare resurser

Dela via

Justera Azure Web Application Firewall (WAF) för Azure Front Door

Förstå WAF-loggar

Lösa falska positiva identifieringar

Använda undantagslistor

Ändra WAF-åtgärder

Använda anpassade regler

Inaktivera regler

Sök efter fält för begäran

Hitta namn på begärandeattribut

Hitta namn på begärandehuvud

Hitta namn på begärandecookies

Regel för avvikelsebedömning

Nästa steg

Feedback

Ytterligare resurser