पारदर्शी समीपता की कमजोरियाँ, WebSocket अंतिम संस्कार, रद्द करना ...

"वेब सॉकेट्स अस्थायी रूप से रद्द" पढ़ने के बाद, मैं विरोध नहीं कर सका और जवाब देने का फैसला किया।







तो, आईटी के मोर्चों से नवीनतम समाचार। वे चौंकाने वाले हैं।



एडोब फ्लैश में एक गंभीर खुली भेद्यता के कारण, सभी प्रमुख ब्राउज़रों ने इसका समर्थन करने से इनकार कर दिया। हाँ, हाँ अब नेटवर्क पर फ्लैश नहीं होगा, अफसोस। यह मेरे यार्ड में एक बेंच पर बैठे सभी प्रमुख दादी द्वारा कहा गया था।



9 तक के सभी संस्करणों के इंटरनेट एक्सप्लोरर में एक गंभीर खुली भेद्यता के कारण , सभी IE उपयोगकर्ता नेटवर्क पर जाने से इनकार करते हैं। लेआउट डिजाइनरों के लिए नया दुःस्वप्न - अब आपको IE के विभिन्न संस्करणों के लिए साइट संस्करण बनाए रखने की आवश्यकता नहीं है। एक बुरा सपना! अधिग्रहित कौशल के साथ क्या करना है? चौकीदार की खाली जगह कहाँ है?



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



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



अच्छा मजाक किया और इतना ही काफी है। आइए इसे जानने की कोशिश करें।



सबसे पहले, एडम बार्थ का लेख "पारदर्शी परदे के पीछे: खतरा या खतरे" था। यही है, लेखक WebSocket प्रोटोकॉल की जांच नहीं करता है, लेकिन "पारदर्शी प्रोक्सिंग"।



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



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



हम इस निर्णय पर "शुद्धता" के दृष्टिकोण से चर्चा नहीं करेंगे। मान लीजिए कि कुछ पारदर्शी परदे के पीछे एक मेजबान होस्ट में एक अनुरोध को पुनर्निर्देशित करते हैं। इससे क्या होता है?



लेखक आगे एक और दस्तावेज़ को संदर्भित करता है।



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



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



हमें दो समस्याएं मिलती हैं:



1. दुर्भावनापूर्ण फ़्लैश एप्लिकेशन अब किसी भी वेब सर्वर तक पहुंच सकता है, और न केवल वह है जिसमें से इसे डाउनलोड किया गया था;



2. यदि प्रॉक्सी प्रतिक्रिया को कैश करता है, तो किसी भी क्लाइंट से एक अच्छे सर्वर के बाद के अनुरोधों को एक दुर्भावनापूर्ण कैश्ड प्रतिक्रिया प्राप्त होगी।



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



और Luzhkov WebSocket कहाँ है? इससे कुछ लेना-देना नहीं। आगे बढ़ो। युवा RFC मर्मोट्स के विश्वकोश पर एक नज़र डालें। हम RFC 1919 में दिलचस्पी लेंगे, जो पारदर्शी परदे के पीछे परिभाषित करता है। हम पढ़ते हैं:



4.2.3 DNS requirements



In transparent proxy configurations, client systems MUST be

able to resolve server names belonging to remote networks. This

is critical since the proxy will determine the target server

from the destination IP address of the packets arriving from

the client.











यही है, मानक असमान रूप से बताता है कि अनुरोध के आईपी पते को लेना आवश्यक है, और मेजबान क्षेत्र से नहीं ।



फिर, ऐसा लगता है, WebSocket को दोष नहीं देना है। ठीक है, लेखक द्वारा मूल लेख पर वापस।



लेखकों ने एक प्रयोग किया। उन्होंने लोगों को एक विज्ञापन बैनर दिया जो एक समान योजना को क्रैंक करने की कोशिश की: एक "अलग" होस्ट के साथ एक HTTP अनुरोध भेजें। फ्लैश और जावा एप्लिकेशन दोनों का उपयोग किया गया था। प्रयोग से पता चला कि "दुर्भावनापूर्ण" फ्लैश का उपयोग करने वाले अनुरोधों में से 2.2% (363305 में से 803) और "दुर्भावनापूर्ण" जावा वर्ग का उपयोग करने वाले अनुरोधों के 3.6% (1212) को HTTP हेडर में होस्ट करने के लिए पुनर्निर्देशित किया गया था, और आईपी पते पर नहीं।



इसके अलावा, लेखक WebSocket प्रोटोकॉल का उपयोग करके प्रॉक्सी को "ट्रिक" करने की कोशिश करते हैं। यदि पारदर्शी प्रॉक्सी को WebSocket के बारे में कुछ नहीं पता है, तो ग्राहक निम्नलिखित फ़ॉर्म का एक संदेश WebSocket हैंडशेक पर भेज सकता है:



GET /sensitive-document HTTP/1.1

Host: victim.com









चूंकि दुर्भाग्यपूर्ण प्रॉक्सी WebSocket के बारे में कुछ नहीं जानता है, इसलिए यह तय करेगा कि यह एक और HTTP अनुरोध है। और वह पीड़ित.कॉम पर "जाएगा" और उसे वहां स्थानांतरित कर देगा। लेखकों के प्रयोग से पता चला कि 2.8% प्रॉक्सी ने ऐसा किया (49218 में से 1376)। इसके अलावा, प्रयोग अनिवार्य रूप से दोहराया गया था।



इसलिए, यह दावा किया जाता है कि WebSocket असुरक्षित है, गलत है ।



सुरक्षा उल्लंघनों का उदय होता है क्योंकि पारदर्शी प्रॉक्सी वेबस्केट को नहीं जानते हैं और RFC 1919 का उल्लंघन करते हैं ।



अध्ययन के लेखक अपने समाधान की पेशकश करते हैं: WebSocket के लिए HTTP कनेक्ट कमांड का उपयोग करें। उनके प्रयोग से पता चला है कि _all_ पारदर्शी परदे के पीछे "अच्छी तरह से" काम करते हैं। उनका मानना ​​है कि अंदर HTTPS डेटा होगा और इसे पार्स करने की कोशिश न करें। अनुरोध स्रोत आईपी पर जाते हैं।



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



अनुरोध शीर्षलेख के होस्ट फ़ील्ड में निर्दिष्ट आईपी पते के लिए लगभग 3% पारदर्शी प्रॉक्सी रूट HTTP अनुरोध। यह RFC 1919 मानक का उल्लंघन है। रूट को स्रोत IP पते पर किया जाना चाहिए, जिसके लिए अनुरोध भेजा गया था।



यह व्यवहार दुर्भावनापूर्ण फ़्लैश एप्लिकेशन, जावा एप्लेट या जावास्क्रिप्ट को किसी भी साइट तक पहुँचने (समान उत्पत्ति नीति के उल्लंघन का उल्लंघन) की अनुमति देता है और इन प्रॉक्सी के कैश से समझौता करता है।



एक दुर्भावनापूर्ण जावास्क्रिप्ट स्क्रिप्ट केवल तभी नुकसान पहुंचा सकती है जब ब्राउज़र वेब पॉकेट का समर्थन करता है। फ़्लैश एप्लिकेशन और जावा एप्लेट को नुकसान पहुंचाने के लिए वेबसॉफ़्ट ब्राउज़र समर्थन की आवश्यकता नहीं है



एक हैंडशेक WebSocket (कुछ सुधारों के साथ) में CONNECT कमांड पर स्विच करने से आप WebSocket के मामले में "छेद को बंद" कर सकेंगे ...



... लेकिन फल-फूल और जाव का उपयोग करने के लिए SOP का सहारा लें और PROXY CACHE STAYS पोस्सेबल को ट्रांसपेरेंट PROXIS BREAK को RCF 1919 में डालें।



व्याकुलता के लिए चित्र।







पुनश्च



जोड़ना भूल गए। ओपेरा और फायरफॉक्स के डेवलपर्स को डर के लिए समझने की जरूरत है कि सुरक्षा के निम्नलिखित को व्यवस्थित होना चाहिए, अर्थात्।



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



और इसलिए यह एक सस्ते पीआर चाल की तरह दिखता है:



“देखो, हम सुरक्षा की परवाह करते हैं। हमने अपने ब्राउज़र में एक छिद्रपूर्ण फ़्लैश छोड़ दिया, लेकिन हमने WebSocket को निष्क्रिय कर दिया और अब आप सुरक्षित हैं। "



पीएसएस



थोड़ा ट्वीक किया। मुझे उम्मीद है कि यह स्पष्ट हो गया है ...