CSRF सुरक्षा और CORS दोनों का उपयोग क्यों किया जाता है?

 (smagin.fyi)
33 पॉइंट द्वारा GN⁺ 2025-03-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cross-Site Request पर सोचते समय शुरुआत में यह समझना मुश्किल था कि CSRF सुरक्षा और CORS दोनों की ज़रूरत क्यों पड़ती है. लेकिन इसे समझाने के लिए काफ़ी शब्दों की ज़रूरत है

CSRF और CORS

  • CSRF (Cross-Site Request Forgery)
    • पहले यह आम था, लेकिन अब ज़्यादातर web frameworks डिफ़ॉल्ट रूप से सुरक्षा देते हैं, इसलिए यह लगभग समस्या नहीं रह गई है
    • हमले का तरीका: उपयोगकर्ता को किसी malicious site पर किसी खास form पर क्लिक कराने के लिए उकसाया जाता है ताकि वह cross-site request भेज दे
    • बचाव का तरीका: यह जाँचना कि request किसी दूसरी site से आई है या नहीं
  • CORS (Cross-Origin Resource Sharing)
    • यह HTTP spec का हिस्सा है, जो कुछ खास cross-site requests को अनुमति देने का तरीका परिभाषित करता है
    • preflight request और response headers का उपयोग करके यह तय किया जाता है कि किन origins से request भेजी जा सकती है

तो क्या cross-site requests डिफ़ॉल्ट रूप से अनुमति प्राप्त होती हैं और इसलिए CSRF सुरक्षा चाहिए, या वे डिफ़ॉल्ट रूप से block होती हैं और इसलिए CORS की ज़रूरत पड़ती है? सही जवाब है दोनों.

डिफ़ॉल्ट व्यवहार

  • Same-origin policy
    • यह browser द्वारा लागू की जाने वाली security policy है
    • आम तौर पर cross-site write की अनुमति होती है, लेकिन read पर रोक होती है
    • उदाहरण के लिए, browser form के ज़रिए POST request की अनुमति देता है, लेकिन response को पढ़ने नहीं देता
  • SameSite cookie policy
    • 2019 में cookies के डिफ़ॉल्ट व्यवहार में बदलाव किया गया
    • पहले cross-site requests में भी cookies हमेशा भेजी जाती थीं
    • नया SameSite attribute जोड़ा गया और डिफ़ॉल्ट मान Lax कर दिया गया
    • 2025 तक, 96% browsers SameSite attribute को support करते हैं, और 75% नया default (Lax) support करते हैं
    • लेकिन Safari ने इसे default के रूप में लागू नहीं किया, और UCBrowser अभी भी इसे support नहीं करता
  • Site और Origin का अंतर
    • Origin: protocol + hostname + port का संयोजन
    • Site: protocol + top-level domain + 1 का संयोजन (subdomain और port को नज़रअंदाज़ किया जाता है)

CORS

  • CORS, same-origin policy में कुछ खास origins के लिए अपवादस्वरूप अनुमति देने का तरीका है
  • browser request भेजने से पहले OPTIONS type की preflight request भेजता है
  • server response headers के ज़रिए अनुमति नियम तय करता है (Access-Control-* headers का उपयोग)
  • जिन request types पर CORS लागू होता है:
    • fetch और XMLHttpRequest
    • web fonts
    • WebGL textures
    • canvas में drawImage से बनाई गई images/video frames
    • CSS shape-outside property में इस्तेमाल होने वाली images
  • लेकिन form submission पर अपवादस्वरूप CORS लागू नहीं होता
    • HTML 4.0 का <form> tag बहुत पहले से cross-site requests की अनुमति देता आया है
    • इसलिए पुराने servers को पहले से ही CSRF attacks के ख़िलाफ़ डिज़ाइन किया गया होना चाहिए था
    • response share करने के लिए server को Access-Control-Allow-Origin सेट करना पड़ता है, लेकिन request स्वयं preflight के बिना भी स्वीकार की जाती है

सवाल: SameSite policy और यह तरीका आपस में consistency कैसे बनाए रखते हैं?

CSRF सुरक्षा के तरीके

  • cross-site write requests की अनुमति होती है, लेकिन response share नहीं किया जाता
    • ज़्यादातर websites cross-site write की अनुमति देना नहीं चाहतीं
  • CSRF से बचाव का मानक तरीका
    • user-specific CSRF token को request में शामिल करके verify करना
    • तरीके:
      • form submission: hidden input field के रूप में token जोड़ना
      • JS requests: cookie या meta tag में store करके, फिर request header या parameter में शामिल करना
  • JS requests मूल रूप से cross-site होने पर डिफ़ॉल्ट रूप से block होती हैं
    • लेकिन same-site requests में इनकी अनुमति होती है
    • CSRF token शामिल करने पर सभी requests को एक ही तरीके से verify किया जा सकता है
  • अतिरिक्त सुरक्षा लाभ
    • यह इस मान्यता पर काम करता है कि browser डिफ़ॉल्ट रूप से response reading को block करेगा
    • Origin header की जाँच करने की तुलना में यह अधिक सुरक्षित है

सवाल: कुछ frameworks CSRF token को समय-समय पर बदलते हैं. ऐसा क्यों?

Browser की भूमिका

  • web security का मूल इस बात पर निर्भर करता है कि browser पर भरोसा किया जा सकता है या नहीं
  • browser:
    • same-origin policy लागू करता है
    • अगर response की अनुमति नहीं है, तो उसे पढ़ने से रोकता है
    • यह तय करता है कि SameSite=Lax default लागू करना है या नहीं
    • CORS implement करता है और सुरक्षित preflight request भेजता है

हमें अपने इस्तेमाल किए जा रहे browser पर भरोसा करना पड़ता है.

निष्कर्ष

  • अगर SameSite=Lax को 100% browsers support करें, तो security और मज़बूत हो जाएगी, लेकिन
    अभी भी स्थिति यह है कि cross-site POST requests ही अपवादस्वरूप अनुमति प्राप्त हैं
  • इसलिए developers को CSRF सुरक्षा पर लगातार ध्यान देना चाहिए

"इंटरनेट धीरे-धीरे अधिक सुरक्षित हो रहा है, लेकिन उसी अनुपात में पुराने सिस्टम्स के साथ compatibility भी घटती जा रही है."

स्रोत

  1. Same-origin policy
  2. caniuse SameSite cookie attribute
  3. OWASP CSRF cheatsheet
  4. CORS wiki with requirements
  5. CORS spec
  6. CORS on MDN
  7. Preflight request
  8. Origin request header
  9. Origin and Site

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-03-04
Hacker News राय

  • CORS एक ऐसा mechanism है जिसमें server browser को साफ़ तौर पर बताता है कि कौन-सी cross-origin requests response को पढ़ सकती हैं

    • डिफ़ॉल्ट रूप से browser cross-origin script को response पढ़ने से रोकता है
    • जब तक स्पष्ट रूप से अनुमति न दी जाए, request domain response नहीं पढ़ सकता
    • उदाहरण के लिए, evil.com का script bank.com/transactions पर request भेजकर पीड़ित के transaction history को पढ़ने की कोशिश कर सकता है
    • browser request को bank.com तक पहुँचने देता है, लेकिन evil.com को response पढ़ने से रोक देता है

  • CSRF protection authenticated user की ओर से malicious cross-origin requests द्वारा बिना अनुमति actions किए जाने से रोकती है

    • उदाहरण के लिए, evil.com का script bank.com पर action कराने के लिए request भेज सकता है (जैसे: bank.com/transfer?from=victim&to=hacker से पैसे transfer करना)
    • bank.com की server-side CSRF protection इसे reject कर देती है (संभवतः इसलिए क्योंकि request में secret CSRF token शामिल नहीं होता)

  • CSRF protection write protection से जुड़ी है, जबकि CORS read protection से जुड़ा है

  • JS से शुरू की गई requests में डिफ़ॉल्ट रूप से cross-site की अनुमति नहीं होती

    • fetch() का उपयोग करके allowed headers के साथ cross-site request शुरू की जा सकती है

  • लगता है कि इस विषय पर इससे बेहतर explanation मौजूद है

    • संबंधित blog link दिया गया

  • blog post के सवाल पर प्रतिक्रिया

    • HTML 4.0 का <form> element किसी भी origin पर simple request submit कर सकता है
    • इस संदर्भ में यह SameSite initiative के साथ कैसे मेल खाता है, इस पर सवाल था

  • 2022 में MDN के CORS article में "simple request" शब्द की उत्पत्ति स्पष्ट करने के लिए एक paragraph जोड़ा गया था

    • पहले सिर्फ़ इतना लिखा था कि इसका उल्लेख fetch spec में नहीं है
    • 2019 में browser के CSRF mitigation features द्वारा SameSite=Lax को support करने या उसे default बनाने का कोई उल्लेख नहीं था

  • यह बात उलझन पैदा करती है कि SameSite को CORS preflight से स्वतंत्र रूप से जोड़ा गया

    • यह जानने की जिज्ञासा है कि browser makers ने सभी cross-origin POST requests के लिए preflight अनिवार्य क्यों नहीं किया

  • यह मान लेना कि csrf का इस्तेमाल न करने पर भी चीज़ें सुरक्षित हैं, गलत हो सकता है; कुछ libraries (जैसे django rest framework) content-type header सेट होने पर HTML form को process कर सकती हैं

    • इससे किसी user की site पर form post करके उसके behalf पर requests भेजना संभव हो जाता है

  • CSRF token को rotate करने की वजह पर सवाल

    • OWASP कहता है कि यह ज़्यादा सुरक्षित है, लेकिन उसका कारण स्पष्ट नहीं है

  • इस जटिल विषय के लिए flowchart की मांग

    • application platforms और standards का एक नया set चाहा गया

  • ये चीज़ें आसान diagnostic tracing को support नहीं करतीं

    • ठीक से configure न किए गए legitimate use cases में कई बार opaque errors का सामना हुआ

  • यह समझना कठिन है कि CORS आने से पहले page origin से अलग किसी भी endpoint पर request भेजना संभव क्यों था, लेकिन response देखना संभव नहीं था

    • जिज्ञासा है कि क्या यह spec में संयोगवश शामिल हुआ, XSS की आशंका को देखते हुए जानबूझकर किया गया, या किसी प्रमुख browser ने ऐसा किया और बाकी ने उसका अनुसरण किया

  • CSRF protection को लेकर भ्रम

    • सवाल है कि attacker को goodsite.com से CSRF token लेकर उसे badsite.com में डालने और Alice को badsite.com से goodsite.com पर request submit करने के लिए फुसलाने से रोकने का तरीका क्या है