Special HTTP headers

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

Location बदलने वाले Headers

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 (हॉप-बाय-हॉप headers चेक करें)

स्थान को री-राइट करें:

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

Hop-by-hop header वह header है जिसे उस proxy द्वारा प्रोसेस और उपयोग करने के लिए design किया गया है जो वर्तमान में request को हैंडल कर रहा है, इसके विपरीत 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

The Expect header

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

Expect: 100-continue के रोचक प्रभाव:

HEAD request में body भेजने पर server ने यह ध्यान नहीं दिया कि HEAD requests में body नहीं होना चाहिए और कनेक्शन खोलकर रखा जब तक timeout नहीं हुआ।
कुछ servers ने अजीब डेटा भेजा: socket से पढ़ा गया random डेटा response में, secret keys या यह प्रकट किया कि front-end header values हटाने से रोक दिया गया।
यह एक 0.CL desync का कारण भी बना जब backend ने 100 की जगह 400 response दिया, लेकिन proxy front-end initial request का body भेजने के लिए तैयार था — इसलिए उसने body भेज दी और backend ने उसे नए request के रूप में लिया।
Expect: y 100-continue जैसा variation भी 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 response भेजा + victim request के response, जबकि front-end ने सोचा कि केवल 1 request भेजा गया था, तो दूसरी response एक दूसरे victim को भेज दी गई और आगे भी इसी तरह गलत मैपिंग हो गई…

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

HTTP Request Smuggling / HTTP Desync Attack

Cache Headers

Server Cache Headers:

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

Cache Poisoning and Cache Deception

Local Cache headers:

Clear-Site-Data: यह header cache को हटाने के लिए संकेत देता है: Clear-Site-Data: "cache", "cookies"
Expires: response के expiry 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

इन headers का उपयोग करने वाले requests: If-Modified-Since और If-Unmodified-Since केवल तभी डेटा के साथ उत्तरित होंगे जब response header Last-Modified में समय अलग हो।
शर्तीय requests जो If-Match और If-None-Match का उपयोग करते हैं, एक Etag मान का उपयोग करते हैं ताकि web server केवल तब response भेजे जब डेटा (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: यह दर्शाता है कि दस्तावेज़ का कौन सा भाग server को वापस करना चाहिए। उदाहरण के लिए, Range:80-100 मूल response के bytes 80 से 100 को लौटाएगा और status code 206 Partial Content होगा। साथ ही याद रखें कि Accept-Encoding header को request से हटाना पड़ सकता है।
यह उपयोगी हो सकता है जब आप arbitrary reflected javascript code के साथ response पाना चाहते हैं जो अन्यथा escaped हो जाता; लेकिन इसका दुरुपयोग करने के लिए आपको request में ये headers इंजेक्ट करने होंगे।
If-Range: एक conditional range request बनाता है जो केवल तभी पूरा होता है जब दिया गया etag या date remote resource से मेल खाता हो। इसका उपयोग resource के असंगत वर्ज़न से दो अलग ranges डाउनलोड करने से रोकने के लिए होता है।
Content-Range: यह बताता है कि partial message किस हिस्से में full body message का हिस्सा है।

Message body information

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

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

एक request जिसमें header Range: bytes=20-20 हो और response में ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y" मौजूद हो, यह leak कर रहा है कि 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: क्लाइंट द्वारा उन अपेक्षाओं को संप्रेषित करने के लिए उपयोग किया जाता है जिन्हें server को request सफलतापूर्वक संसाधित करने के लिए पूरा करना चाहिए। एक सामान्य उपयोग का मामला Expect: 100-continue header है, जो संकेत देता है कि क्लाइंट बड़ा डेटा payload भेजने का इरादा रखता है। क्लाइंट आगे बढ़ने से पहले 100 (Continue) response की प्रतीक्षा करता है। यह तंत्र नेटवर्क उपयोग को अनुकूलित करने में मदद करता है क्योंकि क्लाइंट server की पुष्टि का इंतजार करता है।

Downloads

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

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

इसका मतलब है कि “filename.jpg” नामक फ़ाइल डाउनलोड करके सहेजी जानी है।

सुरक्षा हेडर

कंटेंट सिक्योरिटी पॉलिसी (CSP)

Content Security Policy (CSP) Bypass

Trusted Types

Trusted Types को CSP के जरिए लागू करके, applications को DOM XSS attacks से सुरक्षित किया जा सकता है। 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 से बचाव के लिए, यह हेडर सीमित करता है कि दस्तावेज़ों को <frame>, <iframe>, <embed>, या <object> टैग में कैसे एम्बेड किया जा सकता है, और सभी दस्तावेज़ों को उनकी एम्बेडिंग अनुमतियाँ स्पष्ट रूप से निर्दिष्ट करने की अनुशंसा करता है।

X-Frame-Options: DENY

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

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

Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)

COEP और COOP क्रॉस-ऑरिजिन अलगाव को सक्षम करने के लिए आवश्यक हैं, और Spectre-like हमलों के जोखिम को काफी कम करते हैं। ये क्रमशः क्रॉस-ऑरिजिन संसाधनों के लोडिंग और क्रॉस-ऑरिजिन विंडोज़ के साथ इंटरैक्शन को नियंत्रित करते हैं।

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

Permissions-Policy (formerly Feature-Policy)

Permissions-Policy वेब डेवलपर्स को एक दस्तावेज़ के भीतर कुछ ब्राउज़र फीचर्स और APIs के व्यवहार को चयनात्मक रूप से सक्षम, अक्षम, या संशोधित करने की अनुमति देता है। यह अब-अप्रचलित Feature-Policy हेडर का उत्तराधिकारी है। यह हेडर शक्तिशाली फीचर्स तक पहुँच को सीमित करके हमले की सतह को कम करने में मदद करता है, जिनका दुरुपयोग किया जा सकता है।

Permissions-Policy: geolocation=(), camera=(), microphone=()

सामान्य निर्देश:

Directive	विवरण
`accelerometer`	Accelerometer सेंसर तक पहुँच को नियंत्रित करता है
`camera`	वीडियो इनपुट डिवाइस (webcam) तक पहुँच को नियंत्रित करता है
`geolocation`	Geolocation API तक पहुँच को नियंत्रित करता है
`gyroscope`	Gyroscope सेंसर तक पहुँच को नियंत्रित करता है
`magnetometer`	Magnetometer सेंसर तक पहुँच को नियंत्रित करता है
`microphone`	ऑडियो इनपुट डिवाइस तक पहुँच को नियंत्रित करता है
`payment`	Payment Request API तक पहुँच को नियंत्रित करता है
`usb`	WebUSB API तक पहुँच को नियंत्रित करता है
`fullscreen`	Fullscreen API तक पहुँच को नियंत्रित करता है
`autoplay`	मीडिया के autoplay करने की अनुमति को नियंत्रित करता है
`clipboard-read`	क्लिपबोर्ड सामग्री पढ़ने तक पहुँच को नियंत्रित करता है
`clipboard-write`	क्लिपबोर्ड में लिखने की अनुमति को नियंत्रित करता है

सिंटैक्स मान:

() - फीचर को पूरी तरह अक्षम कर देता है
(self) - केवल उसी origin के लिए फीचर की अनुमति देता है
* - सभी origins के लिए फीचर की अनुमति देता है
(self "https://example.com") - उसी origin और निर्दिष्ट domain के लिए अनुमति देता है

उदाहरण कॉन्फ़िगरेशन:

# Restrictive policy - disable most features
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()

# Allow camera only from same origin
Permissions-Policy: camera=(self)

# Allow geolocation for same origin and a trusted partner
Permissions-Policy: geolocation=(self "https://maps.example.com")

From a security perspective, missing or overly permissive Permissions-Policy headers may allow attackers (e.g., through XSS or embedded iframes) to abuse powerful browser features. Always restrict features to the minimum necessary for your application.

Header Name Casing Bypass

HTTP/1.1 defines header field‐names as case-insensitive (RFC 9110 §5.1). Nevertheless, it is very common to find custom middleware, security filters, or business logic that compare the literal header name received without normalising the casing first (e.g. header.equals("CamelExecCommandExecutable")). If those checks are performed case-sensitively, an attacker may bypass them simply by sending the same header with a different capitalisation.

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

Identify a header that is filtered or validated server-side (for example, by reading source code, documentation, or error messages).
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.
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 की अनुमतियों के साथ रिमोट कमांड निष्पादन होता है।

पता लगाने और निवारण

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

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

HackTricks