Vad är CRLF?

När en webbläsare skickar en begäran till en webbserver svarar webbservern tillbaka med ett svar som innehåller både HTTP-svarshuvudena och det faktiska webbplatsinnehållet, dvs. svarkroppen. HTTP-rubrikerna och HTML-svaret (webbplatsens innehåll) separeras av en specifik kombination av specialtecken, nämligen en vagnretur och en radmatning. Kort sagt är de också kända som CRLF.

webbservern använder CRLF för att förstå när Ny HTTP-rubrik börjar och en annan slutar. CRLF kan också berätta för en webbapplikation eller användare att en ny rad börjar i en fil eller i ett textblock. CRLF-tecknen är ett standard HTTP / 1.1-meddelande, så det används av alla typer av webbserver, inklusive Apache, Microsoft IIS och alla andra.

Vad är CRLF injektion sårbarhet?

i en CRLF-injektionssårbarhetsattack infogar angriparen både vagnretur och linefeed-tecken i användarinmatning för att lura servern, webbapplikationen eller användaren att tro att ett objekt avslutas och ett annat har startat. Som sådan är CRLF-sekvenserna inte skadliga tecken,men de kan användas för skadlig avsikt, för HTTP-svarsuppdelning etc.

CRLF injektion i webbapplikationer

i webbapplikationer en CRLF injektion kan ha allvarliga effekter, beroende på vad programmet gör med enstaka objekt. Effekter kan sträcka sig från informationsutlämnande till kodkörning, en direkt inverkan på webbapplikationssäkerhetsproblem. I själva verket kan en CRLF-injektionsattack få mycket allvarliga konsekvenser för en webbapplikation, även om den aldrig listades i OWASP Top 10-listan. Till exempel är det också möjligt att manipulera loggfiler i en adminpanel som förklaras i exemplet nedan.

ett exempel på CRLF-injektion i en loggfil

Föreställ dig en loggfil i en adminpanel med utgångsströmmönstret för IP – Tidsbesökt sökväg, till exempel nedan:

123.123.123.123 - 08:15 - /index.php?page=home

om en angripare kan injicera CRLF-tecknen i HTTP-begäran kan han ändra utgångsströmmen och förfalska loggposterna. Han kan ändra svaret från webs-applikationen till något som nedan:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

%0d och %0a är url-kodade former av CR och LF. Därför loggposter skulle se ut så här efter angriparen infogat dessa tecken och programmet visar det:

IP – Time-Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

därför genom att utnyttja en CRLF injektion sårbarhet angriparen kan falska poster i loggfilen för att fördunkla sina egna skadliga handlingar. Angriparen gör bokstavligen sidkapning och ändrar svaret. Föreställ dig till exempel ett scenario där angriparen har administratörslösenordet och exekverat parametern restrictedaction, som endast kan användas av en administratör.

problemet är att om administratören märker att en okänd IP använde parametern restrictedaction, kommer att märka att något är fel. Men eftersom det nu ser ut som att kommandot utfärdades av localhost (och därför förmodligen av någon som har tillgång till servern, som en admin) ser det inte misstänkt ut.

hela delen av frågan som börjar med %0d%0a hanteras av servern som en parameter. Därefter finns det en annan & med parametern restrictedactionsom kommer att analyseras av servern som en annan parameter. I praktiken skulle detta vara samma fråga som:

/index.php?page=home&restrictedaction=edit

HTTP Response Splitting

beskrivning

eftersom rubriken för ett HTTP-svar och dess kropp separeras av CRLF-tecken kan en angripare försöka injicera dem. En kombination av CRLFCRLF kommer att berätta för webbläsaren att rubriken slutar och kroppen börjar. Det betyder att han nu kan skriva data i svarskroppen där html-koden lagras. Detta kan leda till en serveröverskridande skriptsårbarhet.

ett exempel på HTTP-Svarsuppdelning som leder till XSS

Föreställ dig ett program som ställer in en anpassad rubrik, till exempel:

X-Your-Name: Bob

värdet på rubriken ställs in via en get-parameter som heter ”namn”. Om ingen URL-kodning finns på plats och värdet reflekteras direkt inuti rubriken kan det vara möjligt för en angripare att infoga ovan nämnda kombination av CRLFCRLF för att berätta för webbläsaren att begäran börjar. På så sätt kan han infoga data som XSS nyttolast, till exempel:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

ovanstående visar ett varningsfönster i samband med den attackerade domänen.

HTTP Header Injection

beskrivning

genom att utnyttja en CRLF-injektion kan en angripare också infoga HTTP-rubriker som kan användas för att besegra säkerhetsmekanismer som en webbläsares XSS-filter eller samma ursprungspolicy. Detta gör det möjligt för angriparen att få känslig information som CSRF-tokens. Han kan också ställa in cookies som kan utnyttjas genom att logga offret på angriparens konto eller genom att utnyttja på annat sätt oexploaterbara sårbarheter för cross-site scripting (XSS).

ett exempel på HTTP Header Injection för att extrahera känsliga data

om en angripare kan injicera HTTP-rubriker som aktiverar CORS( Cross Origin Resource Sharing), kan han använda javascript för att komma åt resurser som annars skyddas av SOP (samma Origin Policy) som förhindrar webbplatser från olika ursprung för att komma åt varandra.

effekterna av CRLF-Injektionssårbarheten

effekterna av CRLF-injektioner varierar och inkluderar också alla effekter av skript över flera platser till informationsutlämnande. Det kan också inaktivera vissa säkerhetsbegränsningar som XSS-filter och samma Ursprungspolicy i offrets webbläsare, vilket gör att de är mottagliga för skadliga attacker.

hur man förhindrar CRLF/HTTP Header-injektioner i webbapplikationer

den bästa förebyggande tekniken är att inte använda användarnas inmatning direkt i svarhuvuden. Om det inte är möjligt bör du alltid använda en funktion för att koda CRLF-specialtecknen. En annan bra webbapplikationssäkerhet är att uppdatera ditt programmeringsspråk till en version som inte tillåter CR och LF att injiceras i funktioner som ställer in HTTP-rubriker.

sårbarhet klassificering och svårighetsgrad tabell