[**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) का उपयोग करें ताकि आप दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित **कार्यप्रवाहों** को आसानी से बना और **स्वचालित** कर सकें।\
AWS हैकिंग सीखें और अभ्यास करें:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
GCP हैकिंग सीखें और अभ्यास करें: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **हमारे** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **Twitter** 🐦 पर हमें **फॉलो** करें [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
इस तकनीक की गहरी समझ प्राप्त करने के लिए [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) में मूल रिपोर्ट देखें
Race conditions का लाभ उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई अनुरोध एक ही समय में संभाले जाएं, **उनकी प्रसंस्करण समय में बहुत कम अंतर के साथ—आदर्श रूप से, 1ms से कम**।
* **HTTP/2**: एकल TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर के प्रभाव को कम करता है। हालाँकि, सर्वर-साइड भिन्नताओं के कारण, दो अनुरोध एक सुसंगत race condition शोषण के लिए पर्याप्त नहीं हो सकते हैं।
* **HTTP/1.1 'लास्ट-बाइट सिंक'**: 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समानांतर आगमन प्राप्त करता है।
रोकें गए फ्रेम का अगला भेजना एक ही पैकेट में उनके आगमन का परिणाम होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं।
लक्ष्य की आर्किटेक्चर को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को अलग तरीके से रूट कर सकते हैं, जो समय को प्रभावित करता है। तुच्छ अनुरोधों के माध्यम से पूर्व-निर्धारित सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है।
PHP के सत्र हैंडलर जैसे ढांचे सत्र द्वारा अनुरोधों को अनुक्रमित करते हैं, संभावित रूप से कमजोरियों को अस्पष्ट करते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को हल कर सकता है।
यदि कनेक्शन गर्म करना प्रभावी नहीं है, तो डमी अनुरोधों की बाढ़ के माध्यम से वेब सर्वर की दर या संसाधन सीमा विलंब को जानबूझकर सक्रिय करना एकल-पैकेट हमले को सुविधाजनक बना सकता है, जिससे सर्वर-साइड विलंब उत्पन्न होता है जो race conditions के लिए अनुकूल है।
* **Tubo Intruder - HTTP2 सिंगल-पैकेट हमला (1 एंडपॉइंट)**: आप अनुरोध को **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 एकल-पैकेट हमला (कई एंडपॉइंट)**: यदि आपको 1 एंडपॉइंट पर एक अनुरोध भेजने की आवश्यकता है और फिर RCE को ट्रिगर करने के लिए अन्य एंडपॉइंट्स पर कई अनुरोध भेजने की आवश्यकता है, तो आप `race-single-packet-attack.py` स्क्रिप्ट को इस तरह बदल सकते हैं:
* यह **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" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं।
मूल शोध में यह बताया गया है कि इस हमले की सीमा 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) पर पा सकते हैं।
* **Intruder**: **Intruder** को **request** भेजें, **Options menu** के अंदर **threads की संख्या** को **30** पर सेट करें, और पेलोड के रूप में **Null payloads** का चयन करें और **30** उत्पन्न करें।
यह रेस कंडीशन का सबसे बुनियादी प्रकार है जहाँ **कमजोरियाँ** उन स्थानों पर **प्रकट** होती हैं जो **आपको एक क्रिया करने के लिए कितनी बार सीमित करते हैं**। जैसे कि एक वेब स्टोर में एक ही छूट कोड का कई बार उपयोग करना। एक बहुत आसान उदाहरण [**इस रिपोर्ट**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) या [**इस बग**](https://hackerone.com/reports/759247)** में पाया जा सकता है।**
जटिल रेस कंडीशनों का शोषण अक्सर छिपे हुए या **अनपेक्षित मशीन उप-राज्यों** के साथ बातचीत करने के लिए संक्षिप्त अवसरों का लाभ उठाने में शामिल होता है। इसे इस प्रकार से निपटें:
* उन एंडपॉइंट्स को पहचानने से शुरू करें जो महत्वपूर्ण डेटा को संशोधित या बातचीत करते हैं, जैसे उपयोगकर्ता प्रोफाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान केंद्रित करें:
* **स्टोरेज**: सर्वर-साइड स्थायी डेटा को संभालने वाले एंडपॉइंट्स को प्राथमिकता दें, न कि क्लाइंट-साइड डेटा को संभालने वाले।
* **क्रिया**: उन ऑपरेशनों की तलाश करें जो मौजूदा डेटा को बदलते हैं, जो नए डेटा जोड़ने की तुलना में शोषण योग्य स्थितियाँ बनाने की अधिक संभावना रखते हैं।
* **कीइंग**: सफल हमले आमतौर पर उसी पहचानकर्ता पर की गई ऑपरेशनों में शामिल होते हैं, जैसे उपयोगकर्ता नाम या रीसेट टोकन।
* पहचाने गए एंडपॉइंट्स पर रेस कंडीशन हमलों के साथ परीक्षण करें, किसी भी अपेक्षित परिणामों से विचलन के लिए अवलोकन करें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन व्यवहार में परिवर्तन एक कमजोरी का संकेत दे सकते हैं।
* हमले को कमजोरियों का शोषण करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस चरण में सटीक समय के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है।
अनुरोधों के समय में सटीकता कमजोरियों को प्रकट कर सकती है, विशेष रूप से जब सुरक्षा टोकनों के लिए पूर्वानुमानित विधियों जैसे टाइमस्टैम्प का उपयोग किया जाता है। उदाहरण के लिए, टाइमस्टैम्प के आधार पर पासवर्ड रीसेट टोकन उत्पन्न करना समानांतर अनुरोधों के लिए समान टोकन की अनुमति दे सकता है।
इसे देखने के लिए [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) पर जाएँ कि कैसे **भुगतान** करें और **एक अतिरिक्त** आइटम **जोड़ें** जिसके लिए **आपको भुगतान करने की आवश्यकता नहीं है**।
[**इस शोध**](https://portswigger.net/research/smashing-the-state-machine) के अनुसार, Gitlab इस तरीके से अधिग्रहण के लिए कमजोर था क्योंकि यह **एक ईमेल के ईमेल सत्यापन टोकन को दूसरे ईमेल पर भेज सकता है**।
यदि **2 अलग-अलग लेखन** का उपयोग करके **जानकारी** को **डेटाबेस** के अंदर **जोड़ने** के लिए किया जाता है, तो एक छोटा सा समय होता है जहाँ **केवल पहला डेटा डेटाबेस के अंदर लिखा गया है**। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है, तो **उपयोगकर्ता नाम** और **पासवर्ड****लिखे** जा सकते हैं और **फिर टोकन** नए बनाए गए खाते की पुष्टि करने के लिए लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए **खाते की पुष्टि करने के लिए टोकन शून्य है**।
इसलिए **एक खाता पंजीकृत करना और तुरंत पुष्टि करने के लिए एक खाली टोकन के साथ कई अनुरोध भेजना** (`token=` या `token[]=` या किसी अन्य भिन्नता) एक ऐसा खाता **पुष्टि करने** की अनुमति दे सकता है जहाँ आप ईमेल को नियंत्रित नहीं करते हैं।
कई [**OAUth प्रदाता**](https://en.wikipedia.org/wiki/List\_of\_OAuth\_providers) हैं। ये सेवाएँ आपको एक एप्लिकेशन बनाने और उन उपयोगकर्ताओं को प्रमाणित करने की अनुमति देंगी जिन्हें प्रदाता ने पंजीकृत किया है। ऐसा करने के लिए, **क्लाइंट** को **आपके एप्लिकेशन** को **OAUth प्रदाता** के अंदर उनके कुछ डेटा तक पहुँचने की **अनुमति** देनी होगी।\
तो, यहाँ तक बस एक सामान्य लॉगिन है जैसे google/linkedin/github... जहाँ आपको एक पृष्ठ पर संकेत दिया जाता है: "_एप्लिकेशन \<InsertCoolName> आपकी जानकारी तक पहुँचने की इच्छा रखता है, क्या आप इसे अनुमति देना चाहते हैं?_"
**समस्या** तब उत्पन्न होती है जब आप **इसे स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए **`authorization_code`** से एक से अधिक AT/RT (_Authentication Token/Refresh Token_) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि **कई खाते बनाए जा सकें**। फिर, यदि आप **एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो AT/RT का एक जोड़ा हटा दिया जाएगा, लेकिन अन्य अभी भी मान्य रहेंगे**।
एक बार जब आप **एक मान्य RT प्राप्त कर लेते हैं** तो आप **इसका दुरुपयोग करने की कोशिश कर सकते हैं ताकि कई AT/RT उत्पन्न किए जा सकें** और **यहां तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमति रद्द कर देता है, तो भी **कई RTs मान्य रहेंगे।**
[**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\_PoC) में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को **समानांतर** में भेजने के लिए है ताकि **वेब सॉकेट्स में रेस कंडीशंस का दुरुपयोग किया जा सके**।
AWS हैकिंग सीखें और अभ्यास करें:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
GCP हैकिंग सीखें और अभ्यास करें: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **Twitter** पर हमें **फॉलो करें** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **हैकिंग ट्रिक्स साझा करें और [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में PRs सबमिट करें।**
[**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) का उपयोग करें ताकि आसानी से **वर्कफ़्लो** बनाएं और **स्वचालित** करें जो दुनिया के **सबसे उन्नत** सामुदायिक उपकरणों द्वारा संचालित हों।\