9 populära typer av attacker för webbapplikationsinjektion

Problemet med webbapplikationer är att de öppet exponeras för miljarder internetanvändare, av vilka många kommer att vilja bryta sina säkerhetsåtgärder – oavsett orsaken.

I början av Internet var en av de vanligaste attackmetoderna grundläggande, enkel brute force. Bots utförde vanligtvis dessa attacker – eller personer med mycket ledigt – som försökte miljontals kombinationer av användarnamn och lösenord tills de hittade ett som skulle ge åtkomst till målapplikationen.

Brute force-attacker är inte längre ett hot, tack vare lösenordspolicyer, begränsade inloggningsförsök och captchas. Men cyberbrottslingar älskar att upptäcka nya bedrifter och att använda dem för att utföra nya typer av attacker. För länge sedan upptäckte de att textfält på applikationer eller webbsidor kunde utnyttjas genom att skriva in – eller injicera – oväntad text i dem som skulle tvinga applikationen att göra något den inte var tänkt att göra. På det sättet kom de så kallade injektionsattackerna in på platsen.

Injektionsattacker kan användas inte bara för att logga in på en applikation utan att känna till användarnamn och lösenord, utan också för att avslöja privat, konfidentiell eller känslig information, eller till och med för att kapa en hel server. Det är därför dessa attacker inte bara är ett hot mot webbapplikationer, utan också mot de användare vars data finns på dessa applikationer, och i värsta fall mot andra anslutna applikationer och tjänster.

Kodinjektion

Kodinjektion är en av de vanligaste typerna av injektionsattacker. Om angripare känner till programmeringsspråket, ramverket, databasen eller operativsystemet som används av en webbapplikation, kan de injicera kod via textinmatningsfält för att tvinga webbservern att göra vad de vill.

Dessa typer av injektionsattacker är möjliga på applikationer som saknar indatavalidering. Om ett textinmatningsfält låter användare ange vad de vill, är programmet potentiellt exploateringsbart. För att förhindra dessa attacker måste applikationen begränsa så mycket som möjligt att indataanvändare tillåts komma in.

Till exempel måste den begränsa mängden förväntad data, kontrollera dataformatet innan det accepteras och begränsa mängden tillåtna tecken.

Kodinjektionssårbarheterna kan vara lätta att hitta, bara genom att testa textinmatningen i en webbapplikation med olika typer av innehåll. När de hittas är sårbarheterna måttligt svåra att utnyttja. Men när en angripare lyckas utnyttja en av dessa sårbarheter kan konsekvenserna inkludera förlust av konfidentialitet, integritet, tillgänglighet eller applikationsfunktionalitet.

SQL-injektion

På ett liknande sätt som kodinjektion infogar denna attack ett SQL-skript – det språk som används av de flesta databaser för att utföra frågeoperationer – i ett textinmatningsfält. Skriptet skickas till applikationen som kör det direkt på sin databas. Som ett resultat kan angriparen passera en inloggningsskärm eller göra farligare saker, som att läsa känslig data direkt från databasen, ändra eller förstöra databasdata eller utföra administratörsåtgärder på databasen.

PHP- och ASP-applikationer är benägna att attackera SQL-injektioner på grund av dess äldre funktionella gränssnitt. J2EE- och ASP.Net-appar är vanligtvis mer skyddade mot dessa attacker. När en SQL-injektionssårbarhet hittas – och de skulle lätt kunna hittas – kommer omfattningen av de potentiella attackerna endast att begränsas av angriparens skicklighet och fantasi. Således är effekten av en SQL-injektionsattack utan tvekan hög.

Kommando injektion

Dessa attacker är också möjliga, främst på grund av otillräcklig indatavalidering. De skiljer sig från kodinjektionsattacker genom att angriparen infogar systemkommandon istället för bitar av programmeringskod eller skript. Därför behöver hackaren inte känna till det programmeringsspråk som programmet är baserat på eller språket som används av databasen. Men de måste känna till operativsystemet som används av värdservern.

De infogade systemkommandona exekveras av värdoperativsystemet med privilegierna för applikationen, vilket skulle kunna göra det möjligt att exponera innehållet i godtyckliga filer som finns på servern, för att visa katalogstrukturen för en server, för att ändra användarlösenord, 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.

Skripting på flera webbplatser

Närhelst ett program infogar indata från en användare i utdata som det genererar, utan att validera eller koda det, ger det en angripare möjlighet att skicka skadlig kod till en annan slutanvändare. Cross-Site Scripting (XSS)-attacker utnyttjar dessa möjligheter att injicera skadliga skript på betrodda webbplatser, som i slutändan skickas till andra användare av applikationen, som blir 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 låta den komma åt sessionstokens, cookies eller 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å olika kategorier: lagrade och reflekterade.

I lagrade XSS-attacker finns det skadliga skriptet permanent på målservern, i ett meddelandeforum, i en databas, i en besökslogg, etc. Offret får det när dess webbläsare begär den lagrade informationen. I reflekterade XSS-attacker återspeglas 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 som tillhandahålls av 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-data är uppbyggd, och sedan attackerar de igen för att komma åt dessa data.

XPath är ett standardspråk med vilket du, precis som SQL, kan specificera de attribut 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 data ska matcha. Genom att skicka felaktig indata kan mönstret förvandlas till en operation som angriparen vill tillämpa på data.

Till skillnad från vad som händer med SQL, i XPath, finns det inga olika versioner. Detta innebär att XPath-injektion kan göras på vilken webbapplikation som helst som använder XML-data, oavsett implementering. Det betyder också att attacken kan automatiseras; därför, till skillnad från SQL-injektion, har den potential att avfyras mot ett godtyckligt antal mål.

Mail 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 starkt skydd mot attacker, som det skulle vara fallet med de flesta webbservrar, och därför kan de vara mer exploaterbara. Genom att gå in via en e-postserver kan angripare undvika restriktioner som captchas, ett begränsat antal förfrågningar, etc.

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å angriparnas förfrågningar, vilket gör att de till exempel kan åsidosätta serverbegränsningar och använda dess tjänster för att skicka skräppost.

IMAP-injektion kan huvudsakligen göras på webbmailapplikationer, med utnyttjande av funktionen för meddelandeläsning. I dessa fall kan attacken utföras genom att helt enkelt ange, i adressfältet i en webbläsare, en URL med de injicerade kommandona.

CRLF-injektion

Infogningen av vagnretur och radmatningstecken – en kombination som kallas CRLF – i inmatningsfält för webbformulär representerar 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.

Till exempel kan infogningen av en CRLF i en HTTP-förfrågan, följt av viss HTML-kod, skicka anpassade webbsidor till besökarna på en webbplats.

Denna attack kan utföras på sårbara webbapplikationer som inte tillämpar korrekt filtrering på användarinmatningen. Denna sårbarhet öppnar dörren för andra typer av injektionsattacker, såsom XSS och kodinjektion, och kan också härledas till att en webbplats kapas.

Host Header-injektion

På servrar som är värd för många webbplatser eller webbapplikationer blir värdhuvudet nödvändigt för att avgöra vilken av de inhemska webbplatserna eller webbapplikationerna – var och en av dem känd som en virtuell värd – som ska behandla en inkommande begäran. Värdet på rubriken talar om för servern till vilken av de virtuella värdarna som ska skicka en begäran. När servern tar emot en ogiltig värdhuvud skickar den vanligtvis den till den första virtuella värden i listan. Detta utgör 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 relaterat till PHP-applikationer, även om det också kan göras med andra webbutvecklingstekniker. Hostheader-attacker fungerar som möjliggörare för andra typer av attacker, till exempel webbcacheförgiftning. Dess konsekvenser kan inkludera att angriparna utför känsliga operationer, till exempel lösenordsåterställningar.

LDAP-injektion

LDAP är ett protokoll utformat för att underlätta sökning av resurser (enheter, filer, andra användare) i ett nätverk. Det är mycket användbart för intranät, och 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ändning av speciella kontrolltecken som påverkar dess kontroll. Angripare kan eventuellt ändra det avsedda beteendet för en LDAP-fråga om de kan infoga kontrolltecken i den.

Återigen, rotproblemet som tillåter LDAP-injektionsattacker är felaktigt validerad användarinmatning. Om texten som en användare skickar till ett program används som en del av en LDAP-fråga utan att rensa den, kan frågan sluta med 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örhindrar injektionsattacker

Som vi såg i den här artikeln är alla injektionsattacker riktade mot servrar och applikationer med öppen åtkomst till alla internetanvändare. Ansvaret för att förhindra dessa attacker är fördelat på applikationsutvecklare och serveradministratörer.