Webbapplikationers utmaning ligger i deras globala tillgänglighet för miljarder internetanvändare, där en betydande del kan försöka kompromettera säkerhetsåtgärderna, oavsett deras motiv.
I internets tidiga skede var en vanlig attackmetod den enkla brute force-attacken. Automatiserade verktyg, ofta kallade botar, eller individer med gott om tid, testade miljontals olika kombinationer av användarnamn och lösenord tills de hittade en kombination som gav dem tillträde till den aktuella applikationen.
Numera är brute force-attacker inte längre ett lika stort hot tack vare införandet av starkare lösenordspolicyer, begränsade inloggningsförsök samt captchas. Trots det fortsätter cyberkriminella att söka efter och utnyttja nya sårbarheter för att lansera nya typer av attacker. Det var inte länge sedan de upptäckte att textfält i applikationer eller webbsidor kan manipuleras genom att mata in, eller injicera, oönskad text. Detta tvingar applikationen att agera på ett sätt som inte var avsett. På så sätt uppstod injektionsattacker.
Injektionsattacker kan användas inte bara för att logga in på en applikation utan att ha tillgång till användarnamn och lösenord, utan också för att avslöja privat, konfidentiell eller känslig data, eller till och med för att ta kontroll över en hel server. Därför utgör dessa attacker inte bara en fara för webbapplikationer, utan också för de användare vars information finns lagrad i dessa applikationer. I värsta fall kan de även påverka andra anslutna applikationer och tjänster.
Kod Injektion
Kodinjektion är en av de vanligaste varianterna av injektionsattacker. Om en angripare har kunskap om programmeringsspråket, ramverket, databasen eller operativsystemet som en webbapplikation använder, kan de injicera kod via textinmatningsfält. På detta sätt kan de tvinga webbservern att utföra oönskade operationer.
Denna typ av injektionsattack är möjlig i applikationer som saknar korrekt indatavalidering. Om ett textinmatningsfält tillåter användare att ange vilken information som helst, är applikationen potentiellt sårbar. För att skydda sig mot denna typ av attack måste applikationen begränsa typen av indata som användare kan mata in så mycket som möjligt.
Exempelvis bör applikationen begränsa mängden data som förväntas, kontrollera datans format innan den accepteras och begränsa antalet tecken som tillåts.
Kodinjektionssårbarheter kan vara enkla att identifiera genom att testa textinmatningen i en webbapplikation med olika typer av innehåll. När en sådan sårbarhet väl upptäckts, är den relativt enkel att utnyttja. Om en angripare lyckas utnyttja sårbarheten kan konsekvenserna inkludera förlust av konfidentialitet, integritet, tillgänglighet eller applikationens funktionalitet.
SQL-injektion
I likhet med kodinjektion, involverar denna attackmetod införandet av ett SQL-skript i ett textinmatningsfält. SQL är det språk som används av de flesta databaser för att utföra frågeoperationer. Skriptet skickas till applikationen som i sin tur kör det direkt mot databasen. På detta sätt kan en angripare ta sig förbi en inloggningssida eller utföra mer skadliga handlingar. Det kan exempelvis handla om att direkt läsa känslig information från databasen, ändra eller förstöra databasdata, eller utföra administrativa uppgifter på databasen.
PHP- och ASP-applikationer är särskilt sårbara för SQL-injektionsattacker på grund av deras äldre funktionsgränssnitt. J2EE- och ASP.Net-applikationer är generellt sett bättre skyddade mot dessa attacker. När en SQL-injektionssårbarhet väl upptäckts, vilket kan vara relativt enkelt, är omfattningen av de möjliga attackerna endast begränsad av angriparens skicklighet och fantasi. Därför är effekten av en SQL-injektionsattack ofta mycket stor.
Kommandoinjektion
Även dessa attacker är möjliga, främst på grund av otillräcklig indatavalidering. De skiljer sig från kodinjektionsattacker genom att angriparen injicerar systemkommandon istället för delar av programmeringskod eller skript. Därför behöver angriparen inte ha kunskap om det programmeringsspråk applikationen är baserad på eller det språk som databasen använder. Däremot behöver de känna till operativsystemet som används av värdservern.
De injicerade systemkommandona körs av värdoperativsystemet med applikationens privilegier. Detta kan potentiellt leda till att innehållet i godtyckliga filer på servern exponeras, att en servers katalogstruktur visas, att användarlösenord kan ändras, bland annat.
Dessa attacker kan förhindras av en systemadministratör genom att begränsa systemåtkomstnivån för de webbapplikationer som körs på en server.
Cross-Site Scripting
Om en applikation infogar indata från en användare i den utdata som den genererar, utan att validera eller koda den, ger det en angripare möjlighet att skicka skadlig kod till en annan användare. Cross-Site Scripting (XSS)-attacker utnyttjar dessa möjligheter för att injicera skadliga skript på betrodda webbplatser. Dessa skript skickas i sin tur till andra användare av applikationen, vilket gör dem till angriparens offer.
Offrens webbläsare kommer att köra det skadliga skriptet utan att veta att det inte ska litas på. Därför kommer webbläsaren att tillåta det att komma åt sessionstokens, cookies eller annan känslig information som lagras av webbläsaren. Om de är korrekt programmerade kan skripten till och med skriva om innehållet i en HTML-fil.
XSS-attacker kan generellt delas in i två kategorier: lagrade och reflekterade.
Vid lagrade XSS-attacker finns det skadliga skriptet permanent på målservern, exempelvis i ett meddelandeforum, i en databas eller i en besökslogg. Offret mottar skriptet när webbläsaren begär den lagrade informationen. Vid reflekterade XSS-attacker reflekteras det skadliga skriptet i ett svar som inkluderar indata som skickas till servern. Detta kan till exempel vara ett felmeddelande eller ett sökresultat.
XPath-injektion
Denna typ av attack är möjlig när en webbapplikation använder information från en användare för att bygga en XPath-fråga för XML-data. Sättet som dessa attacker fungerar på liknar SQL-injektion: angripare skickar felaktig information till applikationen för att ta reda på hur XML-datan är strukturerad. Sedan attackerar de igen för att få tillgång till denna data.
XPath är ett standardspråk som, i likhet med SQL, gör det möjligt att ange de attribut som du vill hitta. För att utföra en fråga på XML-data använder webbapplikationer användarinmatning för att ställa in ett mönster som datan ska matcha. Genom att skicka felaktig indata kan mönstret omvandlas till en operation som angriparen vill tillämpa på datan.
Till skillnad från SQL finns det inga olika versioner av XPath. Detta innebär att XPath-injektion kan utföras på alla webbapplikationer som använder XML-data, oavsett implementering. Det betyder också att attacken kan automatiseras, vilket gör att den, till skillnad från SQL-injektion, potentiellt kan lanseras mot ett stort antal mål.
E-post Kommandoinjektion
Denna attackmetod kan användas för att utnyttja e-postservrar och applikationer som bygger IMAP- eller SMTP-satser med felaktigt validerad användarinmatning. Ibland har IMAP- och SMTP-servrar inte ett lika starkt skydd mot attacker som de flesta webbservrar. Därför kan de vara mer sårbara. Genom att angripa via en e-postserver kan angripare kringgå restriktioner som captchas och begränsade antalet förfrågningar.
För att utnyttja en SMTP-server behöver angripare ett giltigt e-postkonto för att skicka meddelanden med injicerade kommandon. Om servern är sårbar kommer den att svara på angriparens förfrågningar, vilket gör det möjligt för dem att, till exempel, åsidosätta serverbegränsningar och använda dess tjänster för att skicka skräppost.
IMAP-injektion kan främst utföras på webbmailapplikationer genom att utnyttja meddelandeläsningsfunktionen. I dessa fall kan attacken utföras genom att ange en webbadress med de injicerade kommandona i adressfältet i en webbläsare.
CRLF-injektion
Infogningen av vagnretur och radmatningstecken, en kombination som kallas CRLF, i inmatningsfält för webbformulär, utgör en attackmetod som kallas CRLF-injektion. Dessa osynliga tecken indikerar slutet på en rad eller slutet på ett kommando i många traditionella internetprotokoll som HTTP, MIME eller NNTP.
Exempelvis kan infogningen av en CRLF i en HTTP-förfrågan, följt av viss HTML-kod, skicka anpassade webbsidor till besökare på en webbplats.
Denna attack kan utföras på sårbara webbapplikationer som inte har korrekt filtrering av användarinmatning. Denna sårbarhet öppnar dörren för andra typer av injektionsattacker, som XSS och kodinjektion, och kan även leda till att en webbplats kapas.
Host Header-injektion
På servrar som hanterar många webbplatser eller webbapplikationer blir värdhuvudet nödvändigt för att bestämma vilken av de lokala webbplatserna eller webbapplikationerna – var och en känd som en virtuell värd – som ska hantera en inkommande förfrågan. Värdet på rubriken talar om för servern till vilken av de virtuella värdarna som förfrågan ska skickas. När servern tar emot ett ogiltigt värdhuvud skickar den vanligtvis det till den första virtuella värden i listan. Detta skapar en sårbarhet som angripare kan använda för att skicka godtyckliga värdhuvuden till den första virtuella värden på en server.
Manipulering av värdhuvudet är vanligtvis kopplat till PHP-applikationer, även om det även kan utföras med andra tekniker för webbutveckling. Host header-attacker kan underlätta andra typer av attacker, exempelvis webbcacheförgiftning. Konsekvenserna kan omfatta att angripare utför känsliga operationer, som lösenordsåterställningar.
LDAP-injektion
LDAP är ett protokoll som är utformat för att underlätta sökning av resurser, som enheter, filer eller andra användare, i ett nätverk. Det är mycket användbart för intranät. När det används som en del av ett system för enkel inloggning kan det användas för att lagra användarnamn och lösenord. LDAP-frågor involverar användningen av speciella kontrolltecken som påverkar dess styrning. Angripare kan potentiellt ändra det avsedda beteendet för en LDAP-fråga om de lyckas infoga kontrolltecken i den.
Återigen är det grundläggande problemet som möjliggör LDAP-injektionsattacker felaktigt validerad användarinmatning. Om texten som en användare skickar till en applikation används som en del av en LDAP-fråga utan att rensa den, kan frågan resultera i att en lista över alla användare hämtas och visas för en angripare, bara genom att använda en asterisk på rätt plats i en inmatningssträng.
Förebyggande av injektionsattacker
Som vi har sett i den här artikeln, är alla injektionsattacker riktade mot servrar och applikationer som är tillgängliga för alla internetanvändare. Ansvaret för att förhindra dessa attacker delas mellan applikationsutvecklare och serveradministratörer.
Applikationsutvecklare måste vara medvetna om riskerna med felaktig validering av användarinmatning och lära sig bästa praxis för att sanera användarinmatning i förebyggande syfte. Serveradministratörer måste regelbundet granska sina system för att upptäcka sårbarheter och åtgärda dem så snabbt som möjligt. Det finns många metoder för att utföra dessa granskningar, antingen på begäran eller automatiskt.