वेब अनुप्रयोगों में दौड़ की स्थिति

टीएल; डीआर इस लेख में अलोकप्रिय दौड़ हालत की चाल का वर्णन किया गया है जो आमतौर पर इस प्रकार के हमले में उपयोग नहीं किया जाता है। हमारे शोध के परिणामों के आधार पर, हमने रेसप्वेन हमलों के लिए अपना ढांचा बनाया।

वास्या 100 डॉलर अपने पेटीएम खाते में ट्रांसफर करना चाहती है। वह स्थानान्तरण टैब पर जाता है, पेटिन उपनाम को धन की संख्या के साथ क्षेत्र में चलाता है जिसे स्थानांतरित करने की आवश्यकता है - 100 नंबर। अगला, हस्तांतरण बटन पर क्लिक करता है। किसको और कितना डेटा वेब एप्लिकेशन को भेजा जाता है। अंदर क्या हो सकता है? सब कुछ सही ढंग से काम करने के लिए प्रोग्रामर द्वारा क्या करने की आवश्यकता है?

• आपको यह सुनिश्चित करने की आवश्यकता है कि राशि स्थानांतरण के लिए वास्या के पास उपलब्ध है।

उपयोगकर्ता के वर्तमान संतुलन का मूल्य प्राप्त करना आवश्यक है, अगर यह उस राशि से कम है जिसे वह स्थानांतरित करना चाहता है, तो इसके बारे में उसे बताएं। इस तथ्य को देखते हुए कि हमारी साइट ऋण प्रदान नहीं करती है और माइनस बैलेंस में नहीं जाना चाहिए।

• उपयोगकर्ता के शेष से स्थानांतरित की जाने वाली राशि को घटाएं

हस्तांतरित राशि की कटौती के साथ वर्तमान उपयोगकर्ता के संतुलन को लिखना आवश्यक है। यह 100 था, यह 100-100 = 0 हो गया।

• उपयोगकर्ता की शेष राशि पेटी में जोड़ें जो राशि स्थानांतरित की गई थी।

पेट्या, इसके विपरीत, 0 थी, यह 0 + 100 = 100 हो गया।

• उपयोगकर्ता को एक संदेश प्रदर्शित करें कि वह अच्छी तरह से किया गया है!

प्रोग्राम लिखते समय, एक व्यक्ति सबसे सरल एल्गोरिदम लेता है, जिसे वह एकल प्लॉट में जोड़ता है, जो प्रोग्राम की स्क्रिप्ट होगी। हमारे मामले में, प्रोग्रामर का कार्य एक वेब ऐप्लिकेशन में एक व्यक्ति से दूसरे व्यक्ति को मनी ट्रांसफर (अंक, क्रेडिट) का तर्क लिखना है। तर्क द्वारा निर्देशित, आप कई चेकों से मिलकर एक एल्गोरिथ्म बना सकते हैं। कल्पना कीजिए कि हमने अनावश्यक रूप से सब कुछ हटा दिया और एक छद्मकोड संकलित किया।

 (. >= _)  .=.-_ .=.+_ ()  () 

लेकिन सब कुछ ठीक होगा अगर सब कुछ बदले में हुआ। लेकिन एक साइट एक ही समय में कई उपयोगकर्ताओं की सेवा कर सकती है, और यह एक धागे में नहीं होता है, क्योंकि आधुनिक वेब एप्लिकेशन समानांतर डेटा प्रसंस्करण के लिए मल्टीप्रोसेसिंग और मल्टीथ्रेडिंग का उपयोग करते हैं। मल्टीथ्रेडिंग के आगमन के साथ, कार्यक्रमों में एक अजीब वास्तुकला भेद्यता है - दौड़ की स्थिति (या दौड़ की स्थिति)।

अब कल्पना करें कि हमारा एल्गोरिथ्म 3 बार एक साथ काम करता है।

वास्या के पास अभी भी अपने संतुलन पर 100 अंक हैं, केवल किसी तरह वह एक ही समय में तीन थ्रेड में वेब एप्लिकेशन की ओर मुड़ गया (अनुरोधों के बीच न्यूनतम समय के साथ)। सभी तीन धाराएं यह जांचती हैं कि उपयोगकर्ता पेटीएम है या नहीं, और जांच लें कि वासा के पास हस्तांतरण के लिए पर्याप्त संतुलन है या नहीं। उस समय में जब एल्गोरिथ्म संतुलन की जांच करता है, यह अभी भी 100 के बराबर है। एक बार सत्यापन पूरा होने के बाद, 100 को वर्तमान शेष से घटाया जाता है और पीट को जोड़ा जाता है।

हमारे पास क्या है? वास्या के खाते में एक नकारात्मक संतुलन है (100 - 300 = -200 अंक)। इस बीच, पेट्या के 300 अंक हैं, हालांकि वास्तव में, यह 100 होना चाहिए। यह एक दौड़ की स्थिति के शोषण का एक विशिष्ट उदाहरण है। यह इस तथ्य के बराबर है कि कई लोग एक बार में एक पास से गुजरते हैं। नीचे 4lemon से इस स्थिति का स्क्रीनशॉट है



दौड़ की स्थिति बहु-थ्रेडेड अनुप्रयोगों, साथ ही उन डेटाबेस में हो सकती है जिसमें वे काम करते हैं। जरूरी नहीं कि वेब एप्लिकेशन में, उदाहरण के लिए, ऑपरेटिंग सिस्टम में विशेषाधिकार वृद्धि के लिए यह एक सामान्य मानदंड है। यद्यपि सफल संचालन के लिए वेब अनुप्रयोगों की अपनी विशेषताएं हैं, जिनके बारे में मैं बात करना चाहता हूं।

ठेठ दौड़ हालत ऑपरेशन

एक हैकर एक हुक्का कमरे, एक खोज और एक बार में प्रवेश करता है, और उसके लिए - आपके पास एक दौड़ की स्थिति है! उमर गनीव

ज्यादातर मामलों में, दौड़ की स्थिति की जांच / संचालन के लिए क्लाइंट के रूप में मल्टीथ्रेड सॉफ्टवेयर का उपयोग किया जाता है। उदाहरण के लिए, बर्प सूट और उसका घुसपैठिया उपकरण। वे पुनरावृत्ति के लिए एक HTTP अनुरोध डालते हैं, कई धाराएं स्थापित करते हैं और बाढ़ को चालू करते हैं। उदाहरण के लिए इस लेख में । या इस एक में । यह एक उचित रूप से काम करने का तरीका है, अगर सर्वर अपने संसाधन के लिए कई थ्रेड्स का उपयोग करने की अनुमति देता है, और जैसा कि वे ऊपर के लेखों में कहते हैं, अगर यह काम नहीं करता है, तो फिर से प्रयास करें। लेकिन तथ्य यह है कि कुछ स्थितियों में, यह प्रभावी नहीं हो सकता है। खासकर यदि आप याद करते हैं कि ऐसे एप्लिकेशन सर्वर तक कैसे पहुंचते हैं।

सर्वर पर क्या है

प्रत्येक थ्रेड एक टीसीपी कनेक्शन स्थापित करता है, डेटा भेजता है, प्रतिक्रिया का इंतजार करता है, कनेक्शन बंद करता है, फिर से खोलता है, डेटा भेजता है, और इसी तरह। पहली नज़र में, सभी डेटा एक साथ भेजे जाते हैं, लेकिन HTTP अनुरोध स्वयं समकालिक रूप से नहीं आ सकते हैं और परिवहन परत की सुविधाओं के कारण असंगत हैं, एक सुरक्षित कनेक्शन (HTTPS) स्थापित करने और DNS (burp के मामले में नहीं) और कई परतों को हल करने की आवश्यकता है नेटवर्क डिवाइस पर भेजे जाने से पहले डेटा पास करने वाले अमूर्त। जब मिलीसेकंड की बात आती है, तो यह एक महत्वपूर्ण भूमिका निभा सकता है।

HTTP पाइपलाइनिंग

आप HTTP-Pipelining को याद कर सकते हैं, जिसमें आप एकल सॉकेट का उपयोग करके डेटा भेज सकते हैं। आप अपने लिए देख सकते हैं कि यह नेटकैट उपयोगिता का उपयोग करके कैसे काम करता है (आपके पास जीएनयू / लिनक्स, राइट?) है।

वास्तव में, आपको कई कारणों से लिनक्स का उपयोग करने की आवश्यकता है, क्योंकि एक अधिक आधुनिक टीसीपी / आईपी स्टैक है, जो ऑपरेटिंग सिस्टम गुठली द्वारा समर्थित है। सर्वर इस पर भी सबसे अधिक संभावना है।

उदाहरण के लिए, nc google.com 80 चलाएं और वहां लाइनें डालें

 GET / HTTP/1.1 Host: google.com GET / HTTP/1.1 Host: google.com GET / HTTP/1.1 Host: google.com 

इस प्रकार, एक कनेक्शन के भीतर, तीन HTTP अनुरोध भेजे जाएंगे, और आपको तीन HTTP प्रतिक्रियाएं प्राप्त होंगी। अनुरोधों के बीच के समय को कम करने के लिए इस सुविधा का उपयोग किया जा सकता है।

सर्वर पर क्या है

वेब सर्वर को क्रमिक रूप से (कीवर्ड) अनुरोध प्राप्त होंगे, और प्राथमिकता के क्रम में प्रतिक्रियाओं को संसाधित करेंगे। इस सुविधा का उपयोग कई चरणों में हमला करने के लिए किया जा सकता है (जब समय की न्यूनतम मात्रा में क्रमिक रूप से दो क्रियाएं करना आवश्यक हो) या, उदाहरण के लिए, हमले की सफलता को बढ़ाने के लिए पहले अनुरोध में सर्वर को धीमा करना।
ट्रिक - आप सर्वर को उसके DBMS को लोड करके आपके अनुरोध को संसाधित करने से रोक सकते हैं, खासकर यदि INSERT / UPDATE का उपयोग किया जाता है। भारी अनुरोध आपके लोड को "धीमा" कर सकता है, इस प्रकार, यह अधिक संभावना होगी कि आप इस दौड़ को जीत लेंगे।

HTTP अनुरोध को दो भागों में विभाजित करना

सबसे पहले, याद रखें कि HTTP अनुरोध कैसे उत्पन्न होता है। ठीक है, जैसा कि आप जानते हैं, पहली पंक्ति विधि, पथ और प्रोटोकॉल संस्करण है:

GET / HTTP/1.1

अगला पंक्ति विराम से पहले शीर्षलेख हैं:

Host: google.com
Cookie: a=1
लेकिन वेब सर्वर कैसे जानता है कि HTTP अनुरोध समाप्त हो गया है?

एक उदाहरण देखते हैं, nc google.com 80 दर्ज करें, और वहां

GET / HTTP/1.1
Host: google.com GET / HTTP/1.1
Host: google.com , आपके द्वारा ENTER दबाने के बाद, कुछ भी नहीं होगा। फिर से क्लिक करें - आप जवाब देखेंगे।

यही है, वेब सर्वर के लिए HTTP अनुरोध को स्वीकार करने के लिए, दो लाइन फीड आवश्यक हैं। एक मान्य क्वेरी इस तरह दिखती है:

GET / HTTP/1.1\r\nHost: google.com\r\n\r\n

यदि यह POST तरीका था (सामग्री-लंबाई के बारे में मत भूलना), तो सही HTTP अनुरोध इस तरह होगा:

POST / HTTP/1.1
Host: google.com
Content-Length: 3

a=1

या

POST / HTTP/1.1\r\nHost: google.com\r\nContent-Length: 3\r\n\r\na=1

कमांड लाइन से एक समान अनुरोध भेजने का प्रयास करें:

 echo -ne "GET / HTTP/1.1\r\nHost: google.com\r\n\r\n" | nc google.com 80 

परिणामस्वरूप, आप एक प्रतिक्रिया प्राप्त करेंगे, क्योंकि हमारा HTTP अनुरोध पूरा हो गया है। लेकिन यदि आप अंतिम \ n वर्ण हटाते हैं, तो आपको उत्तर नहीं मिलेगा।

वास्तव में, कई वेब सर्वरों को स्थानांतरण के रूप में केवल \ n का उपयोग करने की आवश्यकता होती है, इसलिए यह महत्वपूर्ण है कि स्वैप और r और \ n स्वैप न करें, अन्यथा आगे की तरकीबें काम नहीं कर सकती हैं।

यह क्या देता है? आप एक साथ एक संसाधन से कई कनेक्शन खोल सकते हैं, अपने HTTP अनुरोध का 99% भेज सकते हैं और अंतिम बाइट को छोड़ सकते हैं। जब तक आप अंतिम लाइनफ़ीड तक नहीं पहुँचते तब तक सर्वर प्रतीक्षा करेगा। इसके बाद यह स्पष्ट हो जाएगा कि डेटा का मुख्य भाग भेजा गया है, अंतिम बाइट (या कई) भेजें।

यह विशेष रूप से महत्वपूर्ण है जब यह बड़े POST अनुरोध के लिए आता है, उदाहरण के लिए, जब फ़ाइल अपलोड आवश्यक है। लेकिन यहां तक ​​कि एक छोटे से अनुरोध में यह समझ में आता है, क्योंकि कुछ बाइट्स देने से सूचना के एक साथ किलोबाइट की तुलना में बहुत तेजी से होता है।

अनुरोध का दूसरा भाग भेजने से पहले विलंब

व्लाद रोसकोव के शोध के अनुसार, न केवल अनुरोध को विभाजित करना आवश्यक है, बल्कि डेटा के मुख्य भाग और अंतिम एक को भेजने के बीच कई सेकंड की देरी करना भी समझ में आता है। और सभी क्योंकि वेब सर्वर इसे संपूर्णता में प्राप्त करने से पहले ही अनुरोधों को पार्स करना शुरू कर देते हैं।

सर्वर पर क्या है

उदाहरण के लिए, HTTP अनुरोध हेडर प्राप्त करते समय, nginx दोषपूर्ण अनुरोध को कैशिंग करते हुए, उन्हें पार्स करना शुरू कर देगा। जब अंतिम बाइट आता है, तो वेब सर्वर आंशिक रूप से संसाधित अनुरोध को ले जाएगा और सीधे आवेदन पर भेज देगा, जिससे अनुरोधों के प्रसंस्करण समय को कम किया जा सकता है, जिससे हमले की संभावना बढ़ जाती है।

इससे कैसे निपटा जाए

सबसे पहले, यह निश्चित रूप से एक वास्तुशिल्प समस्या है, यदि आप ठीक से एक वेब एप्लिकेशन डिज़ाइन करते हैं, तो आप ऐसी दौड़ से बच सकते हैं।

आमतौर पर, निम्न हमले नियंत्रण विधियों का उपयोग किया जाता है:

• ताले का प्रयोग करें।

ऑपरेशन DBMS में बंद ऑब्जेक्ट तक पहुंच को तब तक के लिए ब्लॉक करता है जब तक कि वह अनब्लॉक न हो जाए। दूसरे लोग खड़े होकर इंतजार करते हैं। ताले को सही ढंग से काम करने के लिए आवश्यक है, न कि किसी भी चीज को अवरुद्ध करना।

• वे लेन-देन अलगाव पर शासन करते हैं ।

अर्दली लेन-देन (सीरियल करने योग्य) - सुनिश्चित करें कि लेनदेन सख्ती से क्रमिक रूप से किए जाएंगे, हालांकि, यह प्रदर्शन को प्रभावित कर सकता है।

• म्यूटेक्स सेमाफोरेस (हेहे) का उपयोग किया जाता है।

कोई चीज लेना (जैसे आदि)। फ़ंक्शन को कॉल करने के समय, एक कुंजी के साथ एक प्रविष्टि बनाई जाती है, यदि प्रविष्टि बनाना संभव नहीं था, तो यह पहले से मौजूद है और फिर अनुरोध बाधित है। अनुरोध प्रसंस्करण के पूरा होने पर, रिकॉर्ड हटा दिया जाता है।

और सामान्य तौर पर, मुझे इवान द हार्ड कार्यकर्ता द्वारा ताले और लेनदेन के बारे में वीडियो बहुत पसंद आया, बहुत जानकारीपूर्ण।

दौड़ की स्थिति में सत्र सुविधाएँ

सत्रों की एक विशेषता यह हो सकती है कि यह अपने आप में दौड़ के शोषण में हस्तक्षेप करता है। उदाहरण के लिए, PHP में, session_start () के बाद, एक सत्र फ़ाइल लॉक होती है, और इसका अनलॉकिंग केवल स्क्रिप्ट के अंत में होता है (यदि session_write_close के लिए कोई कॉल नहीं था)। यदि कोई स्क्रिप्ट जो सत्र का उपयोग करता है उसे इस समय कहा जाता है, तो वह प्रतीक्षा करेगा।

इस सुविधा को दरकिनार करने के लिए, आप एक सरल चाल का उपयोग कर सकते हैं - जितना संभव हो उतनी बार प्रमाणित करने के लिए। यदि वेब एप्लिकेशन आपको एक उपयोगकर्ता के लिए कई सत्र बनाने की अनुमति देता है, तो बस सभी PHPSESSID एकत्र करें और प्रत्येक अनुरोध को अपना पहचानकर्ता बनाएं।

सर्वर से निकटता

यदि जिस साइट पर आप दौड़ की स्थिति को संचालित करना चाहते हैं, वह AWS में होस्ट की गई है - AWS में कार लें। यदि DigitalOcean में - इसे वहां ले जाएं।

जब कार्य अनुरोध भेजना और उनके बीच भेजने के अंतराल को कम करना है, तो वेब सर्वर से तत्काल निकटता निस्संदेह एक प्लस होगी।

आखिरकार, सर्वर 200 और 10 एमएस में पिंग करने पर अंतर होता है। और अगर आप भाग्यशाली हैं, तो आप एक ही भौतिक सर्वर पर भी समाप्त हो सकते हैं, तो उड़ान भरना थोड़ा आसान हो जाएगा :)

संक्षेप में देना

एक सफल दौड़ की स्थिति के लिए, आप सफलता की संभावना बढ़ाने के लिए विभिन्न तरकीबें लगा सकते हैं। वेब सर्वर को धीमा करते हुए, एक से अधिक रख-रखाव अनुरोध भेजें। अनुरोध को कई भागों में तोड़ें और भेजने से पहले देरी करें। सर्वर से दूरी और नेटवर्क इंटरफ़ेस के लिए सार की संख्या कम करें।

इस विश्लेषण के परिणामस्वरूप, मिखाइल बाडिन के साथ मिलकर, हमने रेसपॉइन टूल विकसित किया

इसमें दो घटक होते हैं:

• C लिबर्रेस लाइब्रेरी, जो कम से कम समय में सर्वर से बहुत सारे HTTP अनुरोध भेजती है और लेख से अधिकांश सुविधाओं का उपयोग करती है

• यूटिलिटीज रेसप्वन, जो जोंस कॉन्फ़िगरेशन को स्वीकार करता है और आम तौर पर इस लाइब्रेरी को संचालित करता है

रेसपॉटेन को अन्य उपयोगिताओं (उदाहरण के लिए, बर्प सूट में) में एकीकृत किया जा सकता है, या आप उड़ानों के प्रबंधन के लिए एक वेब इंटरफ़ेस बना सकते हैं (आप अभी भी इस पर अपना हाथ नहीं जमा सकते हैं)। का आनंद लें!

लेकिन वास्तव में अभी भी बढ़ने की गुंजाइश है और आप HTTP / 2 और इसके हमले की संभावनाओं को याद कर सकते हैं। लेकिन वर्तमान में HTTP / 2, अधिकांश संसाधनों में पुराने पुराने HTTP / 1.1 के लिए केवल सामने वाले अनुरोध हैं।

शायद आप कुछ अन्य सूक्ष्मताएं जानते हैं?

मूल