MODx क्रांति में सुरक्षा और इसकी समस्याएं

यह विषय सामान्य रूप से MODx क्रांति के सुरक्षा मुद्दों के लिए समर्पित है, साथ ही साथ कनेक्टर और संदर्भ अलग से (क्रांति 2.1.0 रिलीज)।

पृष्ठभूमि: सवाल MODx क्रांति इंजन पर एक गंभीर संसाधन बनाने के लिए पैदा हुआ। हमने तकनीकी समस्याओं को नहीं देखा, लेकिन इंजन के सुरक्षा मुद्दों पर अधिक ध्यान देने का फैसला किया।
ईमानदारी से, मैंने हमेशा MODx क्रांति में सुरक्षा तंत्र को बहुत लचीला और विश्वसनीय माना है, लेकिन यहां मुझे काफी आश्चर्य हुआ ... हम उन्हें यथासंभव और अधिक विस्तार से पार्स करने का प्रयास करेंगे।

जो कोई भी सबसे दिलचस्प बात पढ़ना पसंद करता है, वह शब्दों के साथ पढ़ना शुरू कर देता है "अब संक्षेप में बताएं कि कनेक्टर को काम करने के लिए क्या लगता है ........", क्योंकि समस्या पर पहले विचार नहीं किया गया था, लेकिन समस्या।

यूडीपी: संस्करण 2.1.1 में तय किया गया। लेकिन यह जानने में कि कितना> 2.1.0 कच्चा है, मुझे यकीन है कि उपयोग में क्रांति का 99% हिस्सा पहले रिलीज हैं।


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

1. प्रबंधक / फ़ोल्डर को स्थानांतरित करने की सूक्ष्मताएँ हैं। मैं दोहराना नहीं चाहता, यहाँ पढ़ें
2. उड़ान भरने के लिए कुछ प्लग इन के लिए तैयार रहें। यह विशेष रूप से Directresize प्लगइन के लिए सच है। सबसे पहले, संपत्ति / इसमें हार्ड-कोडित है, और दूसरी बात, फ़ाइल सिस्टम में चित्रों के लिए पथ निरपेक्ष नहीं हैं, लेकिन सापेक्ष हैं, जो त्रुटियों की ओर भी जाता है।
3. अपने कोड में कभी भी कठिन रास्तों को न लिखें, सिस्टम वैरिएबल का उपयोग करना सुनिश्चित करें base_path, core_path, आदि।

इस प्रकार, यह फ़ाइल सिस्टम पर लक्षित जांच से कम से कम आपकी रक्षा करेगा (उदाहरण के लिए, टपका हुआ होस्टिंग पर पड़ोसी खातों से)।

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

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

जारी रखने से पहले, सुरक्षा सिद्धांतों के बारे में थोड़ा:

MODx क्रांति में, नियम हर चीज पर लागू होता है: “यदि अधिकार किसी चीज़ को दिए जाते हैं, तो सिद्धांत that सब कुछ जिसकी अनुमति नहीं है, वह निषिद्ध है’ लागू होता है। और अगर किसी को कुछ भी नहीं सौंपा जाता है, तो हर किसी के लिए सब कुछ संभव है। ”
मैं समझाता हूं: यदि संसाधनों का एक समूह है, जिसके लिए किसी को पहुंच सौंपी जाती है, तो बाकी सभी जिन्हें जंगल में जाने की अनुमति नहीं है। और अगर आपने अभी-अभी समूह बनाने के लिए संसाधनों का एक समूह बनाया है, तो सभी के पास एक पंक्ति में उनकी पहुंच है।
यह प्रतियोगिताओं के साथ भी ऐसा ही है: यदि किसी संदर्भ तक पहुंच सुरक्षा नीतियों के कुछ रोल्स के लिए निर्धारित है, तो बाकी सभी जंगल में जाते हैं। सब कुछ तार्किक है।

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

इसलिए हमने संदर्भ तक पहुंच को अवरुद्ध करने का फैसला किया। मैं चढ़ाई कर रहा हूं, इसका मतलब है कि हमारे नए संदर्भ को संपादित करने के लिए इसका उपयोग करने से इनकार करने के लिए ... और फिर मैं एक छोटे से स्तूप में चला गया ... लेकिन यह कैसे है, इसका उपयोग बंद करने के लिए? प्रसंग की पहुँच किसी अन्य व्यक्ति के लिए, सुपर उपयोगकर्ता भूमिकाओं के लिए निर्धारित है। हालाँकि, सभी की पहुँच है।
प्रतिबिंब पर, मैं समझता हूं कि यह तर्कसंगत है कि उनके पास इसकी पहुंच है, यह एक सार्वजनिक संदर्भ है ... लेकिन फिर भी संदर्भों तक पहुंचने के लिए एक तंत्र क्यों मौजूद है?
बेहतर तरीके से अफवाह फैलाने के बाद, सब कुछ सरल हो गया: यह पता चलता है कि एक्सेस को सार्वजनिक संदर्भों के लिए बिल्कुल भी चेक नहीं किया गया है, एक्सेस को केवल mgr संदर्भ के लिए चेक किया गया है, क्योंकि अनुरोध हैंडलर आमतौर पर अलग होते हैं। यह भी एक अलग लेख है, इसलिए मैं वही लिख रहा हूं जो पहले ही लिखा जा चुका है: MODx Rvolution संदर्भों तक पहुंच के बारे में

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

सब कुछ शांत लग रहा है, लेकिन मुझे आवश्यक कनेक्टर्स लिखने के लिए मिला। मैं सभी नियमों के अनुसार एक कनेक्टर बनाता हूं, कोड लिखता हूं, एक प्रोसेसर बनाता हूं। मैं अनुरोध पूरा करता हूं ... एक खाली उत्तर। यह कनेक्टर्स / index.php फ़ाइल के निष्पादन के कारण है
वहाँ इस तरह के एक कोड है:

if (defined( 'MODX_REQP' ) && MODX_REQP === false ) {
} else if (!$modx->context->checkPolicy( 'load' )) {

@session_write_close();
die();
}



यानी आपके पास 2 विकल्प हैं:

1. परिभाषित कनेक्टर में रजिस्टर करें ('MODX_REQP', गलत); इस मामले में, स्क्रिप्ट को निष्पादित करने के अधिकार के लिए जांच पूरी तरह से अक्षम है। मूर्खता से हर कोई कर सकता है।
2. इस संदर्भ के अधिकार को सही लोड पर असाइन करें। यह अधिक बेहतर है यदि आप कनेक्टर तक पहुंच को प्रतिबंधित करना चाहते हैं। इस मामले में समस्या केवल एक है: अगर पहले मामले में, कोड निष्पादन त्रुटि के मामले में, JSON प्रारूप में एक प्रतिक्रिया दी जाती है, तो एक उत्तर के मामले में कोई जवाब नहीं होगा।

हम दूसरे रास्ते से गए। लेकिन फिर भी, वह अभी भी बीप नहीं करता है। हमने थोड़ी और अफवाह उड़ाई। परिणामस्वरूप, हम इस निष्कर्ष पर पहुंचे कि निम्न पंक्ति की आवश्यकता है: $ _SERVER ['HTTP_MODAUTH'] = $ modx-> site_id; दरअसल, यह चर $ modx-> site_id (जो कि वैश्विक $ site_id भी है) यह लेख लिखने का कारण है। लेकिन उस पर और बाद में ...

सामान्य तौर पर, हम इसे कनेक्टर में लिखते हैं। फिर भी काम नहीं हो रहा है। यह पता चलता है कि एक और चर को $ _REQUEST ['ctx'] = 'reference_id' लिखा जाना चाहिए; और यह सिरदर्द का एक स्रोत है, क्योंकि यदि पंजीकरण करना मुश्किल नहीं है, तो आप कम से कम GET में, कम से कम POST अनुरोध में ctx स्थानांतरित कर सकते हैं। यह वास्तव में संदर्भ कुंजी है।

अब संक्षेप में, क्या काम करने के लिए कनेक्टर की आवश्यकता है और वैश्विक समस्या क्या है:
काम के लिए यह आवश्यक है:

1. $ _REQUEST ['ctx'] - संदर्भ कुंजी किसी भी तरह से पारित;
2. $ site_id - MODx कॉन्फ़िगरेशन में निर्दिष्ट साइट कुंजी, यह $ _SERVER ['HTTP_MODAUTH'] है

तो, चाल: मान लें कि हम कनेक्टर को निष्पादित करते समय सुरक्षा नीति सेटिंग्स का उपयोग करते हैं। हम इसमें अपने संदर्भ का ctx पास करते हैं। सब कुछ शांत है। यह किसके लिए संभव है, यह उसके लिए संभव है, और जिसके लिए यह असंभव है, वह नहीं कर सकता। और यहाँ हम इन्हें लेते हैं, और पंखे से बने ctx = sdfsdfsdfsdfsdfsdfsd को लिखते हैं। वर्तमान में क्या हो रहा है? संदर्भ sdfsdfsdfsdfsdfsdd initialized है (यह जानना दिलचस्प है कि क्या आपके पास एक है?))))। मेरे पास ऐसा कोई संदर्भ नहीं है। और आपको क्या लगता है, सब कुछ टूट गया है? निफेगा !!! MODx संदर्भों के लिए जाँच नहीं करता है। इसके अलावा, वह बिल्कुल भी निफेगा नहीं देखता है! वह मूर्खतापूर्वक संदर्भ सेटिंग्स को लागू करता है sdfsdfsdfsdfsdfsd और संदर्भ सुरक्षा नीति sdfsdfsdfsdfsdfsdfsdfsd! और जब से संदर्भ के लिए कोई सुरक्षा नीतियां नहीं हैं sdfsdfsdfsdfsdfsd, तो (नियम ऊपर कहा याद रखें), अगर कुछ भी निषिद्ध नहीं है, तो सब कुछ संभव है !!! यही है, कनेक्टर चल रहा है।
इसके अलावा। यह पता चला है कि सब कुछ और सब कुछ (व्यवस्थापक पैनल में, जो कि mgr के संदर्भ में) तक पहुंच प्राप्त करने के लिए, आपको लॉगिन / पासवर्ड और अन्य बकवास का एक गुच्छा टाइप नहीं करना होगा। मुख्य बात यह है कि यह बीमार $ $ साइट_ को चुरा रहा है (जो कि वैश्विक रूप से भी कमबख्त है! अर्थात, यह किसी भी $ $ modx के माध्यम से प्राप्त कोड का सबसे घातक टुकड़ा है या यदि आपके पास config.inc.php तक पहुंच है)।
$ Site_id मिलने से आपको क्या मिलेगा? MODx के लिए व्यवस्थापक अनुरोध निष्पादित करने के लिए पूर्ण पहुंच। इसे अपनी साइटों पर स्वयं आज़माएँ। अनधिकृत होने के कारण, कनेक्टर / संसाधन / index.php पर एक साधारण GET अनुरोध भेजें? / HTTP_MODAUTH = {मूल्य $ site_id} & ctx = fgdfgdfg & action = getToolbar। इस स्थिति में, हम HTTP_MODAUTH वैरिएबल के रूप में $ site_id वैरिएबल के मान को प्रतिस्थापित करते हैं (लेकिन यह पर्याप्त नहीं है, क्योंकि mgr प्रसंग अभी भी आरंभीकृत है), और ctx लालटेन चर के लिए हम MODx को एक असम्बद्ध संदर्भ आरंभ करने के लिए बाध्य करते हैं, अर्थात् सुरक्षा सेटिंग्स की कमी को लागू करते हैं। और हां, एक्शन चर के बारे में मत भूलना (आप अपनी साइट के व्यवस्थापक पैनल में खेलकर या MODx ऑफसाइट से रिलीज को डाउनलोड करके एक ही फायरबग का उपयोग करके इन सभी अनुरोधों को आसानी से डीबग कर सकते हैं)। वह सब है! पहुँच दी! बेशक, आपको कुछ दिलचस्प प्रश्न लिखने के लिए चारों ओर खुदाई करनी होगी, लेकिन परिणामस्वरूप, हम आसानी से MODx के अंतर्निहित फ़ाइल प्रबंधक के माध्यम से फ़ाइल सिस्टम तक पहुंच सकते हैं ...

तो दोस्तों, अपनी साइटों को सुरक्षित रखें जिनके पास कुछ महत्वपूर्ण है :-)

वैसे, यह कैसे करना है?
बहुत सरल है। कनेक्टर्स / index.php में कोड को फिर से लिखें

$ctx = isset($_REQUEST[ 'ctx' ]) && !empty($_REQUEST[ 'ctx' ]) ? $_REQUEST[ 'ctx' ] : 'mgr' ;
$modx->initialize($ctx);



पर

/* initialize the proper context */
$ctx = 'mgr' ;
$modx->initialize($ctx);



यह है, संदर्भ को कसकर mgr को इनिशियलाइज़ करें। यह एक उदाहरण है। फिर कार्यों को स्वयं देखें।