Wat is CRLF?

wanneer een browser een verzoek naar een webserver verzendt, antwoordt de webserver terug met een antwoord dat zowel de HTTP response headers als de werkelijke inhoud van de website bevat, d.w.z. De response body. De HTTP headers en de HTML response (de inhoud van de website) worden gescheiden door een specifieke combinatie van speciale tekens, namelijk een carriage return en een line feed. Kortom ze zijn ook bekend als CRLF.

De webserver gebruikt de CRLF om te begrijpen wanneer een nieuwe HTTP-header begint en een andere eindigt. De CRLF kan een webtoepassing of gebruiker ook vertellen dat een nieuwe regel begint in een bestand of in een tekstblok. De CRLF-tekens zijn een standaard HTTP / 1.1-bericht, dus het wordt gebruikt door elk type webserver, inclusief Apache, Microsoft IIS en alle anderen.

Wat is de CRLF injectie kwetsbaarheid?

in een CRLF-vulnerability attack voegt de aanvaller zowel de carriage return-als de linefeed-tekens in de gebruikersinvoer toe om de server, de webtoepassing of de gebruiker te laten denken dat een object is beëindigd en een ander is gestart. Als zodanig de CRLF sequenties zijn geen kwaadaardige tekens, maar ze kunnen worden gebruikt voor kwaadaardige bedoelingen, voor HTTP response splitsen etc.

CRLF-injectie in webtoepassingen

in webtoepassingen kan een CRLF-injectie ernstige gevolgen hebben, afhankelijk van wat de toepassing met afzonderlijke items doet. Impact kan variëren van informatieverschaffing tot het uitvoeren van code, een directe impact webapplicatie beveiligingsprobleem. In feite een CRLF injectie aanval kan zeer ernstige gevolgen hebben op een webapplicatie, hoewel het nooit werd vermeld in de OWASP Top 10 lijst. Het is bijvoorbeeld ook mogelijk om logbestanden te manipuleren in een admin panel zoals uitgelegd in het onderstaande voorbeeld.

een voorbeeld van CRLF-injectie in een logbestand

stel je een logbestand voor in een adminpaneel met het uitvoerstreampatroon van IP – Time-bezocht pad, zoals het onderstaande:

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

als een aanvaller in staat is om de CRLF-tekens in de HTTP-aanvraag te injecteren, is hij in staat om de uitvoerstroom te veranderen en de loggegevens te faken. Hij kan het antwoord van de webs-toepassing wijzigen in iets als het volgende:

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

de %0d en %0a zijn de url-gecodeerde vormen van CR en LF. Daarom zou de log entries er zo uitzien nadat de aanvaller die tekens heeft ingevoegd en de toepassing het weergeeft:

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

daarom kan de aanvaller door gebruik te maken van een CRLF-injectie kwetsbaarheid in het logbestand nep-vermeldingen in het logbestand om zijn eigen kwaadaardige acties te verdoezelen. De aanvaller doet letterlijk pagina hijacking en het aanpassen van de reactie. Stel je bijvoorbeeld een scenario voor waarin de aanvaller het admin wachtwoord heeft en de restrictedaction parameter uitvoert, die alleen door een admin kan worden gebruikt.

het probleem is dat als de beheerder merkt dat een onbekend IP de restrictedaction parameter gebruikt, zal merken dat er iets mis is. Echter, aangezien het nu lijkt alsof het commando is uitgegeven door de localhost (en dus waarschijnlijk door iemand die toegang heeft tot de server, zoals een admin) het ziet er niet verdacht uit.

het hele deel van de query dat begint met %0d%0a zal door de server als één parameter worden behandeld. Daarna is er een andere & met de parameter restrictedaction die door de server als een andere parameter wordt ontleed. In feite zou dit dezelfde query zijn als:

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

HTTP Response Splitting

Description

aangezien de header van een HTTP-antwoord en de inhoud ervan gescheiden zijn door CRLF-tekens kan een aanvaller proberen deze te injecteren. Een combinatie van CRLFCRLF zal de browser vertellen dat de header eindigt en de body begint. Dat betekent dat hij nu in staat is om gegevens te schrijven in het antwoord lichaam waar de html-code is opgeslagen. Dit kan leiden tot een cross-site scripting kwetsbaarheid.

een voorbeeld van HTTP Response Splitting die leidt naar XSS

stel je een toepassing voor die een aangepaste header instelt, bijvoorbeeld:

X-Your-Name: Bob

de waarde van de header wordt ingesteld via een get parameter genaamd”name”. Als er geen URL-codering is en de waarde direct wordt weergegeven in de koptekst is het mogelijk voor een aanvaller om de bovengenoemde combinatie van CRLFCRLF in te voegen om de browser te vertellen dat de aanvraag body begint. Op die manier kan hij gegevens zoals XSS payload invoegen, bijvoorbeeld:

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

het bovenstaande zal een waarschuwingsvenster tonen in de context van het aangevallen domein.

HTTP-Headerinjectie

Description

door gebruik te maken van een CRLF-injectie kan een aanvaller ook HTTP-headers invoegen die kunnen worden gebruikt om beveiligingsmechanismen zoals het XSS-filter van een browser of hetzelfde origin-beleid te verslaan. Hierdoor kan de aanvaller gevoelige informatie zoals CSRF tokens te krijgen. Hij kan ook cookies instellen die kunnen worden uitgebuit door het slachtoffer in te loggen in het account van de aanvaller of door gebruik te maken van anderszins onontgonnen cross-site scripting (XSS) kwetsbaarheden.

een voorbeeld van HTTP Header injectie om gevoelige gegevens te extraheren

als een aanvaller in staat is om de HTTP headers te injecteren die CORS activeren (cross Origin Resource Sharing), kan hij javascript gebruiken om toegang te krijgen tot bronnen die anders beschermd zijn door SOP (Same Origin Policy), waardoor sites van verschillende oorsprong geen toegang tot elkaar krijgen.

effecten van de kwetsbaarheid voor CRLF-injectie

de impact van CRLF-injecties varieert en omvat ook alle effecten van cross-site Scripting tot informatieverschaffing. Het kan ook bepaalde beveiligingsbeperkingen zoals XSS-Filters en hetzelfde Origin-beleid in browsers van het slachtoffer deactiveren, waardoor ze vatbaar zijn voor kwaadaardige aanvallen.

hoe CRLF / HTTP-Headerinjecties in webtoepassingen te voorkomen

de beste preventietechniek is het niet gebruiken van gebruikers die direct in responskoppen worden ingevoerd. Als dat niet mogelijk is, moet je altijd een functie gebruiken om de CRLF speciale tekens te coderen. Een andere goede webapplicatie beveiliging beste praktijk is om uw programmeertaal te updaten naar een versie die CR en LF niet toestaat om te worden geïnjecteerd binnen functies die HTTP headers instellen.

Kwetsbaarheid Classificatie en Ernst van de Tabel