👩‍🎨 ❎ 😗 उपयोगकर्ता प्रतिबंध के माध्यम से सुरक्षा या भेद्यता बनाने के लिए कैसे 👩🏻‍💼 💄 💇🏾

2019 में, CDD नेटवर्क पर CPDoS कैश पॉइज़्ड डेनियल ऑफ़ सर्विस) भेद्यता की खोज की गई, जो CDN प्रदाता के HTTP कैश को जहर देने और सेवा से वंचित करने की अनुमति देता है। भेद्यता ने अभी तक बहुत प्रचार नहीं किया है, क्योंकि यह वास्तविक हमलों में नहीं देखा गया है। लेकिन मैं कैश पॉइज़निंग के तरीकों में से एक के बारे में अलग से बात करना चाहता हूं। HTTP मेथड ओवरराइड।

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

CPDoS के बारे में लघु यदि आप इसे याद किया

, URI method .

, , , , - . — - - -, , - , . , .

, . , , -. - , , .

ग्राहक को सीमित करें, कम कर सकता है - कम टूट जाएगा

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

यह स्पष्ट है कि साधारण HTTP क्लाइंट के लिए तंग यातायात, गैर-मानक को काटने के लिए सब कुछ अच्छी तरह से किया गया था। लेकिन सुरक्षा की खोज में, GET और POST को छोड़कर सभी तरीकों को काट दिया गया। शायद क्योंकि ये एकमात्र तरीके हैं जो वैकल्पिक नहीं हैं और सामान्य प्रयोजन सर्वर के लिए आवश्यक हैं।

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

और ग्राहक गलत लोगों तक सीमित थे। वे HTTP क्लाइंट से संदेशों की परिवर्तनशीलता को सीमित करना चाहते थे, और उन ग्राहकों को सीमित करते थे जिन्हें ये WAFs संरक्षित करते थे, अंतिम एप्लिकेशन सर्वर और उनके डेवलपर्स। अब, डेवलपर्स को केवल दो तरीकों के साथ छोड़ दिया गया था जो HTTP क्लाइंट के तर्क का वर्णन करने के लिए हमेशा पर्याप्त नहीं थे।

उन्हें दूर करने के लिए अड़चनें पैदा की जाती हैं।

यह उम्मीद की जानी थी कि यह अत्यधिक प्रतिबंध जल्द या बाद में वेब डेवलपर्स के साथ हस्तक्षेप करना शुरू कर देगा। विडंबना यह है कि ऐसे WAF से छुटकारा पाना इतना आसान है। खासकर जब वे ग्राहकों या प्रदाताओं के साथ हों। अन्य लोगों की सुरक्षा नीतियों को चुनौती देना एक विनाशकारी मामला है।

HTTP के लचीलेपन के कारण, इस सीमा को दरकिनार करना मुश्किल नहीं है, बस अनुरोध में कुछ जोड़ें जहां आप विधि को ओवरराइड कर सकते हैं। सख्त WAF केवल अनुरोध पंक्ति (अनुरोध की पहली पंक्ति) में विधि की जांच करेगा और वहां एक अनुमोदित GET या POST देखकर खुश होगा। और बैकएंड जोड़े गए तत्व को पार्स करने और उसमें से वास्तविक विधि निकालने में सक्षम होगा।

आप लेखों का एक गुच्छा , वास्तव में एक गुच्छा गूगल कर सकते हैंकैसे खराब प्रॉक्सी ने REST अनुप्रयोगों को तोड़ दिया, और कैसे लेखकों को एक अलग हेडर में वास्तविक विधि को पारित करना पड़ा। उन सभी में, वे सुझाव देते हैं कि आप लगभग एक ही हेडर (X-HTTP-Method-X, HTTP-Method-Override या X-Method-Override - वर्तनी कुछ भिन्न होती है) को एक ओवरराइड विधि को इंगित करने के लिए दर्ज करते हैं। बहुत, बहुत कम ही ऐसे संदर्भ पा सकते हैं जो एक ही उद्देश्य क्वेरी-घटक URI के लिए उपयोग किए जा सकते हैं।

इन लेखों से क्या गायब है सुरक्षा विचार अनुभाग है। और वे सिर्फ हैं।

क्या विधि ओवरराइडिंग सुरक्षित है?

कभी-कभी वेब एप्लिकेशन के डेवलपर्स यह भूल जाते हैं कि क्लाइंट और सर्वर के बीच इंटरमीडिएट प्रतिभागी हो सकते हैं जो HTTP प्रोटोकॉल पर बातचीत करते हैं: प्रॉक्सी, प्रदाताओं के वेब कैश, सीडीएन और डब्ल्यूएएफ। टीएलएस का प्रसार क्लाइंट और सर्वर के बीच एक मध्यवर्ती भागीदार की संभावना को बहुत कम कर देता है। सबसे अधिक संभावना है कि क्लाइंट और बैकएंड के बीच एकमात्र प्रॉक्सी नगनेक्स का अपना सर्वर होगा। और ऐसा कॉन्फ़िगरेशन रिलीज से पहले विशिष्ट परिदृश्यों पर परीक्षण करने के लिए पर्याप्त आसान है।

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

जिन हमलों के बारे में मैं बात करना चाहता हूं, वे मुख्य रूप से HTTP / 1.1 पर लागू होते हैं। HTTP / 2 किसी भी तरह से पुराने मानक के व्यवहार को विरासत में मिला है, कुछ मायनों में यह अपने तरीके से चला जाता है, इसलिए नए मानक पर प्रत्येक हमले की प्रयोज्यता को अलग से माना जाएगा।

कैश पर हमला

ज्यादातर अक्सर, मध्यवर्ती सर्वर खाता पद्धति को ओवरराइड नहीं करते हैं, एक्स-एचटीटीपी-एचटीटीपीएल-मेथड-ओवरराइड परिवार के हेडर की जांच नहीं करते हैं, और अनुरोध रेखा से इसकी मुख्य विधि का उपयोग करके अनुरोध के साथ काम करते हैं। और चूंकि ओवरराइड विधि कैश में अनुरोध के लिए खोज करने के लिए कुंजी में शामिल नहीं है (विधि + URI), ऐसे सर्वर POST + X-HTTP-Method-Override: DELETE से POST को अलग नहीं कर सकते हैं। इसका मतलब है कि यदि आप बैकएंड की निगरानी कर सकते हैं और ओवरराइड की गई विधियों को निष्पादित कर सकते हैं, तो आप किसी निश्चित यूआरआई को किसी भी अनुरोध की कैशिंग की अनुमति नहीं दे सकते।

CPDoS दस्तावेज़ का एक अच्छा उदाहरण है कि यदि आप इस तरह के अनुरोध को कैश करते हैं तो क्या होता है। जब कोई हमलावर GET अनुरोध के रूप में POST अनुरोध को अस्वीकार करता है, तो प्रॉक्सी प्रतिस्थापन की पहचान नहीं करता है और अनुरोध को वैध GET अनुरोध मानता है। बैकएंड, हालांकि, ओवरराइड विधि को पहचानता है और एक्स-एचटीटीपी-HTTP-मेथड-ओवरराइड - POST हेडर में वर्णित क्रिया को निष्पादित करता है। चूंकि UST गंतव्य URI के लिए POST विधि परिभाषित नहीं है, सर्वर एक त्रुटि उत्पन्न करता है। इसके अलावा, बैकएंड प्रतिक्रिया को मूल विधि की प्रतिक्रिया के रूप में कैश में संग्रहीत किया जाता है - जीईटी। अब उसी URI के लिए कोई भी अगला GET अनुरोध कैश की गई त्रुटि लौटाएगा।

वास्तव में, दस्तावेज़ में प्रस्तुत किए गए हमले की तुलना में हमला थोड़ा व्यापक है। लेखकों ने कैश में त्रुटि को संग्रहीत करने पर ध्यान केंद्रित किया, जो हर जगह नहीं है (पहले से ही) पुन: पेश किया जा सकता है। लेकिन अगर चयनित यूआरआई के लिए अनुरोधित विधि को परिभाषित किया गया है और सफलतापूर्वक निष्पादित किया जाएगा, तो प्रॉक्सी को 200 की स्थिति के साथ एक प्रतिक्रिया मिलेगी और इसे कैश करना होगा। फिर उसी URI के बाद के अनुरोध पूरी तरह से गलत तरीके से प्रतिक्रियाएं प्राप्त करने के लिए। इस परिदृश्य में, मूल CPDoS विवरण में 4XX प्रतिक्रियाओं की कैश त्रुटि के साथ आवश्यकता नहीं है।

उल्टे समस्या हो सकती है। यदि कोई सम्मानजनक HTTP क्लाइंट GET + X-HTTP-Method-Override: PATCH अनुरोध (यह बुरा है, लेकिन उस पर बाद में और अधिक) भेजता है, और कैश में पहले से ही GET प्रतिक्रिया है, तो क्लाइंट को यह कैश की गई प्रतिक्रिया प्राप्त होगी। इस मामले में, बैकएंड को कभी भी PATCH अनुरोध प्राप्त नहीं होगा, जो क्लाइंट और सर्वर दोनों पर एप्लिकेशन लॉजिक का उल्लंघन कर सकता है।

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

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

POST /some-uri HTTP/1.1
X-HTTP-Method-Override: DELETE
   ↓  ↓   ↓
POST /some-uri?method=DELETE HTTP/1.1

अब अलग-अलग तरीकों से अनुरोध कैश के लिए अलग-अलग दिखते हैं, क्योंकि उन्हें अलग-अलग चाबियाँ मिलती हैं। कुछ परदे के पीछे URI में क्वेरी घटक वाले अनुरोधों को कैश नहीं करना पसंद करते हैं। लेकिन यह केवल कैशिंग दक्षता को प्रभावित करेगा। यह विधि हमेशा गलत कैशिंग के साथ समस्याओं को हल करती है।

एक अन्य तरीका एक अलग हेडर में विधि ओवरराइड को छोड़ना है, लेकिन कैश में उत्तर खोजने के लिए एक द्वितीयक कुंजी दर्ज करें। यह वैरी हैडर के साथ संभव है। अनुरोध की सेवा करते समय, सर्वर हेडर को विधि ओवरराइड के साथ दोहराएगा और वैरी हेडर में इस हेडर के नाम को प्रतिबिंबित करेगा। फिर, निम्नलिखित अनुरोधों पर, कैश सर्वर कैश में एक अनुरोध की खोज करते समय ओवरराइड विधि के मूल्य को एक माध्यमिक कुंजी के रूप में उपयोग करेगा।

यह विधि काम करती है यदि मध्यवर्ती सर्वर द्वितीयक कुंजी के साथ काम कर सकता है। यह आमतौर पर मामला है, लेकिन प्रॉक्सी ट्रस्ट स्तर, जो GET और POST को छोड़कर सभी तरीकों को काटता है, आमतौर पर कम होता है और इसे जांचना बेहतर होता है।

अनुरोध निकाय के अंदर किसी भी इकाई के माध्यम से एक विधि को ओवरराइड करने से अतिरिक्त हेडर के माध्यम से ओवरराइड करने के समान ही कमियां हैं - यह कैश की दृश्यता से बाहर है।

संदेश पंक्तिबद्ध करना हमलों

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

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

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

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

एक विधि का सबसे सरल और सबसे मजेदार पुनर्परिभाषित GET को क्रिया HEAD से बदलना है। यदि पहले के उत्तर में एक शरीर है, तो दूसरा नहीं है। इसके अलावा, सभी अन्य हेडर समान हैं, जिनमें अनुरोध के फ्रेमिंग भी शामिल हैं। जब प्रॉक्सी सर्वर पर इस तरह के ओवरराइड HEAD को रीडायरेक्ट करता है, तो यह सर्वर से न केवल रिस्पॉन्स हेडर, बल्कि रिस्पॉन्स बॉडी की भी उम्मीद करेगा, जो बैकएंड भेजने वाला नहीं है। यदि प्रॉक्सी और सर्वर अनुरोध-प्रतिक्रिया मोड में बातचीत करते हैं, तो कनेक्शन "हैंग" होगा जब तक कि यह टाइमआउट से टूट नहीं जाता।

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

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

स्वचालित स्पैम रीप्ले

मैंने ऊपर कहा कि फॉर्म के अनुरोध GET + X-HTTP-Method-Override: PATCH से सम्मानजनक क्लाइंट खराब हैं। : और यह क्योंकि तरीकों दो गुण होते हैं बुरा है सुरक्षा और idempotency । सुरक्षा का अर्थ है कि विधि सर्वर की स्थिति (केवल पढ़ने के लिए) को परिवर्तित नहीं करती है, और इस लेख के संदर्भ में हमें रुचि नहीं देती है। विधि की बेवकूफी यह सुनिश्चित करती है कि बार-बार अनुरोध का एकल अनुरोध के समान प्रभाव पड़ता है। आप एक सादृश्य आकर्षित कर सकते हैं: (a = 5)- उदासीन अनुरोध, और (a += 2) - गैर-बेरोजगारी।

यह संपत्ति है जो हमें हितों। यदि क्लाइंट और सर्वर के बीच का कनेक्शन अचानक टूट जाता है, तो क्लाइंट, यह जानकर कि यह विधि बेकार है, स्वचालित रूप से अनुरोध को पुनः भेज सकता है। परदेसी उसी तरह का व्यवहार करते हैं। गैर-निष्पादक अनुरोधों को स्वचालित रूप से दोहराया नहीं जाता है क्योंकि यह ज्ञात नहीं है कि वे सर्वर को कैसे प्रभावित करते हैं और ग्राहक अंत में क्या प्राप्त करेंगे। मुझे लगता है कि हर कोई ब्राउज़र में पॉप-अप जानता है: "क्या आप सुनिश्चित हैं कि आप अनुरोध दोहराना चाहते हैं?"

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

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

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

वह प्राचीन HTTP / 1.1, HTTP / 2 के साथ के रूप में?

HTTP / 2 ने नोड्स के बीच अनुरोध के तरीके को बदल दिया है, लेकिन इसने उनके शाब्दिक अर्थ को नहीं बदला है। इसलिए, उन हमलों में जो अनुरोध मान से संबंधित हैं, HTTP / 2 उसी का व्यवहार करता है। लेकिन "परिवहन" हमलों को फिर से तैयार नहीं किया जाता है, क्योंकि वे पहले से ही मानक में ध्यान में रखे जाते हैं।

कैश पर हमलों को HTTP / 1 के समान तरीके से पुन: पेश किया जाता है, और सुरक्षा समान है।

संदेश कतारबद्ध हमले HTTP / 2 पर लागू नहीं होते हैं । इसमें HTTP संदेश अलग-अलग फ्रेम में विभाजित होते हैं, अलग फ्रेम हेडर के साथ जो स्पष्ट रूप से संदेश की लंबाई और अंत निर्धारित करते हैं। जैसे कि हमलावर विधि नहीं बदलेगा और HTTP हेडर को संशोधित करेगा, इससे संदेश फ़्रेम प्रभावित नहीं होगा। उत्तर चुराना असफल हो जाएगा।

गैर-बेरोजगारी संदेशों की पुनरावृत्ति पर हमले इस तथ्य को ध्यान में रखते हुए भी लागू होते हैं कि HTTP / 2 में हैंअंतिम संसाधित अनुरोध की सूचना तंत्र । HTTP / 2 में, कई अनुरोध एक ही टीसीपी में गुणा किए जाते हैं और इस प्रकार प्रवाह बनाते हैं । प्रत्येक धागे की अपनी संख्या होती है। यदि HTTP / 2 सर्वर डिस्कनेक्ट हो जाता है, तो यह GOAWAY में अंतिम संसाधित अनुरोध की संख्या को इंगित कर सकता है। उच्च संख्या के साथ अनुरोध हमेशा पुनर्निर्देशित करने के लिए सुरक्षित होते हैं, कम संख्या के साथ अनुरोध केवल तभी अनुप्रेषित होते हैं यदि वे बेरोजगार हों। यदि एक ओवरराइड विधि के साथ एक अनुरोध प्रॉक्सी सर्वर के लिए उदासीन दिखता है, तो प्रॉक्सी इसे सर्वर पर भेज देगा।

किसी विधि को सुरक्षित रूप से ओवरराइड कैसे करें

संक्षिप्त उत्तर कोई रास्ता नहीं है। बेहतर है कि मेथड ओवरराइड्स का इस्तेमाल बिल्कुल न किया जाए। और बैकएंड में पूरी तरह से समर्थन को अक्षम करें, यदि कोई हो। HTTP क्लाइंट को तरीकों को ओवरराइड करने से रोकें। प्रॉक्सी / WAF से इंकार करें, जो "अतिरिक्त" तरीकों को काटती है।

यदि आपको किसी तरह से विधि के पुनर्निर्धारण के साथ रहना है, तो बैकएंड के लिए पर्याप्त संपादन को रोकने के लिए। सबसे पहले, यूआरआई के क्वेरी घटक के माध्यम से केवल विधि को ओवरराइड करना उचित है।

दूसरे, तरीकों के परिवर्तन की एक सफेद सूची होनी चाहिए: जो "परिवहन" के रूप में स्वीकार्य हैं और जो परिणामी हैं। जब किसी विधि को किसी भी तरह से ओवरराइड किया जा सकता है तो सामान्यीकृत परिवर्तन कार्य नहीं होने चाहिए। यदि "ट्रांसपोर्ट" विधि में सुरक्षा और सुविधा का गुण नहीं होना चाहिए, यदि परिणामस्वरूप ऐसा नहीं होता है। खतरनाक परिवर्तनों को निषिद्ध किया जाना चाहिए, वही प्रतिस्थापन GET -> HEAD।

क्या मुझे एक समस्या प्रॉक्सी / WAF पैच करने की आवश्यकता है?

यदि प्रॉक्सी केवल GET और POST विधियों को लागू करता है, और एक कारण या किसी अन्य के लिए दूसरों को ब्लॉक करता है, तो निश्चित रूप से हाँ। आप इसे मुख्य रूप से GET और POST के लिए ऑप्टिमाइज़ कर सकते हैं, लेकिन अन्य तरीकों को ब्लॉक करना एक बुरा विचार है। जो अभी भी उत्पाद में अविश्वास की एक खाई पैदा करता है: अगर बुनियादी चीजें अवरुद्ध हो जाती हैं, तो अधिक जटिल समस्याओं के कार्यान्वयन से क्या उम्मीद की जाए?

यदि आप संरक्षित वेब अनुप्रयोगों की सुरक्षा के बारे में चिंतित हैं, तो यह असुरक्षित विधि ओवरराइड नीतियों से अनुप्रयोगों को सुरक्षित करने के लिए सार्थक हो सकता है। बेशक, सामान्य मामले में, वेब एप्लिकेशन कार्यान्वयन के विवरण को जानने के बिना, एप्लिकेशन को गलत ओवरराइड से पूरी तरह से सुरक्षित करना असंभव है, लेकिन आप उन उपयोगकर्ताओं को आंशिक रूप से कवर कर सकते हैं, जो बस समस्या के बारे में नहीं जानते हैं। यह न केवल अपने स्वयं के कैश को विषाक्त करने से बचाने के लिए आवश्यक है, बल्कि प्रत्येक संरक्षित एप्लिकेशन के लिए ओवरराइडिंग को सक्षम या अक्षम करना भी संभव है। ऐसा करने के लिए, आमतौर पर उपयोग किए जाने वाले हेडर का ट्रैक रखें ।X-HTTP-Method, X-HTTP-Method-Override और X-Method-Override। URI के क्वेरी कंपोनेंट में पुनर्परिभाषित को ट्रैक करने का कोई मतलब नहीं है: कैश इस तरह के अनुरोध को जहर नहीं देता है, और क्वेरी बहुत लंबी हो सकती है और पूरी तरह से मनमाना प्रारूप हो सकता है।

?

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

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

एक आफ्टरवर्ड के बजाय

आपको किन प्रॉक्सी सर्वर समस्याओं का सामना करना पड़ा? क्या और कैसे किया गया था?

उपयोगकर्ता प्रतिबंध के माध्यम से सुरक्षा या भेद्यता बनाने के लिए कैसे