मैं Django ऐप को सुरक्षित करने के लिए डेटाबेस अनुमतियों को सही तरीके से कॉन्फ़िगर करने के तरीके पर लिंक, या यहां एक उत्तर की तलाश कर रहा हूं? स्पष्ट होने के लिए, मैं डेटाबेस पर अनुदान के साथ विशेष रूप से सामग्री के लिए देख रहा हूं, Django ढांचे के भीतर अनुमति नहीं है।Django ऐप के लिए डेटाबेस अनुमतियों को कैसे कॉन्फ़िगर करें?
मैं आमतौर पर:
grant all privileges on my_db.* to [email protected] identified by 'my_user_pass'
grant all privileges on test_my_db.* to [email protected] identified by 'my_user_pass'
मुझे लगता है अगर वहाँ Django में एक बग थे, तो आप अपने डेटाबेस को भयानक बातों के लिए खोलने जा सकता है, लेकिन आप अन्य समस्याओं होगा अगर वहाँ थे कि एक सुरक्षा के बड़े django में छेद।
django को न्यूनतम रूप से संचालन के लिए चयन, सम्मिलित, अद्यतन और हटाए जाने की आवश्यकता है। यदि आप टेस्ट या सिंकडब का उपयोग कर रहे हैं, तो आपको टेबल, और इंडेक्स (और शायद एसक्यूएल फिक्स्चर लोड करने के लिए फ़ाइल अनुमति) बनाने में सक्षम होना चाहिए।
तो, एक mysql डीबी के लिए, मुझे लगता है कि अनुमतियों का इष्टतम सेट चुनना, सम्मिलित करना, अद्यतन करना, हटाना, बनाना, अनुक्रमणिका करना और फ़ाइल करना हो सकता है। यदि आप असली नट-किरकिरा प्राप्त करना चाहते हैं, तो आप तालिका स्तर (डीबी स्तर की बजाय) पर उपयुक्त रूप से इन अनुमतियों को अनुदान दे सकते हैं।
व्यक्तिगत रूप से, मुझे grant all ... टाइप करना आसान लगता है।
डीबी स्तर पर अनुमतियों को कॉन्फ़िगर करने का उद्देश्य क्या है? यदि आपके सर्वर से समझौता किया गया है तो हमलावर आपके डेटाबेस के साथ कुछ भी करने में सक्षम होगा (क्योंकि उसके पास लॉगिन/पास है) और अनुमतियां मदद नहीं करेंगे। यदि आपका सर्वर सुरक्षित है तो अनुमतियां बेकार हैं।
यदि आपका डीबी सर्वर बाहरी दुनिया से उपलब्ध है तो अनुमतियां समझ सकती हैं, लेकिन ऐसा करने का अच्छा विचार नहीं है।
डीबी अनुमतियों को जोड़कर आपके पास एक एसक्यूएल इंजेक्शन इत्यादि के हमलों को सीमित करने का अवसर है। यदि वेब सर्वर से समझौता किया गया है तो डीबी अनुमतियों में क्षति को सीमित करने की क्षमता है - उदा। वेब ऐप लॉगिन डेटाबेस डेटाबेस को छोड़ने में सक्षम होने का कोई कारण नहीं है। – emru
एसक्यूएल इंजेक्शन डीजेंगो से बचने में आसान है और मुझे सभी तालिकाओं को साफ़ करने और डेटाबेस को छोड़ने के बीच एक बड़ा अंतर नहीं दिखता है। भेद्यता को खत्म करने के बाद किसी भी तरह से आपका डेटा खो गया है और बैकअप से कुछ भी बहाल करना चाहिए। यह स्पष्ट नहीं है कि डीबी-स्तरीय अनुमतियां आपकी परियोजना को अधिक सुरक्षित बनाती हैं। मुझे लगता है कि डीजेंगो में डीबी-स्तरीय अनुमतियों के लिए अंतर्निहित समर्थन नहीं है क्योंकि वास्तविक समस्याओं को ठीक करने में प्रयास करना बेहतर है: एक्सएसएस, सीएसआरएफ, एसक्यूएल इंजेक्शन इत्यादि और आधे उपायों से खुद को बेवकूफ़ बनाने के लिए नहीं। –
यहां एएसपी.NET ऐप्स के लिए माइक्रोसॉफ्ट की सलाह है "... केवल न्यूनतम अनुमतियां प्रदान करें जिन्हें एप्लिकेशन को कार्य करना होगा।" और सैन्स "... इसका दृष्टिकोण केवल न्यूनतम अनुमतियों को प्रदान करना चाहिए जो एप्लिकेशन को चलाने की आवश्यकता है।" आदि आवेदन स्टैक में किसी भी स्तर पर त्रुटियां हो सकती हैं - आप हमले के प्रचार को रोकने के लिए हर संभव टूल का उपयोग क्यों नहीं करना चाहेंगे। – emru
:
https://docs.djangoproject.com/en/dev/topics/install/
"आप Django के manage.py syncdb आदेश का उपयोग करने के लिए स्वचालित रूप से (प्रथम Django स्थापित करने और एक परियोजना बनाने के बाद) अपने मॉडल के लिए डेटाबेस तालिकाओं बनाने के लिए योजना बना रहे हैं आपको यह सुनिश्चित करने की आवश्यकता होगी कि Django के पास आपके द्वारा उपयोग किए जा रहे डेटाबेस में तालिकाओं को बनाने और बदलने की अनुमति है; यदि आप मैन्युअल रूप से टेबल बनाने की योजना बनाते हैं, तो आप केवल Django SELECT, INSERT, UPDATE और अनुमतियों को हटा सकते हैं। कुछ डेटाबेस पर, Django syncdb के दौरान वैकल्पिक तालिका विशेषाधिकारों की आवश्यकता होगी लेकिन एक बार सिंकडब ने इसे बनाए जाने के बाद एक तालिका पर वैकल्पिक तालिका विवरण जारी नहीं करेंगे। डेटाबेस बनाने के बाद इन अनुमतियों के साथ, आप अपनी परियोजना की सेटिंग्स फ़ाइल में विवरण निर्दिष्ट करेंगे, विवरण के लिए डेटाबेस देखें। "
मैंने अभी MySQL के साथ प्रारंभिक सेटअप का परीक्षण किया है। python manage.py migrate के लिए कम से कम आप सरल ऑपरेशन के लिए निम्नलिखित अनुदान की जरूरत है (यदि यो उपयोग db-तैयारी):
और, द्वारा रास्ता - सुरक्षा मामलों। आप अपने सिस्टम एक्सपोजर को सीमित करके हमले के प्रभाव को कम कर सकते हैं। इस मामले में - आप 'डीआरओपी' को प्रतिबंधित कर सकते हैं - जो काफी बड़ा प्लस है। यदि आप SQL-इंजेक्ट करने की क्षमता के साथ कुछ मुश्किल छेद छोड़ देते हैं - तो आप शायद नुकसान को कम कर सकते हैं। मैं भविष्य में शोध करूंगा यदि यह DELETE कीवर्ड को हटाने के लिए कोई नुकसान नहीं करेगा - इससे संभावित खतरों को भी सीमित कर दिया जाएगा। सिर्फ इसलिए कि हम सभी समय-समय पर बग छोड़ते हैं :)
धन्यवाद सेठ। मैं भी वह करता हूँ। हालांकि, मैं इसे "असली नट-किरकिरा" ढूंढ रहा था जैसा आपने इसे रखा था।मैंने थोड़ी देर पहले वेब पर कुछ देखा जो इसे विस्तार से ढक गया और सार्थक सख्त लग रहा था। अफसोस की बात है कि मैंने इसे बुकमार्क नहीं किया है ... – emru
यह कहने के बिना चला जाता है, लेकिन उपरोक्त के बाद: 'फ्लश विशेषाधिकार;' – mlissner
@mlissner क्या आप समझा सकते हैं? –