क्या मुझे सीएसआरएफ हमलों को रोकने के लिए HTTP रेफरर सत्यापन या टोकन सत्यापन का उपयोग करना चाहिए?

Question

मैंने एएसपी.नेट एमवीसी वेब एप्लिकेशन में सीएसआरएफ हमलों से अपनी वेबसाइट को कैसे सुरक्षित किया है, इस बारे में पढ़ा। वे दो तरह से उल्लेख किया ऐसा करने के लिए, या तो द्वारा:

1. टोकन सत्यापन का उपयोग कर <@Html.AntiForgeryToken()> और [ValidateAntiforgeryToken]

2. का उपयोग कर HTTP संदर्भदाता सत्यापन का उपयोग करके जैसे:

   public class IsPostedFromThisSiteAttribute : AuthorizeAttribute 
       { 
       public override void OnAuthorize(AuthorizationContext filterContext) 
        { 
        if (filterContext.HttpContext != null) 
         { 
         if (filterContext.HttpContext.Request.UrlReferrer == null) 
          throw new System.Web.HttpException("Invalid submission"); 
         if (filterContext.HttpContext.Request.UrlReferrer.Host != 
          "mysite.com") 
          throw new System.Web.HttpException 
           ("This form wasn't submitted from this site!"); 
         } 
        } 
       } 
   

   और

   [IsPostedFromThisSite] 
   public ActionResult Register(…) 
   

तो मुझे इस बारे में भ्रमित हो गया कि क्या मुझे सीएसआरएफ हमलों से अपनी वेबसाइट की रक्षा करने के लिए दोनों का उपयोग करना चाहिए या क्या मैं इनमें से किसी एक तरीके का चयन कर सकता हूं?

Answer 1

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

सीएसआरएफ सत्यापन टोकन का उपयोग करना एक मजबूत दृष्टिकोण है और सीएसआरएफ हमलों के खिलाफ कमजोर पड़ने का पसंदीदा तरीका है। आप इस बारे में पढ़ सकते हैं कि यह OWASP CSRF Cheat Sheet पर क्यों है।

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

Answer 2

HTTP Referer (एसआईसी) शीर्षलेख is not reliable। आपको किसी भी महत्वपूर्ण चीज़ के लिए इस पर निर्भर नहीं होना चाहिए। Wikipedia's CSRF article के शब्दों में:।

"HTTP जाँच हो रही है Referer हैडर यदि अनुरोध एक अधिकृत पेज से आ रही है आमतौर पर एम्बेडेड नेटवर्क उपकरणों के लिए प्रयोग किया जाता है, क्योंकि यह स्मृति आवश्यकताओं में वृद्धि नहीं करता देखने के लिए हालांकि एक अनुरोध है कि Referer हैडर को छोड़ देता है अनधिकृत के रूप में माना जाना चाहिए क्योंकि एक हमलावर Referer हेडर को एफ़टीपी या एचटीटीपीएस यूआरएल से अनुरोध जारी करके दबा सकता है। यह सख्त Referer सत्यापन ब्राउज़र या प्रॉक्सी के साथ समस्याएं पैदा कर सकता है जो गोपनीयता कारणों से Referer शीर्षलेख को छोड़ देता है। इसके अलावा, फ्लैश के पुराने संस्करण 9.0.18) दुर्भावनापूर्ण फ्लैश को सीआरएलएफ इंजेक्शन का उपयोग करके मनमाने ढंग से HTTP अनुरोध शीर्षलेखों के साथ जीईटी या POST अनुरोध उत्पन्न करने की अनुमति देता है। इसी तरह के सीआरएलएफ इंजेक्शन vu किसी क्लाइंट में लोनिबिलिटी का उपयोग HTTP अनुरोध के रेफरर को धोखा देने के लिए किया जा सकता है। "

रेफरर जांच persistent CSRF हमलों के खिलाफ भी मदद नहीं करेगी, जहां हमलावर सीधे आपकी साइट पर एक दुर्भावनापूर्ण लिंक इंजेक्ट करने का प्रबंधन करता है। ऐसे हमलों से बचाने के लिए एकमात्र विश्वसनीय तरीका विरोधी जालसाजी टोकन का उपयोग करना है।

Answer 3

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

संपादित करें: this question देखें।

मैं विश्वसनीय होने पर भरोसा नहीं करता।

Answer 4

जैसा कि अन्य उत्तरों द्वारा इंगित किया गया है, रेफरर चेक का उपयोग करके स्वयं पर्याप्त नहीं है और आपको वास्तव में एंटी-फोर्जरी टोकन का उपयोग करना चाहिए।

हालांकि, जैसा कि @jeffsix ने इंगित किया है, आप रेफरर चेक को रक्षा-इन-गहराई (डीआईडी) रणनीति के रूप में उपयोग कर सकते हैं, इसलिए एक हमलावर को सफल हमले को निष्पादित करने के लिए एकाधिक, स्वतंत्र, रक्षा को हराने की आवश्यकता होगी।

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

/// <summary> 
/// For POST requests, checks that the requests referrer is the current site. This could be used along side the ValidateAntiForgeryToken 
/// Note that many clients do not send the referrer, so we do nothing in this case. 
/// This attribute can be used as part of a Defence-in-Depth (DID) strategy, so an 
/// attacker would need to defeat multiple, independent, defenses to execute a successful attack. 
/// </summary> 
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited = true, AllowMultiple = false)] 
public class ValidateReferrerAttribute : FilterAttribute, IAuthorizationFilter 
{ 
    /// <summary> 
    /// Called when authorization is required. 
    /// </summary> 
    /// <param name="filterContext">The filter context.</param> 
    /// <exception cref="System.ArgumentNullException">filterContext</exception> 
    public void OnAuthorization(AuthorizationContext filterContext) 
    { 
     if (filterContext == null) 
     { 
      throw new ArgumentNullException("filterContext"); 
     } 

     if ((filterContext.HttpContext.Request.UrlReferrer != null) && 
      string.Equals(filterContext.HttpContext.Request.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) && 
      !string.Equals(filterContext.HttpContext.Request.UrlReferrer.Host, filterContext.HttpContext.Request.Url.Host, StringComparison.OrdinalIgnoreCase)) 
     { 
      this.HandleExternalPostRequest(filterContext); 
     } 
    } 

    /// <summary> 
    /// Handles post requests that are made from an external source. 
    /// By default a 403 Forbidden response is returned. 
    /// </summary> 
    /// <param name="filterContext">The filter context.</param> 
    /// <exception cref="System.Web.HttpException">Request not allowed.</exception> 
    protected virtual void HandleExternalPostRequest(AuthorizationContext filterContext) 
    { 
     throw new HttpException((int)HttpStatusCode.Forbidden, "Request not allowed."); 
    } 
}