[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें और आसानी से **ऑटोमेट वर्कफ़्लो** बनाएं जो दुनिया के **सबसे उन्नत** समुदाय उपकरणों द्वारा संचालित हैं।\
<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) देखें!
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह, **The PEASS Family** की खोज करें
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
* **HackTricks** और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में PRs सबमिट करके अपने हैकिंग ट्रिक्स साझा करें।
इस तकनीक को गहरी समझने के लिए मूल रिपोर्ट की जांच करें [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
रेस कंडीशन का लाभ उठाने में मुख्य बाधा यह है कि सुनिश्चित किया जाए कि कई अनुरोध समायोजित समय में हैं, उनके प्रसंस्करण समय में **बहुत कम अंतर—आदर्श रूप से, 1ms से कम**।
* **HTTP/2**: एक ही TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर प्रभाव को कम करता है। हालांकि, सर्वर-साइड विविधताओं के कारण, दो अनुरोध एक स्थिर रेस कंडीशन हमले के लिए पर्याप्त नहीं हो सकते।
* **HTTP/1.1 'लास्ट-बाइट सिंक'**: 20-30 अनुरोधों के अधिकांश हिस्से को पूर्व-भेजन की अनुमति देता है, एक छोटा टुकड़ा रोकता है, जिसे फिर साथ में भेजा जाता है, सर्वर पर समकालिक पहुंच को प्राप्त करते हैं।
बाधित फ्रेम्स के बाद के भेजन से उनकी एक ही पैकेट में पहुंचना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो सामान्यत: RC हमलों में शामिल नहीं होती हैं।
लक्षित की गई वास्तुकला को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को विभिन्न रूप से मार्गित कर सकते हैं, जो समय पर प्रभाव डाल सकते हैं। अर्थहीन अनुरोधों के माध्यम से पूर्वानुमानित सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है।
PHP की सत्र हैंडलर जैसे फ्रेमवर्क सत्र द्वारा अनुरोधों को सीरियलाइज कर सकते हैं, संकेतों को छिपा सकते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को टाल सकता है।
यदि कनेक्शन गर्म करना असफल है, तो वेब सर्वर की दर या संसाधन सीमाओं को जानबूझकर ट्रिगर करना, डमी अनुरोधों की बाढ़ के माध्यम से एक सिंगल-पैकेट हमले को सुविधाजनक बना सकता है जो रेस कंडीशन के लिए उपयुक्त सर्वर-साइड देरी को उत्पन्न कर सकता है।
* **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 (Several endpoints)**: यदि आपको RCE को ट्रिगर करने के लिए 1 एंडपॉइंट को रिक्वेस्ट भेजने की आवश्यकता है और फिर अन्य एंडपॉइंट्स पर कई रिक्वेस्ट भेजने की आवश्यकता है, तो आप `race-single-packet-attack.py` स्क्रिप्ट को निम्नलिखित तरह से बदल सकते हैं:
* **मल्टी-एंडपॉइंट** आरसी के लिए आप **छिपे हुए स्थिति** को जाने वाला **अनुरोध** भेजना शुरू कर सकते हैं और फिर इसके बाद **50 अनुरोध** भेज सकते हैं जो **छिपे हुए स्थिति का शोषण** करते हैं।
* **इंट्रूडर:** **इंट्रूडर** को **अनुरोध** भेजें, **विकल्प मेनू** में **स्थान** की **संख्या 30** पर सेट करें, **पेलोड** के रूप में **नल पेलोड** का चयन करें और **30** जेनरेट करें।
यह सबसे मौलिक प्रकार की रेस कंडीशन है जहाँ **कम संख्या में क्रिया करने की सीमा** होती है जिसमें **सुरक्षा कमियाँ** हो सकती हैं। जैसे किसी वेब स्टोर में एक ही डिस्काउंट कोड का कई बार उपयोग करना। एक बहुत ही सरल उदाहरण [**इस रिपोर्ट**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) या [**इस बग**](https://hackerone.com/reports/759247) में देखा जा सकता है।
जटिल रेस कंडीशन का शोध करना अक्सर छोटे अवसरों का लाभ उठाने का मतलब होता है जो छिपी या **अनजान मशीन उप-स्थितियों** के साथ बातचीत करने के लिए होते हैं। यहाँ इसका तरीका है:
* सर्वाधिक महत्वपूर्ण डेटा को संशोधित या बातचीत करने वाले अंत-बिंदुओं की पहचान करके शुरू करें, जैसे उपयोगकर्ता प्रोफ़ाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान दें:
* **स्टोरेज**: उन अंत-बिंदुओं को पसंद करें जो सर्वर-साइड स्थायी डेटा को संचालित करते हैं उनके बजाय जो डेटा क्लाइंट-साइड संभालते हैं।
* **क्रिया**: मौजूदा डेटा को बदलने वाली क्रियाओं की खोज करें, जो उनसे अधिक उत्पादनीय स्थितियाँ बनाने की संभावना हैं जो नए डेटा जोड़ने वाले की तुलना में।
* **कींग**: सफल हमले आम तौर पर एक ही पहचानकर्ता पर आधारित क्रियाओं को शामिल करते हैं, जैसे उपयोगकर्ता नाम या रीसेट टोकन।
* निर्धारित अंत-बिंदुओं को रेस कंडीशन हमलों के साथ जांचें, अपेक्षित परिणामों से किसी भिन्नता के लिए ध्यान दें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन के व्यवहार में परिवर्तन एक संकट संकेत कर सकते हैं।
3.**संकट को प्रदर्शित करें**
* संकट को उत्पन्न करने के लिए आवश्यकतानुसार हमले को न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस कदम में समयित होने के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है।
अनुरोधों में समयितता में सटीकता संकेतित कर सकती है, विशेषकर सुरक्षा टोकन के लिए समय-चिह्नों जैसे पूर्वानुमानित विधियों का उपयोग करने पर। उदाहरण के लिए, समय-चिह्नों पर आधारित पासवर्ड रीसेट टोकन उत्पन्न करने से समयितता के दौरान एक ही टोकन समान अनुरोधों के लिए संकेतित कर सकता है।
* दो पासवर्ड रीसेट टोकन का एक साथ अनुरोध करें और उन्हें तुलना करें। मेल खाता उत्पन्न करने में दोष सुझाते हैं।
**इसे जांचने के लिए** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **का अवलोकन करें।**
## छिपी उप-स्थितियों के मामले की अध्ययन
### भुगतान करें और आइटम जोड़ें
दुकान में **भुगतान** करने और **एक अतिरिक्त** आइटम जोड़ने के बारे में जानने के लिए इस [**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 प्रदाता** के अंदर।\
तो, यहाँ तक सिर्फ एक सामान्य लॉगिन गूगल/लिंक्डइन/गिटहब... जहां आपको एक पृष्ठ के साथ प्रोम्प्ट किया जाता है: "_एप्लिकेशन \<InsertCoolName> आपकी जानकारी तक पहुंचना चाहता है, क्या आप इसे अनुमति देना चाहते हैं?_"
**समस्या** उत्पन्न होती है जब आप इसे **स्वीकार करते हैं** और स्वचालित रूप से एक **`authorization_code`** को दुर्भाग्यपूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए एटी/आरटी** (_प्रमाणीकरण टोकन/रिफ्रेश टोकन_) **से अधिक एटी/आरटी उत्पन्न कर सके**। मूल रूप से, यह आपके डेटा तक पहुंचने की अनुमति देने के लिए आपने एप्लिकेशन को स्वीकृत किया है इस तथ्य का दुरुपयोग करेगा और **कई खाते बनाएगा**। फिर, अगर आप **एप्लिकेशन को अपने डेटा तक पहुंचने की अनुमति देना बंद कर देते हैं तो एक जोड़ा एटी/आरटी हटा दिया जाएगा, लेकिन अन्य वाले अभी भी मान्य रहेंगे**।
एक वैध आरटी प्राप्त करने के बाद आप **इसे दुरुपयोग करने के लिए कई एटी/आरटी उत्पन्न करने की कोशिश कर सकते हैं** और **यदि उपयोगकर्ता दुर्भाग्यपूर्ण एप्लिकेशन के लिए अपने डेटा तक पहुंचने की अनुमति रद्द कर देता है** तो **कई आरटी अभी भी मान्य रहेंगे**।
[**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\_PoC) में आपको जावा में वेबसॉकेट संदेश भेजने के लिए PoC मिलेगा **पैरलल** में दुर्भाग्यपूर्ण स्थितियों का दुरुपयोग करने के लिए वेब सॉकेट में भी।
<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* यदि आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) का उपयोग करें और आसानी से **वर्कफ़्लो बनाएं और स्वचालित करें** जो दुनिया के **सबसे उन्नत** समुदाय उपकरणों द्वारा संचालित हैं।\