Vichwa maalum vya HTTP

Reading time: 11 minutes

Orodha za maneno & Zana

• https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers
• https://github.com/rfc-st/humble

Vichwa vya Kubadilisha Mahali

Rekebisha chanzo cha IP:

• X-Originating-IP: 127.0.0.1
• X-Forwarded-For: 127.0.0.1
• X-Forwarded: 127.0.0.1
• Forwarded-For: 127.0.0.1
• X-Forwarded-Host: 127.0.0.1
• X-Remote-IP: 127.0.0.1
• X-Remote-Addr: 127.0.0.1
• X-ProxyUser-Ip: 127.0.0.1
• X-Original-URL: 127.0.0.1
• Client-IP: 127.0.0.1
• X-Client-IP: 127.0.0.1
• X-Host: 127.0.0.1
• True-Client-IP: 127.0.0.1
• Cluster-Client-IP: 127.0.0.1
• Via: 1.0 fred, 1.1 127.0.0.1
• Connection: close, X-Forwarded-For (Angalia hop-by-hop headers)

Rekebisha eneo:

• X-Original-URL: /admin/console
• X-Rewrite-URL: /admin/console

Vichwa Hop-by-Hop

Kichwa cha hop-by-hop ni kichwa kilichoundwa kushughulikiwa na proxy inayoshughulikia ombi kwa sasa, badala ya kichwa cha end-to-end.

• Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

• Content-Length: 30
• Transfer-Encoding: chunked

HTTP Request Smuggling / HTTP Desync Attack

Kichwa Expect

Inawezekana kwa client kutuma kichwa Expect: 100-continue na kisha server inaweza kujibu kwa HTTP/1.1 100 Continue ili kuruhusu client kuendelea kutuma body ya ombi. Hata hivyo, baadhi ya proxies hazipendi kichwa hiki.

Matokeo ya kuvutia ya Expect: 100-continue:

• Kutuma ombi la HEAD lenye mwili huku server haikuzingatia kwamba maombi ya HEAD hayana mwili, na ikahifadhi muunganisho wazi hadi ulipomalizika (timeout).
• Seva nyingine zilituma data za ajabu: data za nasibu zilizosomeka kutoka soketi katika response, vitufe vya siri, au hata ikaruhusu kuzuia front-end kuondoa thamani za vichwa.
• Pia ilisababisha desync ya 0.CL kwa sababu backend ilijibu kwa 400 badala ya 100, lakini proxy front-end ilikuwa tayari kutuma body ya ombi la awali; ikalituma na backend ikailichukulia kama ombi jipya.
• Kutuma toleo la Expect: y 100-continue pia kulisababisha desync ya 0.CL.
• Hitilafu sawa ambapo backend ilijibu kwa 404 ilizalisha desync ya CL.0 kwa sababu ombi la uharibifu liliainisha Content-Length, hivyo backend inatuma ombi la uharibifu + bajti za Content-Length za ombi linalofuata (la mwathiriwa); hili linasukuma mfululizo kwa sababu backend inatuma ombi la 404 kwa ombi la uharibifu + majibu ya ombi za mwathiriwa, lakini front-end ilifikiri ombi 1 tu lilitumwa, hivyo jibu la pili limetumwa kwa ombi la pili la mwathiriwa na jibu la hilo likatumwa kwa ombi lifuatalo...

Kwa habari zaidi kuhusu HTTP Request Smuggling angalia:

HTTP Request Smuggling / HTTP Desync Attack

Vichwa vya Cache

Vichwa vya Cache vya Server:

• X-Cache katika response inaweza kuwa na thamani miss wakati ombi halikuhifadhiwa (cached) na thamani hit wakati limehifadhiwa
• Tabia sawa katika kichwa Cf-Cache-Status
• Cache-Control inaonyesha kama rasilimali inahifadhiwa na lini itahifadhiwa tena: Cache-Control: public, max-age=1800
• Vary mara nyingi hutumika katika response kuonyesha vichwa vya ziada vinavyochukuliwa kama sehemu ya cache key hata kama kawaida havizingatiwi.
• Age inaonyesha muda kwa sekunde ambayo kitu kimekuwa kwenye proxy cache.
• Server-Timing: cdn-cache; desc=HIT pia inaonyesha kwamba rasilimali ilihifadhiwa

Cache Poisoning and Cache Deception

Vichwa vya Cache vya Ndani:

• Clear-Site-Data: Kichwa kinachoonyesha cache ambayo inapaswa kuondolewa: Clear-Site-Data: "cache", "cookies"
• Expires: Imejaa tarehe/muda wakati response inapaswa kuisha: Expires: Wed, 21 Oct 2015 07:28:00 GMT
• Pragma: no-cache sawa na Cache-Control: no-cache
• Warning: Kichwa jumla cha HTTP Warning kina taarifa kuhusu matatizo yanayowezekana na hali ya ujumbe. Zaidi ya kichwa kimoja cha Warning kinaweza kuonekana katika response. Warning: 110 anderson/1.3.37 "Response is stale"

Masharti

• Maombi yanayotumia vichwa hivi: If-Modified-Since na If-Unmodified-Since yatatajibiwa kwa data tu ikiwa kichwa cha response Last-Modified kina wakati tofauti.
• Maombi ya masharti yanayotumia If-Match na If-None-Match yanatumia thamani ya Etag ili server itume maudhui ya response ikiwa data (Etag) imebadilika. Etag inachukuliwa kutoka kwa HTTP response.
• Thamani ya Etag kwa kawaida hupimwa kwa msingi wa maudhui ya response. Kwa mfano, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" inaonyesha kwamba Etag ni SHA1 ya bajti 37.

Maombi ya Range

• Accept-Ranges: Inaonyesha ikiwa server inasaidia maombi ya range, na ikiwa ndiyo ni kwa unit gani range inaweza kuelezwa. Accept-Ranges: <range-unit>
• Range: Inaonyesha sehemu ya hati ambayo server inapaswa kurudisha. Kwa mfano, Range:80-100 itarudisha bajti 80 hadi 100 za response ya asili kwa status code 206 Partial Content. Pia kumbuka kuondoa kichwa Accept-Encoding kutoka kwenye ombi.
• Hii inaweza kuwa muhimu kupata response yenye msimbo wa javascript unaoreflektwa kwa hiari ambao kwa kawaida ungeweza ku-escape. Lakini kwa kuabusu hii utahitaji kuingiza vichwa hivi kwenye ombi.
• If-Range: Inaunda ombi la range la masharti ambalo linautekelezwa tu ikiwa etag au tarehe iliyotolewa inafanana na rasilimali ya mbali. Inatumika kuzuia kupakua ranges mbili kutoka kwa matoleo yasiyofanana ya rasilimali.
• Content-Range: Inaonyesha wapi katika ujumbe wa mwili kamili ujumbe wa sehemu unapatikana.

Taarifa za mwili wa ujumbe

• Content-Length: Ukubwa wa rasilimali, kwa namba ya desimali ya bajti.
• Content-Type: Inaonyesha aina ya media ya rasilimali
• Content-Encoding: Inatumika kubainisha algoritim ya compression.
• Content-Language: Inaelezea lugha(za) za kibinadamu zilizokusudiwa kwa hadhira, ili kumruhusu mtumiaji kutofautisha kulingana na lugha anayoipendelea.
• Content-Location: Inaonyesha eneo mbadala kwa data iliyorejeshwa.

Kutoka kwa mtazamo wa pentest taarifa hizi kwa kawaida ni "zisizo na maana", lakini ikiwa rasilimali imelemazwa na 401 au 403 na unaweza kupata njia yoyote ya kupata info hii, inaweza kuwa ya kuvutia.
Kwa mfano, mchanganyiko wa Range na Etag katika ombi la HEAD unaweza leak maudhui ya ukurasa kupitia maombi ya HEAD:

• Ombi lenye kichwa Range: bytes=20-20 na kwa response yenye ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" linaonyesha kuwa SHA1 ya bajti ya 20 ni ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y

Taarifa za Server

• Server: Apache/2.4.1 (Unix)
• X-Powered-By: PHP/5.3.3

Vizuizi

• Allow: Kichwa hiki kinatumika kuwasilisha njia za HTTP ambazo rasilimali inaweza kushughulikia. Kwa mfano, kinaweza kubainishwa kama Allow: GET, POST, HEAD, ikionyesha kwamba rasilimali inasaidia njia hizi.
• Expect: Inatumika na client kuwasilisha matarajio ambayo server inahitaji kutimiza ili ombi lifanyike kwa mafanikio. Matumizi ya kawaida ni Expect: 100-continue, ambayo inaashiria kuwa client inalenga kutuma payload kubwa ya data. Client inatarajia jibu la 100 (Continue) kabla ya kuendelea na upelelezi. Mbinu hii inasaidia kuboresha matumizi ya mtandao kwa kusubiri uthibitisho wa server.

Upakuaji

• Kichwa Content-Disposition katika responses za HTTP kinaelekeza kama faili inapaswa kuonyeshwa ndani ya ukurasa (ndani ya webpage) au kutumika kama kiambatisho (kupakuliwa). Kwa mfano:

Content-Disposition: attachment; filename="filename.jpg"

Hii inamaanisha faili iitwayo "filename.jpg" imekusudiwa kupakuliwa na kuhifadhiwa.

Vichwa vya Usalama

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Kwa kutekeleza Trusted Types kupitia CSP, maombi yanaweza kulindwa dhidi ya mashambulizi ya DOM XSS. Trusted Types zinahakikisha kwamba tu vitu vilivyotengenezwa mahsusi, vinavyokubaliana na sera za usalama zilizowekwa, vinaweza kutumika katika miito hatari ya API za wavuti, hivyo kuilinda JavaScript kwa chaguo-msingi.

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
});
}

// Assignment of raw strings is blocked, ensuring safety.
el.innerHTML = "some string" // Throws an exception.
const escaped = policy.createHTML("<img src=x onerror=alert(1)>")
el.innerHTML = escaped // Results in safe assignment.

X-Content-Type-Options

Kichwa hiki kinazuia MIME type sniffing, mbinu inayoweza kusababisha XSS vulnerabilities. Inahakikisha kwamba browsers zinaheshimu MIME types zilizobainishwa na server.

X-Content-Type-Options: nosniff

X-Frame-Options

Ili kupambana na clickjacking, header hii inapunguza jinsi nyaraka zinavyoweza kuingizwa katika lebo za <frame>, <iframe>, <embed>, au <object>, ikipendekeza nyaraka zote kutaja wazi ruhusa zao za kuingizwa.

X-Frame-Options: DENY

Cross-Origin Resource Policy (CORP) na Cross-Origin Resource Sharing (CORS)

CORP ni muhimu kwa kubainisha rasilimali zinazoweza kupakiwa na tovuti, na kupunguza cross-site leaks. CORS, kwa upande mwingine, inaruhusu mfumo wenye ufanisi zaidi wa cross-origin resource sharing, ikilegeza same-origin policy chini ya masharti fulani.

Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Sera za Cross-Origin Embedder (COEP) na Cross-Origin Opener (COOP)

COEP na COOP ni muhimu kwa kuwezesha kutengwa kwa cross-origin, kupunguza kwa kiasi kikubwa hatari ya shambulio kama Spectre. Zinadhibiti upakiaji wa rasilimali za cross-origin na mwingiliano na madirisha ya cross-origin, mtawalia.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups

HTTP Strict Transport Security (HSTS)

Mwishowe, HSTS ni kipengele cha usalama kinachowalazimisha browsers kuwasiliana na servers kwa kutumia viunganisho salama vya HTTPS pekee, hivyo kuboresha faragha na usalama.

Strict-Transport-Security: max-age=3153600

Kupitisha Casing ya Jina la Header

HTTP/1.1 inaelezea majina ya field za header kama hayazingatii utofauti wa herufi (RFC 9110 §5.1). Hata hivyo, mara nyingi hupatikana middleware maalum, filters za usalama, au logic ya biashara ambazo zinalinganisha jina la header kama lilivyo bila kuanzisha casing kwanza (mfano, header.equals("CamelExecCommandExecutable")). Ikiwa ukaguzi huo unafanywa kwa kuzingatia utofauti wa herufi, mshambuliaji anaweza kuupitisha kwa kutuma header ile ile akiwa na utofauti wa namna ya uandikaji wa herufi.

Mifano ya kawaida ambapo kosa hili hufanyika:

• Orodha za kustomi za kuruhusu/kuzuia (allow/deny) ambazo zinajaribu kuzuia header za ndani “hatari” kabla ya ombi kufikia sehemu nyeti.
• Utekelezaji wa ndani wa pseudo-headers za reverse-proxy (mfano, X-Forwarded-For kusafishwa).
• Frameworks zinazofungua endpoints za management/debug na kutegemea majina ya header kwa uthibitisho au kuchagua amri.

Kutumia kupitisha

1. Tambua header inayosafishwa au kuthibitishwa upande wa server (kwa mfano, kwa kusoma source code, nyaraka, au ujumbe za kosa).
2. Tuma header ile ile lakini ukiandika casing tofauti (mixed-case au upper-case). Kwa kuwa stacks za HTTP kwa kawaida hukanonikalisha headers tu baada user code imetekelezwa, ukaguzi dhaifu unaweza kurukwa.
3. Ikiwa sehemu inayofuata inashughulikia headers bila kuzingatia casing (zaidi yao hufanya hivyo), itakubali thamani inayodhibitiwa na mshambuliaji.

Mfano: Apache Camel exec RCE (CVE-2025-27636)

Katika matoleo yaliyo na udhaifu ya Apache Camel, routes za Command Center zinajaribu kuzuia maombi yasiyoaminifu kwa kuondoa headers CamelExecCommandExecutable na CamelExecCommandArgs. Kulinganisha kulifanywa kwa kutumia equals() hivyo majina yalivyo sawa kabisa kwa herufi ndogo tu ndiyo yaliyoondolewa.

# Bypass the filter by using mixed-case header names and execute `ls /` on the host
curl "http://<IP>/command-center" \
-H "CAmelExecCommandExecutable: ls" \
-H "CAmelExecCommandArgs: /"

Vichwa vya header vinamfikia sehemu ya exec bila kuchujwa, na kusababisha remote command execution kwa ruhusa za mchakato wa Camel.

Ugunduzi na Kupunguza

• Sanisha majina yote ya header kwa kesi moja (kawaida lowercase) kabla ya kufanya mlinganisho wa allow/deny.
• Kataa kurudufu zenye shaka: ikiwa Header: na HeAdEr: zote zipo, zitachukuliwa kama hitilafu.
• Tumia allow-list chanya inayotekelezwa baada ya canonicalisation.
• Linda management endpoints kwa kutumia authentication na ugawanyaji wa mtandao.

References

• CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• https://web.dev/security-headers/
• https://web.dev/articles/security-headers