Django 2.1 - Cross Site Request Forgery protection

क्रॉस साइट रिक्वेस्ट फॉरगिरी प्रोटेक्शन




django

क्रॉस साइट रिक्वेस्ट फॉरगिरी प्रोटेक्शन

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

CSRF के हमलों के खिलाफ पहला बचाव यह सुनिश्चित करना है कि GFC अनुरोध (और अन्य 'सुरक्षित' तरीके, जैसा कि RFC 7231 # अनुभाग-4.2.1 द्वारा परिभाषित किया गया है) साइड इफेक्ट मुक्त हैं। POST, PUT और DELETE जैसे 'असुरक्षित' विधियों के माध्यम से अनुरोध, फिर नीचे दिए गए चरणों का पालन करके संरक्षित किया जा सकता है।

इसे कैसे उपयोग करे

अपने विचारों में CSRF सुरक्षा का लाभ उठाने के लिए, इन चरणों का पालन करें:

  1. MIDDLEWARE सेटिंग में CSRF मिडलवेयर डिफ़ॉल्ट रूप से सक्रिय होता है। यदि आप उस सेटिंग को ओवरराइड करते हैं, तो याद रखें कि 'django.middleware.csrf.CsrfViewMiddleware' को किसी भी दृश्य मिडलवेयर से पहले आना चाहिए जो यह मानता है कि CSRF के हमलों से निपटा गया है।

    यदि आपने इसे अक्षम कर दिया है, जिसकी अनुशंसा नहीं की गई है, तो आप उन विशेष विचारों पर csrf_protect() उपयोग कर सकते हैं, csrf_protect() आप सुरक्षित करना चाहते हैं (नीचे देखें)।

  2. POST फॉर्म का उपयोग करने वाले किसी भी टेम्पलेट में, <form> URL <form> तत्व के अंदर csrf_token टैग का उपयोग करें यदि फॉर्म आंतरिक URL के लिए है, जैसे:

    <form method="post">{% csrf_token %}
    

    यह बाहरी URL को लक्षित करने वाले POST रूपों के लिए नहीं किया जाना चाहिए, क्योंकि इससे CSRF टोकन लीक हो जाएगा, जिससे एक भेद्यता हो सकती है।

  3. संबंधित दृश्य कार्यों में, सुनिश्चित करें कि {% csrf_token %} को रेंडर करने के लिए RequestContext का उपयोग किया जाता है ताकि {% csrf_token %} ठीक से काम करे। यदि आप render() फंक्शन, जेनेरिक व्यूज़ या कंट्रीब ऐप्स का उपयोग कर रहे हैं, तो आप पहले से ही कवर हैं क्योंकि ये सभी RequestContext उपयोग करते हैं।

AJAX

जबकि AJAX POST अनुरोधों के लिए उपरोक्त विधि का उपयोग किया जा सकता है, इसमें कुछ असुविधाएँ हैं: आपको हर POST अनुरोध के साथ POST डेटा के रूप में CSRF टोकन पास करना याद रखना होगा। इस कारण से, एक वैकल्पिक विधि है: प्रत्येक XMLHttpRequest पर, CSRF टोकन के मान के लिए एक कस्टम X-CSRFToken हैडर सेट करें। यह अक्सर आसान होता है, क्योंकि कई जावास्क्रिप्ट फ्रेमवर्क हुक प्रदान करते हैं जो हेडर को हर अनुरोध पर सेट करने की अनुमति देते हैं।

सबसे पहले, आपको CSRF टोकन प्राप्त करना होगा। कैसे करें कि CSRF_USE_SESSIONS सेटिंग सक्षम है या नहीं, इस पर निर्भर करता है।

टोकन प्राप्त करना अगर CSRF_USE_SESSIONS False

टोकन के लिए अनुशंसित स्रोत csrftoken कुकी है, जिसे यदि आपने ऊपर उल्लिखित अपने विचारों के लिए CSRF सुरक्षा सक्षम किया है, तो सेट किया जाएगा।

ध्यान दें

CSRF टोकन कुकी को डिफ़ॉल्ट रूप से csrftoken नाम csrftoken गया है, लेकिन आप CSRF_COOKIE_NAME सेटिंग के माध्यम से कुकी नाम को नियंत्रित कर सकते हैं।

CSRF हेडर का नाम HTTP_X_CSRFTOKEN डिफ़ॉल्ट रूप से है, लेकिन आप CSRF_HEADER_NAME सेटिंग का उपयोग करके इसे अनुकूलित कर सकते हैं।

टोकन प्राप्त करना सीधा है:

// using jQuery
function getCookie(name) {
    var cookieValue = null;
    if (document.cookie && document.cookie !== '') {
        var cookies = document.cookie.split(';');
        for (var i = 0; i < cookies.length; i++) {
            var cookie = jQuery.trim(cookies[i]);
            // Does this cookie string begin with the name we want?
            if (cookie.substring(0, name.length + 1) === (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}
var csrftoken = getCookie('csrftoken');

getCookie को बदलने के लिए जावास्क्रिप्ट कुकी लाइब्रेरी का उपयोग करके उपरोक्त कोड को सरल बनाया जा सकता है:

var csrftoken = Cookies.get('csrftoken');

ध्यान दें

CSRF टोकन DOM में भी मौजूद है, लेकिन केवल अगर टेम्पलेट में csrf_token का उपयोग करके स्पष्ट रूप से शामिल किया गया हो। कुकी में विहित टोकन होता है; CsrfViewMiddleware में CsrfViewMiddleware कुकी को टोकन के लिए पसंद करेगा। भले ही, आपको कुकी की गारंटी दी जाती है यदि डोम डोम में मौजूद है, तो आपको कुकी का उपयोग करना चाहिए!

चेतावनी

यदि आपका दृश्य csrf_token टेम्पलेट टैग वाले टेम्पलेट को प्रस्तुत नहीं कर रहा है, तो Django CSRF टोकन कुकी सेट नहीं कर सकता है। यह उन मामलों में सामान्य है जहां प्रपत्र गतिशील रूप से पृष्ठ पर जोड़े जाते हैं। इस मामले को संबोधित करने के लिए, Django एक व्यू डेकोरेटर प्रदान करता है जो कुकी की सेटिंग को मजबूर करता है: ensure_csrf_cookie()

टोकन प्राप्त करना अगर CSRF_USE_SESSIONS True

यदि आप CSRF_USE_SESSIONS सक्रिय CSRF_USE_SESSIONS , तो आपको अपने HTML में CSRF टोकन को शामिल करना होगा और जावास्क्रिप्ट के साथ DOM से टोकन पढ़ना होगा:

{% csrf_token %}
<script type="text/javascript">
// using jQuery
var csrftoken = jQuery("[name=csrfmiddlewaretoken]").val();
</script>

AJAX अनुरोध पर टोकन सेट करना

अंत में, आपको वास्तव में अपने AJAX अनुरोध पर हेडर सेट करना होगा, जबकि jQuery 1.5.1 और नए में settings.crossDomain का उपयोग करके CSRF टोकन को अन्य डोमेन पर भेजे जाने से बचाता है:

function csrfSafeMethod(method) {
    // these HTTP methods do not require CSRF protection
    return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
$.ajaxSetup({
    beforeSend: function(xhr, settings) {
        if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
            xhr.setRequestHeader("X-CSRFToken", csrftoken);
        }
    }
});

यदि आप AngularJS 1.1.3 और नए का उपयोग कर रहे हैं, तो कुकी और हेडर नामों के साथ $http प्रदाता को कॉन्फ़िगर करना पर्याप्त है:

$httpProvider.defaults.xsrfCookieName = 'csrftoken';
$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';

Jinja2 टेम्पलेट्स में CSRF का उपयोग करना

Django के Jinja2 टेम्प्लेट बैकेंड में सभी टैम्प्लेट के संदर्भ में {{ csrf_input }} जाता है, जो Django टेम्पलेट भाषा में {% csrf_token %} बराबर है। उदाहरण के लिए:

<form method="post">{{ csrf_input }}

डेकोरेटर विधि

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

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

csrf_protect(view)

डेकोरेटर जो एक दृश्य को CsrfViewMiddleware की सुरक्षा प्रदान करता है।

उपयोग:

from django.shortcuts import render
from django.views.decorators.csrf import csrf_protect

@csrf_protect
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)

यदि आप वर्ग-आधारित विचारों का उपयोग कर रहे हैं, तो आप सजाने-आधारित वर्ग-आधारित विचारों को संदर्भित कर सकते हैं।

अस्वीकृत अनुरोध

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

हालाँकि, त्रुटि पृष्ठ बहुत अनुकूल नहीं है, इसलिए आप इस स्थिति से निपटने के लिए अपना दृष्टिकोण प्रदान करना चाह सकते हैं। ऐसा करने के लिए, बस CSRF_FAILURE_VIEW सेटिंग सेट करें।

CSRF विफलताओं को django.security.csrf को चेतावनी के रूप में लॉग किया जाता है।

यह काम किस प्रकार करता है

CSRF सुरक्षा निम्नलिखित बातों पर आधारित है:

  1. एक CSRF कुकी जो एक यादृच्छिक गुप्त मूल्य पर आधारित है, जिसकी अन्य साइटों तक पहुंच नहीं होगी।

    यह कुकी CsrfViewMiddleware द्वारा सेट की गई है। यह हर प्रतिक्रिया के साथ भेजा जाता है जिसे django.middleware.csrf.get_token() (CSRF टोकन प्राप्त करने के लिए आंतरिक रूप से उपयोग किया जाने वाला फ़ंक्शन django.middleware.csrf.get_token() कहा जाता है, अगर यह पहले से ही अनुरोध पर सेट नहीं किया गया था।

    BREACH हमलों से बचाने के लिए, टोकन केवल रहस्य नहीं है; एक बेतरतीब नमक राज़ से जुड़ा हुआ है और इसका इस्तेमाल किया जाता है।

    सुरक्षा कारणों से, उपयोगकर्ता द्वारा लॉग इन करने पर हर बार रहस्य का मूल्य बदल जाता है।

  2. सभी आउटगोइंग POST रूपों में मौजूद 'csrfmiddlewaretoken' नाम के साथ एक छिपा हुआ फॉर्म फ़ील्ड। इस क्षेत्र का मूल्य, फिर से, रहस्य का मूल्य है, एक नमक के साथ जो इसे दोनों में जोड़ा जाता है और इसका इस्तेमाल किया जाता है। प्रत्येक कॉल पर get_token() लिए नमक पुनर्जीवित किया जाता है ताकि इस तरह की प्रतिक्रिया में फॉर्म फ़ील्ड मान बदल जाए।

    यह भाग टेम्प्लेट टैग द्वारा किया जाता है।

  3. आने वाले सभी अनुरोधों के लिए जो HTTP GET, HEAD, OPTIONS या TRACE का उपयोग नहीं कर रहे हैं, एक CSRF कुकी मौजूद होनी चाहिए, और 'csrfmiddlewaretoken' फ़ील्ड मौजूद और सही होनी चाहिए। यदि ऐसा नहीं है, तो उपयोगकर्ता को 403 त्रुटि मिलेगी।

    'Csrfmiddlewaretoken' फ़ील्ड मान को सत्यापित करते समय, केवल गुप्त, पूर्ण टोकन नहीं, कुकी मूल्य में रहस्य के साथ तुलना की जाती है। यह कभी-कभी बदलते टोकन के उपयोग की अनुमति देता है। हालांकि प्रत्येक अनुरोध अपने स्वयं के टोकन का उपयोग कर सकता है, लेकिन रहस्य सभी के लिए सामान्य रहता है।

    यह जाँच CsrfViewMiddleware द्वारा की CsrfViewMiddleware

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

    यह एक मानव-में-मध्य हमले को भी संबोधित करता है जो एक सत्र स्वतंत्र रहस्य का उपयोग करते समय HTTPS के तहत संभव है, इस तथ्य के कारण कि HTTP Set-Cookie हेडर (दुर्भाग्य से) क्लाइंट द्वारा स्वीकार किए जाते हैं, तब भी जब वे HTTPS के तहत किसी साइट पर बात कर रहे हों । (HTTP जाँच अनुरोधों के लिए रेफ़र की जाँच नहीं की जाती है क्योंकि Referer शीर्षलेख की उपस्थिति HTTP के अंतर्गत पर्याप्त विश्वसनीय नहीं है।)

    यदि CSRF_COOKIE_DOMAIN सेटिंग सेट की जाती है, तो इसके विरुद्ध संदर्भकर्ता की तुलना की जाती है। यह सेटिंग उप-डोमेन का समर्थन करती है। उदाहरण के लिए, CSRF_COOKIE_DOMAIN = '.example.com' www.example.com और api.example.com से POST अनुरोधों की अनुमति देगा। यदि सेटिंग सेट नहीं है, तो रेफ़र को HTTP Host हेडर से मेल खाना चाहिए।

    वर्तमान होस्ट या कुकी डोमेन से परे स्वीकार किए गए CSRF_TRUSTED_ORIGINS का CSRF_TRUSTED_ORIGINS सेटिंग से किया जा सकता है।

यह सुनिश्चित करता है कि केवल ऐसे फॉर्म जो विश्वसनीय डोमेन से उत्पन्न हुए हैं, उन्हें वापस पोस्ट डेटा के लिए इस्तेमाल किया जा सकता है।

यह GET के अनुरोधों (और RFC 7231 द्वारा 'सुरक्षित' के रूप में परिभाषित किए गए अन्य अनुरोधों) को जानबूझकर अनदेखा करता है। इन अनुरोधों पर कभी भी कोई संभावित खतरनाक दुष्प्रभाव नहीं होना चाहिए, और इसलिए GET अनुरोध के साथ CSRF का हमला हानिरहित होना चाहिए। RFC 7231 POST, PUT, और DELETE को 'असुरक्षित' के रूप में परिभाषित करता है, और अन्य सभी तरीकों को भी अधिकतम सुरक्षा के लिए असुरक्षित माना जाता है।

CSRF सुरक्षा मैन-इन-द-बीच हमलों से सुरक्षा नहीं कर सकती है, इसलिए HTTP सख्त परिवहन सुरक्षा के साथ HTTPS उपयोग करें। यह HOST हेडर के सत्यापन को भी मानता है और आपकी साइट पर कोई भी क्रॉस-साइट स्क्रिप्टिंग भेद्यता नहीं है (क्योंकि XSS भेद्यता पहले से ही एक हमलावर को कुछ भी करने देती है CSRF भेद्यता की अनुमति देता है और बहुत बुरा होता है)।

Referer शीर्षलेख निकाल रहा है

तृतीय-पक्ष साइटों के लिए रेफ़रर URL का खुलासा करने से बचने के लिए, आप अपनी साइट के <a> टैग पर रेफ़र को अक्षम करना चाह सकते हैं। उदाहरण के लिए, आप <meta name="referrer" content="no-referrer"> टैग का उपयोग कर सकते हैं या Referrer-Policy: no-referrer शीर्ष लेख शामिल कर सकते हैं। HTTPS अनुरोधों पर CSRF सुरक्षा के सख्त रेफर चेकिंग के कारण, उन तकनीकों के कारण 'असुरक्षित' तरीकों से अनुरोधों पर CSRF की विफलता होती है। इसके बजाय, तृतीय-पक्ष साइटों के लिंक के लिए <a rel="noreferrer" ...>" जैसे विकल्पों का उपयोग करें।

कैशिंग

यदि csrf_token टेम्प्लेट टैग का उपयोग टेम्पलेट द्वारा किया जाता है (या get_token फ़ंक्शन को किसी अन्य तरीके से कहा जाता है), CsrfViewMiddleware एक कुकी और एक Vary: Cookie जोड़ देगा Vary: Cookie शीर्ष लेख की प्रतिक्रिया। इसका मतलब यह है कि यदि निर्देश के रूप में उपयोग किया जाता है तो मिडिलवेयर कैश मिडिलवेयर के साथ अच्छा खेलेगा ( UpdateCacheMiddleware अन्य सभी मिडलवेयर से पहले जाता है)।

हालाँकि, यदि आप अलग-अलग विचारों पर कैश डेकोरेटर्स का उपयोग करते हैं, तो CSRF मिडलवेयर अभी तक वैरी हेडर या CSRF कुकी सेट नहीं कर पाएगा, और प्रतिक्रिया बिना किसी एक के बंद हो जाएगी। इस स्थिति में, किसी भी ऐसे विचार पर, जिसमें आपको सम्मिलित किए जाने के लिए CSRF टोकन की आवश्यकता होगी, आपको पहले csrf_protect() डेकोरेटर का उपयोग करना चाहिए:

from django.views.decorators.cache import cache_page
from django.views.decorators.csrf import csrf_protect

@cache_page(60 * 15)
@csrf_protect
def my_view(request):
    ...

यदि आप वर्ग-आधारित विचारों का उपयोग कर रहे हैं, तो आप सजाने-आधारित वर्ग-आधारित विचारों को संदर्भित कर सकते हैं।

परिक्षण

CSRF टोकन की आवश्यकता के कारण, जो कि हर POST अनुरोध के साथ भेजा जाना चाहिए, CsrfViewMiddleware आम तौर पर दृश्य कार्यों के परीक्षण में एक बड़ी बाधा होगी। इस कारण से, परीक्षणों के लिए Django के HTTP क्लाइंट को अनुरोधों पर एक ध्वज सेट करने के लिए संशोधित किया गया है जो मिडलवेयर और csrf_protect डेकोरेटर को आराम देता है ताकि वे अब अनुरोधों को अस्वीकार न करें। हर दूसरे सम्मान में (जैसे कुकीज़ आदि भेजना), वे एक जैसा व्यवहार करते हैं।

यदि, किसी कारण से, आप चाहते हैं कि परीक्षण ग्राहक CSRF जाँच करें, तो आप CSRF जाँच लागू करने वाले परीक्षण ग्राहक का एक उदाहरण बना सकते हैं:

>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)

सीमाएं

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

किनारे के मामले

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

उपयोगिताएँ

नीचे दिए गए उदाहरण मानते हैं कि आप फ़ंक्शन-आधारित विचारों का उपयोग कर रहे हैं। यदि आप वर्ग-आधारित विचारों के साथ काम कर रहे हैं, तो आप सजाने-आधारित वर्ग-आधारित विचारों को संदर्भित कर सकते हैं।

csrf_exempt(view) [source]

यह डेकोरेटर मिडलवेयर द्वारा सुनिश्चित सुरक्षा से मुक्त होने के रूप में एक दृश्य को चिह्नित करता है। उदाहरण:

from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def my_view(request):
    return HttpResponse('Hello world')
requires_csrf_token(view)

यदि CsrfViewMiddleware.process_view या समकक्ष नहीं है तो आम तौर पर csrf_token टेम्पलेट टैग काम नहीं करेगा। डेकोरेटर requires_csrf_token काम करने के लिए डेकोरेटर की requires_csrf_token । यह डेकोरेटर csrf_protect समान काम करता है, लेकिन कभी भी आने वाले अनुरोध को अस्वीकार नहीं करता है।

उदाहरण:

from django.shortcuts import render
from django.views.decorators.csrf import requires_csrf_token

@requires_csrf_token
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)

यह डेकोरेटर CSRF कुकी भेजने के लिए एक दृश्य प्रस्तुत करता है।

परिदृश्य

CSRF सुरक्षा को केवल कुछ दृश्यों के लिए अक्षम किया जाना चाहिए

अधिकांश विचारों में CSRF सुरक्षा की आवश्यकता होती है, लेकिन कुछ नहीं करते हैं।

समाधान: मिडलवेयर को अक्षम करने और csrf_protect आवश्यकता वाले सभी दृश्यों में csrf_protect को लागू करने के बजाय, मिडलवेयर को सक्षम करें और csrf_exempt() उपयोग करें।

CsrfViewMiddleware.process_view का उपयोग नहीं किया गया

ऐसे मामले हैं जब CsrfViewMiddleware.process_view आपके दृश्य के चलने से पहले नहीं CsrfViewMiddleware.process_view सकता है - उदाहरण के लिए 404 और 500 हैंडलर, - लेकिन आपको अभी भी CSRF टोकन की आवश्यकता है।

समाधान: का उपयोग करने की requires_csrf_token()

असुरक्षित दृश्य को CSRF टोकन की आवश्यकता है

कुछ ऐसे विचार हो सकते हैं जो असुरक्षित हैं और csrf_exempt द्वारा छूट दी गई है, लेकिन अभी भी CSRF टोकन को शामिल करने की आवश्यकता है।

समाधान: csrf_exempt() उपयोग csrf_exempt() बाद csrf_exempt() requires_csrf_token() । (यानी requires_csrf_token को अंतरतम डेकोरेटर होना चाहिए)।

देखें एक मार्ग के लिए सुरक्षा की आवश्यकता है

एक दृश्य में केवल एक सेट के तहत CSRF सुरक्षा की आवश्यकता होती है, और बाकी समय के लिए नहीं होना चाहिए।

समाधान: संपूर्ण दृश्य फ़ंक्शन के लिए csrf_protect() और csrf_protect() भीतर पथ के लिए csrf_exempt() उपयोग करें csrf_exempt() सुरक्षा की आवश्यकता है। उदाहरण:

from django.views.decorators.csrf import csrf_exempt, csrf_protect

@csrf_exempt
def my_view(request):

    @csrf_protect
    def protected_path(request):
        do_something()

    if some_condition():
       return protected_path(request)
    else:
       do_something_else()

पेज बिना किसी HTML फॉर्म के AJAX का उपयोग करता है

एक पेज AJAX के माध्यम से एक POST अनुरोध करता है, और पृष्ठ में एक HTML फॉर्म नहीं है जिसमें एक csrf_token जो आवश्यक CSRF कुकी भेजने का कारण होगा।

समाधान: पृष्ठ को भेजने वाले दृश्य पर सुनिश्चित करें कि ensure_csrf_cookie() उपयोग करें।

कंट्राब और पुन: प्रयोज्य एप्लिकेशन

क्योंकि डेवलपर के लिए CsrfViewMiddleware बंद करना CsrfViewMiddleware , CsrfViewMiddleware में सभी प्रासंगिक विचार CSRF के खिलाफ इन अनुप्रयोगों की सुरक्षा सुनिश्चित करने के लिए csrf_protect डेकोरेटर का उपयोग करते हैं। यह अनुशंसा की जाती है कि अन्य पुन: प्रयोज्य एप्लिकेशन के डेवलपर्स जो समान गारंटी चाहते हैं, अपने विचारों पर csrf_protect डेकोरेटर का भी उपयोग करें।

सेटिंग्स

Django के CSRF व्यवहार को नियंत्रित करने के लिए कई सेटिंग्स का उपयोग किया जा सकता है:

अक्सर पूछे जाने वाले प्रश्न

क्या एक मनमानी CSRF टोकन जोड़ी (कुकी और POST डेटा) को पोस्ट करना एक भेद्यता है?

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

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

क्या यह एक समस्या है कि Django की CSRF सुरक्षा डिफ़ॉल्ट रूप से एक सत्र से जुड़ी नहीं है?

नहीं, यह डिजाइन द्वारा है। CSRF सुरक्षा को एक सत्र से लिंक नहीं करना, एक pastebin जैसी साइटों पर सुरक्षा का उपयोग करने की अनुमति देता है जो उन अनाम उपयोगकर्ताओं से सबमिशन की अनुमति देता है जिनके पास सत्र नहीं है।

यदि आप उपयोगकर्ता के सत्र में CSRF टोकन स्टोर करना चाहते हैं, तो CSRF_USE_SESSIONS सेटिंग का उपयोग करें।

लॉग इन करने के बाद उपयोगकर्ता को CSRF सत्यापन विफलता क्यों मिल सकती है?

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