Django 2.1 - Security in Django

Django में सुरक्षा




django

Django में सुरक्षा

यह दस्तावेज़ Django की सुरक्षा विशेषताओं का अवलोकन है। इसमें एक Django संचालित साइट हासिल करने की सलाह शामिल है।

क्रॉस साइट स्क्रिप्टिंग (XSS) सुरक्षा

XSS हमलों से उपयोगकर्ता को अन्य उपयोगकर्ताओं के ब्राउज़र में क्लाइंट साइड स्क्रिप्ट को इंजेक्ट करने की अनुमति मिलती है। यह आमतौर पर डेटाबेस में दुर्भावनापूर्ण स्क्रिप्ट को संग्रहीत करके प्राप्त किया जाता है जहां इसे पुनर्प्राप्त किया जाएगा और अन्य उपयोगकर्ताओं को प्रदर्शित किया जाएगा, या उपयोगकर्ताओं को एक लिंक पर क्लिक करने के लिए जो उपयोगकर्ता के ब्राउज़र द्वारा हमलावर के जावास्क्रिप्ट को निष्पादित करने का कारण होगा। हालाँकि, XSS हमले डेटा के किसी भी अविश्वसनीय स्रोत, जैसे कुकीज़ या वेब सेवाओं से उत्पन्न हो सकते हैं, जब भी डेटा को पृष्ठ में शामिल करने से पहले पर्याप्त रूप से स्वच्छता नहीं की जाती है।

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

Django टेम्प्लेट विशिष्ट वर्णों से बचते हैं जो विशेष रूप से HTML के लिए खतरनाक हैं। हालांकि यह उपयोगकर्ताओं को अधिकांश दुर्भावनापूर्ण इनपुट से बचाता है, लेकिन यह पूरी तरह से मूर्ख नहीं है। उदाहरण के लिए, यह निम्नलिखित की रक्षा नहीं करेगा:

<style class={{ var }}>...</style>

यदि var को 'class1 onmouseover=javascript:func()' , तो यह अनधिकृत जावास्क्रिप्ट निष्पादन के परिणामस्वरूप हो सकता है, यह इस बात पर निर्भर करता है कि ब्राउज़र HTML को कैसे अपूर्ण करता है। (विशेषता मान का उद्धरण इस मामले को ठीक करेगा।)

कस्टम टेम्पलेट टैग के साथ is_safe , safe टेम्पलेट टैग, mark_safe , और जब autoescape बंद हो जाता है, तब विशेष रूप से सावधान रहना भी महत्वपूर्ण है।

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

डेटाबेस में HTML स्टोर करते समय आपको बहुत सावधान रहना चाहिए, खासकर जब HTML पुनः प्राप्त और प्रदर्शित होता है।

क्रॉस साइट अनुरोध जालसाजी (CSRF) संरक्षण

CSRF हमले एक दुर्भावनापूर्ण उपयोगकर्ता को उस उपयोगकर्ता के ज्ञान या सहमति के बिना किसी अन्य उपयोगकर्ता की साख का उपयोग करके कार्यों को निष्पादित करने की अनुमति देते हैं।

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

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

HTTPS साथ तैनात होने पर, CsrfViewMiddleware जाँच करेगा कि HTTP CsrfViewMiddleware हेडर एक URL पर एक ही मूल (सबडोमेन और पोर्ट सहित) पर सेट है। क्योंकि HTTPS अतिरिक्त सुरक्षा प्रदान करता है, इसलिए यह सुनिश्चित करना आवश्यक है कि कनेक्शन HTTPS का उपयोग करें जहाँ यह असुरक्षित कनेक्शन अनुरोधों को अग्रेषित करने और समर्थित ब्राउज़रों के लिए HSTS का उपयोग करके उपलब्ध है।

csrf_exempt डेकोरेटर के साथ विचारों को चिह्नित करने के साथ बहुत सावधान रहें जब तक कि यह बिल्कुल आवश्यक न हो।

एसक्यूएल इंजेक्शन सुरक्षा

SQL इंजेक्शन एक प्रकार का हमला है जहां एक दुर्भावनापूर्ण उपयोगकर्ता डेटाबेस पर मनमाने ढंग से SQL कोड निष्पादित करने में सक्षम होता है। इसके परिणामस्वरूप रिकॉर्ड हटाए जा सकते हैं या डेटा रिसाव हो सकता है।

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

Django भी डेवलपर्स को कच्चे प्रश्न लिखने या कस्टम sql निष्पादित करने की शक्ति देता है। इन क्षमताओं को संयम से इस्तेमाल किया जाना चाहिए और उपयोगकर्ता को नियंत्रित करने वाले किसी भी पैरामीटर को ठीक से बचने के लिए आपको हमेशा सावधान रहना चाहिए। इसके अलावा, आपको extra() और RawSQL का उपयोग करते समय सावधानी बरतनी चाहिए।

क्लिकजैकिंग सुरक्षा

क्लिकजैकिंग एक प्रकार का हमला है जिसमें एक दुर्भावनापूर्ण साइट किसी अन्य साइट को एक फ्रेम में लपेटती है। इस हमले के परिणामस्वरूप एक असुरक्षित उपयोगकर्ता को लक्षित साइट पर अनजाने कार्यों को करने में धोखा दिया जा सकता है।

Django में X-Frame-Options middleware के रूप में क्लिकजैकिंग प्रोटेक्शन होता है जो एक सपोर्टिंग ब्राउजर में किसी साइट को फ्रेम के अंदर रेंडर होने से रोक सकता है। प्रति दृश्य आधार पर सुरक्षा को अक्षम करना या भेजे गए सटीक हेडर मान को कॉन्फ़िगर करना संभव है।

किसी भी साइट के लिए मिडलवेयर की जोरदार सिफारिश की जाती है, जिसे अपने पेज को थर्ड पार्टी साइट्स द्वारा फ्रेम में लपेटने की आवश्यकता नहीं होती है, या केवल साइट के एक छोटे से भाग के लिए अनुमति देने की आवश्यकता होती है।

SSL / HTTPS

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

यदि आप HTTPS द्वारा प्रदान की जाने वाली सुरक्षा चाहते हैं, और इसे अपने सर्वर पर सक्षम किया है, तो कुछ अतिरिक्त कदम हैं जिनकी आपको आवश्यकता हो सकती है:

  • यदि आवश्यक हो, तो SECURE_PROXY_SSL_HEADER सेट SECURE_PROXY_SSL_HEADER , यह सुनिश्चित करते हुए कि आप वहां चेतावनी को अच्छी तरह से समझ चुके हैं। ऐसा करने में विफलता CSRF कमजोरियों का परिणाम हो सकती है, और इसे सही ढंग से करने में विफलता भी खतरनाक हो सकती है!
  • SECURE_SSL_REDIRECT को True सेट करें, ताकि HTTP पर अनुरोध HTTPS पर पुनर्निर्देशित हो।

    कृपया SECURE_PROXY_SSL_HEADER तहत चेतावनी पर ध्यान दें। रिवर्स प्रॉक्सी के मामले में, HTTPS पर रीडायरेक्ट करने के लिए मुख्य वेब सर्वर को कॉन्फ़िगर करना आसान या अधिक सुरक्षित हो सकता है।

  • 'सुरक्षित' कुकीज़ का उपयोग करें।

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

  • HTTP सख्त परिवहन सुरक्षा (HSTS) का उपयोग करें

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

होस्ट हेडर सत्यापन

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

क्योंकि यहां तक ​​कि प्रतीत होता है कि सुरक्षित वेब सर्वर कॉन्फ़िगरेशन नकली Host हेडर के लिए अतिसंवेदनशील होते हैं, Django Host हेडर को django.http.HttpRequest.get_host() विधि में ALLOWED_HOSTS सेटिंग के खिलाफ सत्यापित करता है।

यह सत्यापन केवल django.http.HttpRequest.get_host() माध्यम से लागू होता है django.http.HttpRequest.get_host() ; यदि आपका कोड सीधे request.META से Host हेडर तक पहुंचता है। तो आप इस सुरक्षा संरक्षण को दरकिनार कर रहे हैं।

अधिक जानकारी के लिए पूर्ण ALLOWED_HOSTS दस्तावेज़ देखें।

चेतावनी

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

इसके अतिरिक्त, यदि आपके कॉन्फ़िगरेशन की आवश्यकता होती है, तो Django आपको X-Forwarded-Host USE_X_FORWARDED_HOST X-Forwarded-Host हेडर ( USE_X_FORWARDED_HOST सेटिंग के माध्यम से) के लिए समर्थन को स्पष्ट रूप से सक्षम करने की आवश्यकता है।

सत्र सुरक्षा

limitations समान ही एक साइट की आवश्यकता होती है, जिसमें ऐसे django.contrib.sessions उपयोगकर्ता किसी भी उप-डोमेन तक नहीं पहुँच django.contrib.sessions हैं, django.contrib.sessions भी सीमाएँ हैं। विवरण के लिए सुरक्षा पर सत्र विषय गाइड अनुभाग देखें।

उपयोगकर्ता द्वारा अपलोड की गई सामग्री

ध्यान दें

इन कुछ मुद्दों से बचने के लिए क्लाउड सेवा या CDN से स्थिर फ़ाइलों की सेवा करने पर विचार करें।

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

    सभी उपयोगकर्ता अपलोड की गई फ़ाइल सामग्री को सुरक्षित रूप से सत्यापित करने के लिए कोई बुलेटप्रूफ तकनीकी समाधान मौजूद नहीं है, हालांकि, इन हमलों को कम करने के लिए कुछ अन्य कदम हैं:

    1. हमलों के एक वर्ग को हमेशा एक अलग शीर्ष-स्तर या दूसरे-स्तरीय डोमेन से उपयोगकर्ता द्वारा अपलोड की गई सामग्री परोसकर रोका जा सकता है। यह क्रॉस-साइट स्क्रिप्टिंग जैसे समान-मूल नीति सुरक्षा द्वारा अवरुद्ध किसी भी शोषण को रोकता है। उदाहरण के लिए, यदि आपकी साइट example.com पर चलती है, तो आप usercontent-example.com जैसी किसी चीज़ से अपलोड की गई सामग्री ( MEDIA_URL सेटिंग) MEDIA_URL चाहेंगे। यह usercontent.example.com जैसे उपडोमेन से सामग्री परोसने के लिए पर्याप्त नहीं है
    2. इसके अलावा, एप्लिकेशन उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों के लिए स्वीकार्य फ़ाइल एक्सटेंशन के श्वेतसूची को परिभाषित करने के लिए चुन सकते हैं और केवल ऐसी फ़ाइलों की सेवा के लिए वेब सर्वर को कॉन्फ़िगर कर सकते हैं।

अतिरिक्त सुरक्षा विषय

जबकि Django बॉक्स से बाहर अच्छी सुरक्षा सुरक्षा प्रदान करता है, फिर भी आपके एप्लिकेशन को ठीक से तैनात करना और वेब सर्वर, ऑपरेटिंग सिस्टम और अन्य घटकों की सुरक्षा सुरक्षा का लाभ उठाना महत्वपूर्ण है।

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