Hvad er CRLF?

når en internetserver sender en anmodning til en internetserver, svarer internetserveren tilbage med et svar, der både indeholder HTTP-svaroverskrifterne og det faktiske hjemmesideindhold, dvs.svarlegemet. HTTP-overskrifterne og HTML-svaret (hjemmesidens indhold) adskilles af en specifik kombination af specialtegn, nemlig en vognretur og et linjefeed. Kort sagt er de også kendt som CRLF.internetserveren bruger CRLF til at forstå, hvornår Ny HTTP-overskrift begynder, og en anden slutter. CRLF kan også fortælle en internetapplikation eller bruger, at en ny linje begynder i en fil eller i en tekstblok. CRLF-tegnene er en standard HTTP / 1.1-meddelelse, så den bruges af enhver type internetserver, herunder Apache, Microsoft IIS og alle andre.

Hvad er CRLF injektion sårbarhed?

i et CRLF-sårbarhedsangreb indsætter angriberen både vognretur og linefeed-tegn i brugerinput for at narre serveren, internetapplikationen eller brugeren til at tro, at et objekt afsluttes, og et andet er startet. Som sådan er CRLF-sekvenserne ikke ondsindede tegn, men de kan bruges til ondsindet hensigt, til HTTP-responsopdeling osv.

CRLF-injektion i applikationer

i applikationer kan en CRLF-injektion have alvorlige virkninger, afhængigt af hvad applikationen gør med enkelte emner. Virkningerne kan variere fra videregivelse af oplysninger til udførelse af kode, en direkte indvirkning på sikkerhedssårbarheden for internetapplikationer. Faktisk kan et CRLF-injektionsangreb have meget alvorlige konsekvenser for en internetapplikation, selvom det aldrig blev opført på top 10-listen. For eksempel er det også muligt at manipulere logfiler i et admin panel som forklaret i nedenstående eksempel.

et eksempel på CRLF-injektion i en logfil

Forestil dig en logfil i et adminpanel med outputstrømmønsteret for IP – tid – besøgt sti, såsom nedenstående:

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

Hvis en angriber er i stand til at injicere CRLF-tegnene i HTTP-anmodningen, er han i stand til at ændre outputstrømmen og falske logposterne. Han kan ændre svaret fra baneprogrammet til noget som nedenstående:

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

%0D og %0a er url-kodede former for CR og LF. Derfor log poster ville se sådan ud efter angriberen indsat disse tegn og programmet viser det:

IP – Time – besøgte sti

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

derfor ved at udnytte en CRLF injektion sårbarhed angriberen kan falske poster i logfilen for at tilsløre sine egne ondsindede handlinger. Angriberen er bogstaveligt talt gør side kapring og ændre svaret. Forestil dig for eksempel et scenarie, hvor angriberen har administratoradgangskoden og udførte parameteren restrictedaction, som kun kan bruges af en administrator.

problemet er, at hvis administratoren bemærker, at en ukendt IP brugte den begrænsede handlingsparameter, vil bemærke, at noget er galt. Men da det nu ser ud til, at kommandoen blev udstedt af localhost (og derfor sandsynligvis af en person, der har adgang til serveren, som en administrator), ser den ikke mistænkelig ud.

hele delen af forespørgslen, der begynder med %0D%0a, håndteres af serveren som en parameter. Derefter er der en anden & med parameteren restrictedactionsom vil blive analyseret af serveren som en anden parameter. Effektivt ville dette være den samme forespørgsel som:

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

HTTP Response Splitting

Description

da overskriften på et HTTP-svar og dets krop er adskilt af CRLF-tegn, kan en angriber forsøge at injicere dem. En kombination af CRLFCRLF fortæller bro.ser, at overskriften slutter, og kroppen begynder. Det betyder, at han nu er i stand til at skrive data inde i svarlegemet, hvor html-koden er gemt. Dette kan føre til en cross-site Scripting sårbarhed.

et eksempel på opdeling af HTTP-svar, der fører til HSS

Forestil dig et program, der f. eks. angiver en brugerdefineret overskrift:

X-Your-Name: Bob

værdien af overskriften indstilles via en get-parameter kaldet “navn”. Hvis ingen URL-kodning er på plads, og værdien reflekteres direkte inde i overskriften, kan det være muligt for en angriber at indsætte ovennævnte kombination af CRLFCRLF for at fortælle bro.sereren, at anmodningsorganet begynder. Payload, for eksempel:

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

ovenstående viser et advarselsvindue i forbindelse med det angrebne domæne.

http Headerinjektion

beskrivelse

ved at udnytte en CRLF-injektion kan en angriber også indsætte HTTP-overskrifter, som kan bruges til at besejre sikkerhedsmekanismer som f.eks. Dette gør det muligt for angriberen at få følsomme oplysninger som CSRF-tokens. Han kan også indstille cookies, der kan udnyttes ved at logge offeret på angriberens konto eller ved at udnytte ellers uudnyttelige Cross-site scripting-sårbarheder.

et eksempel på http-Headerinjektion til at udtrække følsomme data

Hvis en hacker er i stand til at injicere HTTP-headere, der aktiverer CORS (Cross Origin Resource Sharing), kan han bruge javascript til at få adgang til ressourcer, der ellers er beskyttet af SOP (Same Origin Policy), som forhindrer sider fra forskellige oprindelser i at få adgang til hinanden.

virkningerne af CRLF-injektionssårbarheden

virkningen af CRLF-injektioner varierer og inkluderer også alle virkningerne af Cross-site Scripting til informationsafsløring. Det kan også deaktivere visse sikkerhedsrestriktioner som f.eks.

Sådan forhindres CRLF / HTTP Headerinjektioner i internetapplikationer

den bedste forebyggelsesteknik er at ikke bruge brugernes input direkte inde i responsoverskrifter. Hvis det ikke er muligt, skal du altid bruge en funktion til at kode CRLF-specialtegnene. En anden god bedste praksis er at opdatere dit programmeringssprog til en version, der ikke tillader CR og LF at blive injiceret i funktioner, der indstiller HTTP-overskrifter.

Sårbarhedsklassificering og sværhedsgrad