विशेष HTTP हेडर्स

Reading time: 13 minutes

वर्डलिस्ट्स & टूल्स

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

स्थान बदलने वाले हेडर्स

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 (Check hop-by-hop headers)

स्थान पुनर्लेखन:

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

Hop-by-Hop हेडर्स

Hop-by-hop header एक ऐसा header है जिसे वर्तमान में request को संभाल रहे proxy द्वारा प्रोसेस और उपयोग करने के लिए बनाया गया है, न कि एक end-to-end header की तरह।

• Connection: close, X-Forwarded-For

hop-by-hop headers

HTTP Request Smuggling

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

HTTP Request Smuggling / HTTP Desync Attack

Expect हेडर

क्लाइंट Expect: 100-continue हेडर भेज सकता है और फिर सर्वर HTTP/1.1 100 Continue के साथ जवाब दे सकता है ताकि क्लाइंट request का body भेजना जारी रख सके। हालाँकि, कुछ proxies इस हेडर को पसंद नहीं करते।

Expect: 100-continue के रोचक परिणाम:

• HEAD request में body भेजने पर सर्वर ने यह ध्यान नहीं रखा कि HEAD requests में आमतौर पर body नहीं होती, और कनेक्शन तब तक खुला रखा जब तक timeout नहीं हुआ।
• कुछ सर्वरों ने अजीब डेटा भेजा: response में socket से पढ़ा गया random data, secret keys या यहां तक कि इससे front-end को header values हटाने से रोका जा सकता था।
• इससे एक 0.CL desync भी हुआ क्योंकि backend ने 100 की जगह 400 response दिया, लेकिन proxy front-end body भेजने के लिए तैयार था, तो उसने body भेज दी और backend ने इसे एक नए request के रूप में लिया।
• Expect: y 100-continue जैसी वैरिएशन ने भी 0.CL desync पैदा किया।
• एक समान गलती में जहाँ backend ने 404 से जवाब दिया, उसने CL.0 desync जेनरेट किया क्योंकि malicious request में एक Content-Length दर्शाया गया था, तो backend malicious request + अगले request (victim) के Content-Length बाइट्स भी भेज देता है; इससे queue में desync होता है क्योंकि backend ने malicious request के लिए 404 भेज दिया + victim request का response, पर front-end ने माना कि केवल 1 request ही भेजा गया था, इसलिए दूसरा response दूसरे victim को भेज दिया गया और उसके response ने अगले को भेजा...

HTTP Request Smuggling के बारे में अधिक जानकारी के लिए देखें:

HTTP Request Smuggling / HTTP Desync Attack

Cache हेडर्स

सर्वर कैश हेडर्स:

• X-Cache response में मान के रूप में miss दिखा सकता है जब request cached नहीं था और hit जब यह cached था।
• समान व्यवहार header Cf-Cache-Status में भी देखा जा सकता है।
• Cache-Control बताता है कि कोई resource cache किया जा रहा है और अगली बार कब तक वह resource cached रहेगा: Cache-Control: public, max-age=1800
• Vary अक्सर response में उन अतिरिक्त headers को सूचित करने के लिए इस्तेमाल होता है जिन्हें cache key का हिस्सा माना जाता है, भले ही वे सामान्यतः cache key में शामिल न हों।
• Age उस समय को सेकेंड में परिभाषित करता है जो ऑब्जेक्ट proxy cache में रहा है।
• Server-Timing: cdn-cache; desc=HIT भी संकेत देता है कि कोई resource cached था।

Cache Poisoning and Cache Deception

लोकल कैश हेडर्स:

• Clear-Site-Data: कैश जो हटाना चाहिए उसे सूचित करने वाला हेडर: Clear-Site-Data: "cache", "cookies"
• Expires: response के expire होने की date/time बताता है: Expires: Wed, 21 Oct 2015 07:28:00 GMT
• Pragma: no-cache का व्यवहार Cache-Control: no-cache के समान है
• Warning: सामान्य HTTP header Warning संदेश की स्थिति में संभावित समस्याओं के बारे में जानकारी रखता है। response में एक से ज्यादा Warning header दिख सकते हैं। उदाहरण: Warning: 110 anderson/1.3.37 "Response is stale"

Conditionals

• ऐसे requests जो इन headers का उपयोग करते हैं: If-Modified-Since और If-Unmodified-Since केवल तब डेटा के साथ उत्तर देंगे जब response header Last-Modified में समय अलग हो।
• Conditional requests जो If-Match और If-None-Match का उपयोग करते हैं, वे Etag वैल्यू का उपयोग करते हैं ताकि web server response का content तभी भेजे जब डेटा (Etag) बदल गया हो। Etag HTTP response से लिया जाता है।
• Etag मान आमतौर पर response की सामग्री पर आधारित होता है। उदाहरण के लिए, ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI" सूचित करता है कि Etag 37 bytes का Sha1 है।

Range requests

• Accept-Ranges: यह बताता है कि server range requests को सपोर्ट करता है या नहीं, और अगर करता है तो किस unit में range व्यक्त किया जा सकता है। Accept-Ranges: <range-unit>
• Range: यह उस document के हिस्से को दर्शाता है जिसे server को लौटाना चाहिए। उदाहरण के लिए, Range:80-100 मूल response के बाइट 80 से 100 तक लौटायेगा और status code 206 Partial Content देगा। साथ ही, याद रखें request से Accept-Encoding header हटाना।
• यह उपयोगी हो सकता है जब आपको arbitrary reflected javascript code एक response में चाहिए जो अन्यथा escaped होता; लेकिन इसे abuse करने के लिए आपको request में ये headers inject करने होंगे।
• If-Range: यह एक conditional range request बनाता है जो केवल तभी पूरा किया जाता है जब दिया गया etag या date remote resource से मेल खाता हो। यह दो incompatible संस्करणों से दो ranges डाउनलोड होने से रोकने के लिए उपयोग होता है।
• Content-Range: यह बताता है कि partial message किस हिस्से में एक full body message में स्थित है।

Message body information

• Content-Length: resource का आकार, बाइट्स में दशमलव संख्या।
• Content-Type: resource का मीडिया प्रकार बताता है।
• Content-Encoding: compression algorithm निर्दिष्ट करने के लिए उपयोग होता है।
• Content-Language: दर्शकों के लिए इच्छित मानव भाषा(ओं) का वर्णन करता है, ताकि उपयोगकर्ता अपनी पसंदीदा भाषा के अनुसार अलग कर सकें।
• Content-Location: returned डेटा के लिए एक वैकल्पिक स्थान दर्शाता है।

pentest दृष्टिकोण से यह जानकारी आम तौर पर "बेकार" होती है, लेकिन अगर resource protected है (401 या 403) और आप किसी तरह ये info हासिल कर पाते हैं, तो यह interesting हो सकता है.
उदाहरण के लिए, एक HEAD request में Range और Etag के संयोजन से HEAD requests के माध्यम से पेज की सामग्री leak हो सकती है:

• एक request जिसमें header Range: bytes=20-20 हो और response में ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" मौजूद हो, यह बताता है कि byte 20 का SHA1 ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y है

Server Info

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

Controls

• Allow: यह header बताने के लिए उपयोग होता है कि किसी resource को कौन-कौन से HTTP methods संभाल सकते हैं। उदाहरण: Allow: GET, POST, HEAD, जो संकेत देता है कि resource इन methods को सपोर्ट करता है।
• Expect: क्लाइंट द्वारा सर्वर से ऐसी अपेक्षाएँ बताने के लिए उपयोग होता है जिन्हें request को सफलतापूर्वक process करने के लिए पूरा करना जरूरी है। एक सामान्य उपयोग मामला Expect: 100-continue है, जो संकेत देता है कि क्लाइंट एक बड़ा डेटा payload भेजने का इरादा रखता है। क्लाइंट 100 (Continue) response की प्रतीक्षा करता है इससे पहले कि वह transmission जारी रखे। यह network उपयोग को अनुकूलित करने में मदद करता है क्योंकि यह सर्वर की पुष्टि की प्रतीक्षा करता है।

Downloads

• HTTP responses में Content-Disposition header यह निर्देश देता है कि कोई फाइल inline (वेबपेज के भीतर) दिखायी जाए या उसे attachment (डाउनलोड) के रूप में माना जाए। उदाहरण के लिए:

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

इसका मतलब है कि "filename.jpg" नामक फ़ाइल डाउनलोड करके सेव करने के लिए निर्दिष्ट है।

सुरक्षा हेडर

Content Security Policy (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Trusted Types को CSP के माध्यम से लागू करने पर एप्लिकेशन को DOM XSS हमलों से सुरक्षित किया जा सकता है। Trusted Types यह सुनिश्चित करते हैं कि केवल खास तरह से बनाए गए ऑब्जेक्ट, जो स्थापित सुरक्षा नीतियों के अनुरूप हों, ही खतरनाक web API कॉल्स में उपयोग किए जाएं, और इस तरह JavaScript कोड डिफ़ॉल्ट रूप से सुरक्षित रहता है।

// 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

यह हेडर MIME type sniffing को रोकता है, एक अभ्यास जो XSS vulnerabilities का कारण बन सकता है। यह सुनिश्चित करता है कि ब्राउज़र सर्वर द्वारा निर्दिष्ट MIME types का सम्मान करें।

X-Content-Type-Options: nosniff

X-Frame-Options

clickjacking से निपटने के लिए, यह header सीमित करता है कि दस्तावेज़ों को <frame>, <iframe>, <embed>, या <object> टैग्स में कैसे एम्बेड किया जा सकता है, और सभी दस्तावेज़ों को उनकी एम्बेडिंग अनुमतियाँ स्पष्ट रूप से निर्दिष्ट करने की सिफारिश करता है।

X-Frame-Options: DENY

Cross-Origin Resource Policy (CORP) और Cross-Origin Resource Sharing (CORS)

CORP यह निर्धारित करने के लिए महत्वपूर्ण है कि कौन से संसाधन वेबसाइटों द्वारा लोड किए जा सकते हैं, जिससे cross-site leaks कम होते हैं। CORS, दूसरी ओर, कुछ परिस्थितियों में same-origin policy को ढीला करते हुए एक अधिक लचीला cross-origin resource sharing mechanism प्रदान करता है।

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

Cross-Origin Embedder Policy (COEP) और Cross-Origin Opener Policy (COOP)

COEP और COOP cross-origin isolation सक्षम करने के लिए आवश्यक हैं, जो Spectre-like attacks के जोखिम को काफी कम करते हैं। ये क्रमशः cross-origin resources को लोड करने और cross-origin विंडो के साथ इंटरैक्शन को नियंत्रित करते हैं।

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

HTTP Strict Transport Security (HSTS)

अंत में, HSTS एक सुरक्षा सुविधा है जो ब्राउज़रों को केवल सुरक्षित HTTPS कनेक्शनों पर सर्वरों के साथ संवाद करने के लिए मजबूर करती है, इस प्रकार गोपनीयता और सुरक्षा को बढ़ाती है।

Strict-Transport-Security: max-age=3153600

हेडर नाम केस बायपास

HTTP/1.1 हेडर फील्ड-नामों को case-insensitive के रूप में परिभाषित करता है (RFC 9110 §5.1)। फिर भी, अक्सर कस्टम middleware, security filters, या business logic ऐसे मिलते हैं जो प्राप्त literal हेडर नाम की तुलना पहले केस सामान्यीकृत किये बिना करते हैं (उदा. header.equals("CamelExecCommandExecutable"))। यदि वह चेक्स case-sensitively किए जाते हैं, तो एक हमलावर बस हेडर का कैपिटलाइज़ेशन बदलकर उन्हें बायपास कर सकता है।

Typical situations where this mistake appears:

• Custom allow/deny lists that try to block “dangerous” internal headers before the request reaches a sensitive component.
• In-house implementations of reverse-proxy pseudo-headers (e.g. X-Forwarded-For sanitisation).
• Frameworks that expose management / debug endpoints and rely on header names for authentication or command selection.

Abusing the bypass

1. Identify a header that is filtered or validated server-side (for example, by reading source code, documentation, or error messages).
2. Send the same header with a different casing (mixed-case or upper-case). Because HTTP stacks usually canonicalise headers only after user code has run, the vulnerable check can be skipped.
3. If the downstream component treats headers in a case-insensitive way (most do), it will accept the attacker-controlled value.

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

In vulnerable versions of Apache Camel the Command Center routes try to block untrusted requests by stripping the headers CamelExecCommandExecutable and CamelExecCommandArgs. The comparison was done with equals() so only the exact lowercase names were removed.

# 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: /"

हैडर बिना फ़िल्टर के exec कंपोनेंट तक पहुँचते हैं, जिसके परिणामस्वरूप Camel process की अनुमतियों के साथ remote command execution होता है।

पहचान और निवारण

• सभी header नामों को एक ही case (आमतौर पर lowercase) में सामान्यीकृत करें, allow/deny तुलना करने से पहले।
• संदिग्ध डुप्लिकेट अस्वीकार करें: यदि दोनों Header: और HeAdEr: मौजूद हैं, तो इसे असामान्यता के रूप में मानें।
• एक positive allow-list का उपयोग करें जो canonicalisation के बाद लागू हो।
• प्रबंधन endpoints को प्रमाणीकरण और नेटवर्क विभाजन के साथ सुरक्षित करें।

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