Vad är Azure-brandväggen för webbaserade program?
Här lär du dig grunderna i Azure Web Application Firewall. Den här översikten hjälper dig att utvärdera om Azure Web Application Firewall är ett användbart verktyg att lägga till i Contosos övergripande strategi för nätverkssäkerhet.
Översikt över Azure Web Application Firewall
Du kanske tror att skadliga användare inte bryr sig om dina webbappar. Tester har dock visat att robotar eller skadliga aktörer avsöker nya webbappar efter svagheter inom några minuter efter distributionen. Om du placerar en app på webben antar du att hotaktörerna testar appen för sårbarheter nästan omedelbart. Du kan också anta att sådana avsökningar fortsätter under appens livslängd.
De flesta skadliga tester av webbappar kontrollerar om det finns en eller flera vanliga säkerhetsrisker. Om det hittas kan en hotskådespelare använda dessa sårbarheter för att köra attacker som följande kryphål:
- SQL-inmatning
- Skriptkörning över flera webbplatser
- Lokal fil och fjärrfilinkludering
- HTTP/HTTPS-översvämningar
- Skadliga robotattacker
En vanlig uppgift i webbappens utvecklingscykel är att skriva kod för att stänga de vanligaste säkerhetshålen. Att skriva säkerhetskoden kräver tid, expertis och testning.
Azure Web Application Firewall är en Azure-tjänst som ger ett centraliserat skydd av Azure-värdbaserade webbappar. Azure Web Application Firewall skyddar webbappar från vanliga hot som SQL-inmatning och skript mellan webbplatser.
Du kan distribuera Azure Web Application Firewall på några minuter. Dina webbappar får omedelbart kraftfullt skydd mot kända hot, allt utan att skriva en enda rad säkerhetskod.
Viktiga funktioner i Azure Web Application Firewall
Här är några viktiga funktioner som hjälper dig att utvärdera Azure Web Application Firewall:
Hanterade regler: De regler som Azure Web Application Firewall använder för att identifiera och förhindra vanliga kryphål skapas, underhålls och uppdateras av Microsofts säkerhetsteam. Om en regel ändras, eller om en regeluppsättning (se följande beskrivning) ändras, uppdaterar Microsoft Azure Web Application Firewall automatiskt och sömlöst.
Kommentar
Du kan inte ändra eller ta bort de hanterade regler som erbjuds av Azure Web Application Firewall. Men om en viss regel är problematisk för din miljö (till exempel blockerar legitim trafik till webbappen) kan du skapa undantag eller inaktivera regeln eller regeluppsättningen. Du kan också skapa anpassade regler för att skriva över standardbeteendet.
Robotregler: Robotreglerna identifierar bra robotar och skyddar mot dåliga robotar. Dåliga robotar identifieras baserat på Microsoft Threat Intelligence.
Anpassade regler: Om de hanterade reglerna som erbjuds av Azure Web Application Firewall inte täcker ett specifikt hot mot ditt webbprogram kan du skapa en anpassad regel.
Lägen: Azure Web Application Firewall kan fungera i något av två lägen: identifieringsläget loggar endast begäranden som bryter mot en regel, medan förebyggande läge både loggar och blockerar begäranden som bryter mot en regel.
Undantagslistor: Du kan konfigurera Azure Web Application Firewall för att ignorera specifika attribut när begäranden kontrolleras.
Principer: Du kan kombinera en uppsättning hanterade regler, anpassade regler, undantag och andra Azure Web Application Firewall-inställningar till ett enda element som kallas en Azure Web Application Firewall-princip. Du kan sedan tillämpa den principen på flera webbappar för enkel hantering och underhåll.
Storleksbegränsningar för begäranden: Du kan konfigurera Azure Web Application Firewall för att flagga begäranden som antingen är för små eller för stora.
Aviseringar: Azure Web Application Firewall integreras med Azure Monitor. Den här integreringen ger dig nästan realtidsaviseringar när WAF identifierar ett hot.
Vanliga attacker som förhindras av Azure Web Application Firewall
I följande tabell beskrivs de vanligaste typerna av skadliga hot som Azure Web Application Firewall hjälper till att skydda mot.
| Hot | beskrivning |
|---|---|
| Skriptkörning över flera webbplatser | En hotskådespelare använder ett webbprogram för att skicka skadlig kod till en annan användares webbläsare. Webbläsaren kör koden, vilket ger skriptet åtkomst till användarens sessionsdata, cookies och annan känslig information. |
| Lokal fil inkludering | En angripare utnyttjar sårbarheter i en servers hantering av include instruktioner, oftast i PHP-skript. Genom att skicka särskilt konfigurerad text till ett skripts include -instruktion kan angriparen inkludera filer som finns lokalt på servern. Angriparen kan sedan komma åt känslig information och köra serverkommandon. |
| PHP-inmatning | Angriparen infogar text som är särskilt konfigurerad för att lura servern att köra PHP-kommandon. Med de här kommandona kan angriparen köra lokal eller fjärransluten PHP-kod. Angriparen kan då komma åt känsliga data och köra kommandon på servern. |
| Protokollattacker | En angripare infogar särskilt konfigurerad text i en HTTP/HTTPS-begäranderubrik. Beroende på vilken text som matas in i rubriken kan angriparen lura servern att visa känsliga data eller köra kod. |
| Fjärrkommandokörning | Angriparen lurar en server att köra kommandon som är associerade med serverns operativsystem. I ett UNIX-system kan angriparen till exempel få servern att köras ls för att hämta en kataloglista. |
| Fjärrfilinkludering | Samma som lokal filinkludering, förutom att angriparen skickar den server som är särskilt konfigurerad text som skickar en fjärrfil, dvs. en fil på en fjärrserver som kontrolleras av angriparen, till ett skripts include -instruktion. |
| Sessionsfixering | En angripare utnyttjar en säkerhetsrisk för webbappen som gör att angriparen kan hämta ett giltigt sessions-ID. Angriparen lurar en användare att autentisera en ny session med det ID:t. Angriparen kapar sedan den här användar verifierade sessionen. |
| SQL-inmatning | I ett webbformulärfält infogar angriparen (eller "matar in") text som är särskilt konfigurerad för att lura servern att köra SQL-kommandon. Med de här kommandona kan angriparen komma åt känsliga data, infoga, uppdatera eller ta bort data eller köra SQL-åtgärder. |
Alla kryphål som anges i föregående tabell är bara möjliga när servern litar på de indata som den tar emot. Det skulle vara svårt och tidskrävande att skriva kod som söker efter och sanerar just dessa kryphål. Endast en liten del av de möjliga kryphål som en webbapp kan möta representeras i föregående tabell. Azure Web Application Firewall är utformat för att förhindra dessa attacker och många fler.
Sanera indata
Hoten mot moderna webbappar är varierande och sofistikerade. I de flesta fall är det dock möjligt att webbappen implicit litar på de indata som den tar emot.
Tänk dig till exempel ett webbformulär som gör att en behörig webbappanvändare kan logga in på användarens konto. Formuläret består av bara tre element:
- Textruta för användarnamn
- En textruta för lösenord
- Knappen Logga in
När en behörig användare fyller i formuläret och väljer Logga in lagrar ett webbappskript användarnamnet och lösenordet i variabler. Anta att dessa variabler heter userName respektive userPassword. Skriptet skulle sedan köra följande instruktion:
sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + userPassword + "'"
Om användarnamnet till exempel är support och lösenordet är 1234ABCDhar variabeln sql följande värde:
SELECT * FROM users WHERE username='support' AND password='1234ABCD'
Webbappen kör den här SQL-instruktionen. Om en post returneras från frågan loggar webbappen in användaren.
Anta nu att en angripare går in admin'-- i fältet Användarnamn och lämnar fältet Lösenord tomt. I det här fallet är här den resulterande SQL-instruktionen:
SELECT * FROM users WHERE username='admin'--' AND password=''
På många SQL-system markerar de dubbla bindestrecken (--) början på en kommentar. Allt efter -- ignoreras, så den tidigare instruktionen motsvarar följande kod:
SELECT * FROM users WHERE username='admin'
Förutsatt att det finns en användare med namnet adminloggar det här kommandot in angriparen som administratörsanvändare, ett allvarligt brott!
Föregående exempel är en instans av en exploatering som kallas SQL-inmatning. Angripare kan dra nytta av SQL-inmatning och andra kryphål i webbappar som litar på alla indata.
Azure Web Application Firewall skapar en barriär av icke-förtroende mellan en webbapp och dess användarindata. Azure Web Application Firewall förutsätter att alla indata är potentiellt skadliga, så att indata saneras .
Att rensa indata innebär olika saker beroende på kontexten. Om du till exempel rensar indata kan det innebära att tydligt farliga textelement tas bort, till exempel SQL-kommentarsindikatorer. Hur sanitering än sker är resultatet indata som inte kan skada webbappen eller dess serverdelsdata.