Hva ER CRLF?

når en nettleser sender en forespørsel til en webserver, svarer webserveren tilbake med et svar som inneholder BÅDE HTTP-svarhodene og det faktiske innholdet på nettstedet, dvs. responsteksten. HTTP-overskriftene og HTML-svaret (nettstedets innhold) er adskilt av en bestemt kombinasjon av spesialtegn, nemlig en linjeskift og en linjefeed. For kort er de også kjent SOM CRLF.

webserveren bruker CRLF til å forstå når ny HTTP-header begynner og en annen slutter. CRLF kan også fortelle en webapplikasjon eller bruker at en ny linje begynner i en fil eller i en tekstblokk. CRLF-tegnene er en STANDARD HTTP / 1.1-melding, så den brukes av alle typer webserver, inkludert Apache, Microsoft Iis og alle andre.

Hva Er Sårbarheten FOR Crlf-Injeksjon?

i ET SÅRBARHETSANGREP med CRLF-injeksjon setter angriperen inn både linjeskift-og linjefeed-tegnene i brukerinndata for å lure serveren, webapplikasjonen eller brukeren til å tro at et objekt er avsluttet og et annet har startet. SOM sådan ER CRLF-sekvensene ikke ondsinnede tegn, men de kan brukes til ondsinnet hensikt, FOR HTTP-respons splitting etc.

CRLF-injeksjon i webapplikasjoner

I webapplikasjoner kan EN CRLF-injeksjon ha alvorlige konsekvenser, avhengig av hva applikasjonen gjør med enkeltelementer. Virkninger kan variere fra avsløring av informasjon til kjøring av kode, et sikkerhetsproblem med direkte innvirkning på webapplikasjoner. FAKTISK KAN ET CRLF-injeksjonsangrep ha svært alvorlige konsekvenser på en webapplikasjon, selv om DEN aldri ble oppført PÅ OWASP Top 10-listen. For eksempel er det også mulig å manipulere loggfiler i et administrasjonspanel som forklart i eksemplet nedenfor.

et eksempel PÅ CRLF-Injeksjon i en loggfil

Tenk deg en loggfil i et administrasjonspanel med utgangsstrømmønsteret FOR IP-Time-Besøkt Bane, for eksempel nedenfor:

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

hvis en angriper kan injisere CRLF-tegnene i HTTP-forespørselen, kan han endre utgangsstrømmen og forfalske loggoppføringene. Han kan endre svaret fra webs-applikasjonen til noe som nedenfor:

/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 vil loggoppføringene se slik ut etter at angriperen har satt inn disse tegnene, og programmet viser 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

ved å utnytte ET sikkerhetsproblem MED CRLF-injeksjon kan angriperen derfor forfalske oppføringer i loggfilen for å forvirre sine egne ondsinnede handlinger. Angriperen gjør bokstavelig talt side kapring og endrer svaret. Tenk deg for eksempel et scenario der angriperen har administratorpassordet og utført parameteren restrictedaction, som bare kan brukes av en administrator.

problemet er at hvis administratoren merker at en ukjent IP brukte parameteren restrictedaction, vil du legge merke til at noe er galt. Men siden nå ser det ut til at kommandoen ble utstedt av localhost (og derfor sannsynligvis av noen som har tilgang til serveren, som en admin), ser det ikke mistenkelig ut.

hele delen av spørringen som begynner med % 0d % 0a vil bli håndtert av serveren som en parameter. Etter det er det en annen & med parameteren restrictedactionsom vil bli analysert av serveren som en annen parameter. Dette ville være det samme spørsmålet som:

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

Http Respons Splitting

Beskrivelse

siden overskriften TIL ET HTTP-svar og dets kropp er adskilt av CRLF-tegn, kan en angriper prøve å injisere dem. EN KOMBINASJON AV CRLFCRLF vil fortelle nettleseren at overskriften slutter og kroppen begynner. Det betyr at han nå kan skrive data inne i responsorganet der html-koden er lagret. Dette kan føre til et Sikkerhetsproblem På Tvers av nettsteder.

ET eksempel PÅ HTTP Respons Splitting fører TIL XSS

Tenk deg et program som setter en egendefinert header, for eksempel:

X-Your-Name: Bob

verdien av overskriften er satt via en get-parameter kalt «navn». Hvis INGEN URL-koding er på plass og verdien reflekteres direkte i overskriften, kan det være mulig for en angriper å sette inn OVENNEVNTE KOMBINASJON AV CRLFCRLF for å fortelle nettleseren at forespørselsorganet begynner. På den måten er han i stand til å sette inn data SOM XSS nyttelast, for eksempel:

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

ovennevnte vil vise et varselvindu i sammenheng med angrepet domene.

HTTP Header Injection

Beskrivelse

ved å utnytte EN CRLF-injeksjon kan en angriper også sette INN HTTP-overskrifter som kan brukes til å beseire sikkerhetsmekanismer som EN nettlesers XSS-filter eller samme opprinnelsespolicy. Dette gjør at angriperen kan få sensitiv informasjon som CSRF-tokens. Han kan også sette informasjonskapsler som kan utnyttes ved å logge offeret i angriperens konto eller ved å utnytte ellers uutnyttelige sårbarheter FOR cross-site scripting (XSS).

et EKSEMPEL PÅ HTTP Header Injection for å trekke ut sensitive data

hvis en angriper kan injisere HTTP-overskriftene som aktiverer CORS (Cross Origin Resource Sharing), kan han bruke javascript for å få tilgang til ressurser som ellers er beskyttet AV SOP (Same Origin Policy) som forhindrer nettsteder fra forskjellige opprinnelser til å få tilgang til hverandre.

Konsekvensene AV CRLF injeksjon Sårbarhet

virkningen AV CRLF injeksjoner varierer og inkluderer også alle konsekvensene Av Cross-site Scripting til informasjon avsløring. Det kan også deaktivere visse sikkerhetsrestriksjoner SOM XSS-Filtre og Samme Opprinnelsespolicy i offerets nettlesere, slik at de blir utsatt for ondsinnede angrep.

Slik Forhindrer DU CRLF / HTTP Header-Injeksjoner i Webapplikasjoner

den beste forebyggingsteknikken er å ikke bruke brukere som skriver inn direkte i responshoder. Hvis det ikke er mulig, bør du alltid bruke en funksjon for å kode CRLF spesialtegn. En annen god beste praksis for webapplikasjonssikkerhet er å oppdatere programmeringsspråket til en versjon som ikke tillater at CR og LF injiseres i funksjoner som angir HTTP-overskrifter.

Sårbarhet Klassifisering Og Alvorlighetsgrad Tabell