CSRF, XSSI, और क्रॉस-ऑरिजिन जानकारी लीक होने से बचाएं.
आपको अपने वेब संसाधनों को अलग करने की चिंता क्यों करनी चाहिए?
कई वेब ऐप्लिकेशन, क्रॉस-ऑरिजिन हमलों के जोखिम में होते हैं. जैसे, क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़), क्रॉस-साइट स्क्रिप्ट शामिल करने (XSSI), टाइमिंग अटैक, क्रॉस-ऑरिजिन जानकारी लीक या अनुमान पर आधारित साइड-चैनल (स्पेक्टर) हमले.
मेटाडेटा फ़ेच करें के अनुरोध के हेडर की मदद से, आपके ऐप्लिकेशन को इन आम क्रॉस-ऑरिजिन हमलों से सुरक्षित रखने के लिए, मज़बूत सुरक्षा का मज़बूत तरीका लागू किया जा सकता है. जैसे, रिसॉर्स आइसोलेशन की नीति.
किसी दिए गए वेब ऐप्लिकेशन के ज़रिए दिखाए गए संसाधनों के लिए आम बात है, जो खुद ऐप्लिकेशन के ज़रिए ही लोड होते हैं, दूसरी वेबसाइटों के ज़रिए नहीं. ऐसे मामलों में, मेटाडेटा फ़ेच करने के अनुरोध हेडर के आधार पर रिसॉर्स आइसोलेशन नीति को डिप्लॉय करने में थोड़ी मेहनत लगती है. साथ ही, यह ऐप्लिकेशन को क्रॉस-साइट हमलों से भी सुरक्षित रखता है.
वेबसाइट का अलग-अलग ब्राउज़र पर चलना
डेटा फ़ेच करने के अनुरोध के हेडर, सभी मॉडर्न ब्राउज़र इंजन पर काम करते हैं.
बैकग्राउंड
वेब डिफ़ॉल्ट रूप से खुला होने और आपका ऐप्लिकेशन सर्वर, बाहरी ऐप्लिकेशन से होने वाले कम्यूनिकेशन से आसानी से खुद को सुरक्षित नहीं रखने की वजह से, कई क्रॉस-साइट हमले हो सकते हैं. आम तौर पर, क्रॉस-ऑरिजिन अटैक, क्रॉस-साइट अनुरोध से जुड़ी जालसाज़ी (सीएसआरएफ़) होता है. इसमें कोई हमलावर, उपयोगकर्ता को ऐसी साइट पर ले जाता है जिसका कंट्रोल उसके पास है. इसके बाद, वह उस सर्वर पर फ़ॉर्म सबमिट करता है जिसमें उपयोगकर्ता लॉग इन है. सर्वर यह नहीं बता सकता कि अनुरोध किसी दूसरे डोमेन (क्रॉस-साइट) से किया गया है या नहीं और ब्राउज़र क्रॉस-साइट अनुरोधों में अपने-आप कुकी को अटैच करता है. इसलिए, सर्वर उपयोगकर्ता की ओर से हमलावर की अनुरोध की कार्रवाई को एक्ज़ीक्यूट करेगा.
क्रॉस-साइट स्क्रिप्ट इन्क्लूज़न (XSSI) या क्रॉस-ऑरिजिन जानकारी लीक जैसे अन्य क्रॉस-साइट हमले, सीएसआरएफ़ जैसे ही होते हैं. ये हमलावरों के कंट्रोल वाले दस्तावेज़ में, पीड़ित के ऐप्लिकेशन से संसाधनों को लोड करने और पीड़ित के ऐप्लिकेशन की जानकारी लीक करने पर निर्भर होते हैं. ऐप्लिकेशन भरोसेमंद अनुरोधों और गैर-भरोसेमंद अनुरोधों में आसानी से अंतर नहीं कर सकते, इसलिए वे नुकसान पहुंचाने वाले क्रॉस-साइट ट्रैफ़िक को खारिज नहीं कर सकते.
पेश है मेटाडेटा फ़ेच करने की सुविधा
डेटा फ़ेच करने के अनुरोध के हेडर, वेब प्लैटफ़ॉर्म की सुरक्षा से जुड़ी नई सुविधा है. इससे सर्वर को क्रॉस-ऑरिजिन हमलों से सुरक्षित रहने में मदद मिलती है. Sec-Fetch-* हेडर के सेट में, एचटीटीपी अनुरोध के संदर्भ के बारे में जानकारी देकर, ये रिस्पॉन्स देने वाले सर्वर को अनुरोध को प्रोसेस करने से पहले सुरक्षा नीतियां लागू करने की अनुमति देते हैं. इससे डेवलपर यह तय कर पाते हैं कि किसी अनुरोध को स्वीकार या अस्वीकार करना है या नहीं. अनुरोध को स्वीकार या अस्वीकार करने के लिए यह तरीका इस्तेमाल किया जाएगा. साथ ही, यह भी तय किया जाएगा कि अनुरोध को किस संदर्भ में इस्तेमाल किया जाएगा. इससे, सिर्फ़ उनके ऐप्लिकेशन में किए गए कानूनी अनुरोधों का जवाब दिया जा सकता है.
Sec-Fetch-* हेडर से मिले एचटीटीपी अनुरोध में अतिरिक्त संदर्भ मौजूद होता है.
Sec-Fetch-Site
Sec-Fetch-Site, सर्वर को बताता है कि किस साइट ने अनुरोध भेजा है. ब्राउज़र इस वैल्यू को इनमें से किसी एक पर सेट करता है:
same-origin, अगर अनुरोध आपके खुद के आवेदन से किया गया हो (जैसे,site.example)same-site, अगर अनुरोध आपकी साइट के किसी सबडोमेन से किया गया था (जैसे,bar.site.example)none, अगर अनुरोध साफ़ तौर पर किसी उपयोगकर्ता के उपयोगकर्ता एजेंट के साथ हुए इंटरैक्शन की वजह से हुआ हो (जैसे कि किसी बुकमार्क पर क्लिक करना)cross-site, अगर अनुरोध किसी दूसरी वेबसाइट (जैसे,evil.example) से भेजा गया हो
Sec-Fetch-Mode
Sec-Fetch-Mode, अनुरोध के मोड के बारे में बताता है. यह कुछ हद तक अनुरोध के टाइप से मेल खाता है. इसकी मदद से, रिसॉर्स लोड और नेविगेशन अनुरोधों में अंतर किया जा सकता है. उदाहरण के लिए, navigate का डेस्टिनेशन, टॉप लेवल नेविगेशन के अनुरोध के बारे में बताता है. वहीं, no-cors इमेज लोड करने जैसे रिसॉर्स के अनुरोधों के बारे में बताता है.
Sec-Fetch-Dest
Sec-Fetch-Dest, अनुरोध के डेस्टिनेशन दिखाता है. उदाहरण के लिए, अगर script या img टैग की वजह से ब्राउज़र ने संसाधन का अनुरोध किया है.
क्रॉस-ऑरिजिन हमलों से सुरक्षित रहने के लिए, फे़च मेटाडेटा इस्तेमाल करने का तरीका
इन अनुरोध हेडर से मिली ज़्यादा जानकारी बहुत आसान है, लेकिन ज़्यादा संदर्भ की मदद से सर्वर-साइड पर एक असरदार सुरक्षा लॉजिक बनाया जा सकता है. इसे रिसॉर्स आइसोलेशन नीति भी कहा जाता है. इसके लिए, कोड की कुछ लाइनों का ही इस्तेमाल किया जा सकता है.
संसाधन आइसोलेशन की नीति को लागू करना
संसाधन आइसोलेशन नीति आपके संसाधनों को बाहरी वेबसाइटों से अनुरोध किए जाने से रोकती है. इस तरह के ट्रैफ़िक को ब्लॉक करने से, क्रॉस-साइट वेब पर आम तौर पर होने वाले जोखिम कम हो जाते हैं. जैसे, सीएसआरएफ़, XSSI, टाइमिंग अटैक, और क्रॉस-ऑरिजिन जानकारी लीक होना. यह नीति आपके ऐप्लिकेशन के सभी एंडपॉइंट के लिए चालू की जा सकती है. साथ ही, यह आपके ऐप्लिकेशन से मिलने वाले सभी संसाधन अनुरोधों के साथ-साथ सीधे नेविगेशन (एचटीटीपी GET अनुरोध के ज़रिए) को अनुमति देगी. ऐसे एंडपॉइंट जिन्हें क्रॉस-साइट कॉन्टेक्स्ट में लोड किया जाना चाहिए (उदाहरण के लिए, सीओआरएस का इस्तेमाल करके लोड किए गए एंडपॉइंट) को इस लॉजिक से ऑप्ट आउट किया जा सकता है.
पहला चरण: ऐसे ब्राउज़र से मिलने वाले अनुरोधों को अनुमति दें जो फे़च मेटाडेटा नहीं भेजते हैं
सभी ब्राउज़र पर फे़च मेटाडेटा काम नहीं करता, इसलिए आपको sec-fetch-site की मौजूदगी का पता करके उन अनुरोधों को अनुमति देनी होगी जो Sec-Fetch-* हेडर सेट नहीं करते.
if not req['sec-fetch-site']:
return True # Allow this request
दूसरा चरण: एक ही साइट और ब्राउज़र से शुरू किए गए अनुरोधों को अनुमति देना
ऐसे किसी भी अनुरोध को अनुमति दी जाएगी जो क्रॉस-ऑरिजिन कॉन्टेक्स्ट (जैसे कि evil.example) से नहीं आते हैं. खास तौर पर, ये ऐसे अनुरोध होते हैं जो:
- अपने खुद के ऐप्लिकेशन से जनरेट करें (उदाहरण के लिए, एक ही ऑरिजिन वाला अनुरोध, जिसमें
site.exampleका अनुरोधsite.example/foo.jsonहमेशा लागू होगा). - अपने सबडोमेन से जनरेट करें.
- साफ़ तौर पर उपयोगकर्ता एजेंट के साथ उपयोगकर्ता के इंटरैक्शन की वजह से होते हैं (उदाहरण के लिए, डायरेक्ट नेविगेशन या बुकमार्क पर क्लिक करना वगैरह).
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True # Allow this request
तीसरा चरण: टॉप लेवल पर आसान नेविगेशन और iफ़्रेमिंग की अनुमति देना
यह पक्का करने के लिए कि आपकी साइट अब भी दूसरी साइटों से लिंक की जा सके, आपको आसान (HTTP GET) टॉप लेवल नेविगेशन को अनुमति देनी होगी.
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
# <object> and <embed> send navigation requests, which we disallow.
and req['sec-fetch-dest'] not in ('object', 'embed'):
return True # Allow this request
चौथा चरण: क्रॉस-साइट ट्रैफ़िक दिखाने वाले एंडपॉइंट से ऑप्ट आउट करना (ज़रूरी नहीं है)
कुछ मामलों में, आपका ऐप्लिकेशन ऐसे संसाधन उपलब्ध करा सकता है जिन्हें क्रॉस-साइट लोड किया जा सकता है. इन संसाधनों को हर पाथ या हर एंडपॉइंट के आधार पर छूट दी जानी चाहिए. ऐसे एंडपॉइंट के उदाहरण:
- क्रॉस-ऑरिजिन ऐक्सेस किए जाने वाले एंडपॉइंट: अगर आपका ऐप्लिकेशन ऐसे एंडपॉइंट इस्तेमाल कर रहा है जिन पर
CORSचालू है, तो आपको उन्हें रिसॉर्स आइसोलेशन से साफ़ तौर पर ऑप्ट आउट करना होगा. इससे यह पक्का किया जा सकेगा कि इन एंडपॉइंट पर क्रॉस-साइट अनुरोध अब भी किए जा सकते हैं. - सार्वजनिक संसाधन (जैसे कि इमेज, स्टाइल वगैरह): ऐसे सार्वजनिक और बिना पुष्टि वाले रिसॉर्स को भी छूट दी जा सकती है जिन्हें दूसरी साइटों से लोड किए जा सकने वाले क्रॉस-ऑरिजिन चाहिए.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
return True
पांचवां चरण: ऐसे सभी अनुरोधों को अस्वीकार करना जो क्रॉस-साइट हैं और नेविगेशन से जुड़े नहीं हैं
किसी भी अन्य क्रॉस-साइट अनुरोध को रिसॉर्स आइसोलेशन की इस नीति से अस्वीकार कर दिया जाएगा. इस तरह, आपके ऐप्लिकेशन को क्रॉस-साइट पर होने वाले आम हमलों से सुरक्षित रखा जाएगा.
उदाहरण: नीचे दिया गया कोड, सर्वर पर रिसॉर्स आइसोलेशन की एक अहम नीति को पूरी तरह से लागू करने के बारे में बताता है. इसके अलावा, नेविगेशन के आसान अनुरोधों को अनुमति देते हुए, संभावित नुकसान पहुंचाने वाले क्रॉस-साइट रिसॉर्स के अनुरोधों को अस्वीकार करने के लिए, मिडलवेयर के तौर पर इस नीति को लागू करता है:
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):
# Allow requests from browsers which don't send Fetch Metadata
if not req['sec-fetch-site']:
return True
# Allow same-site and browser-initiated requests
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True
# Allow simple top-level navigations except <object> and <embed>
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
and req['sec-fetch-dest'] not in ('object', 'embed'):
return True
# [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
return True
# Reject all other requests that are cross-site and not navigational
return False
रिसॉर्स आइसोलेशन की नीति लागू करना
- ऊपर दिए गए कोड स्निपेट जैसा कोई मॉड्यूल इंस्टॉल करके लॉग करें और नज़र रखें कि आपकी साइट कैसे काम करती है. साथ ही, पक्का करें कि पाबंदी किसी सही ट्रैफ़िक पर असर न डाले.
- सही क्रॉस-ऑरिजिन एंडपॉइंट को छूट देकर, संभावित उल्लंघनों को ठीक करें.
- नीति का पालन न करने वाले अनुरोधों को हटाकर, नीति लागू करें.
नीति के उल्लंघनों का पता लगाना और उन्हें ठीक करना
हमारा सुझाव है कि आप पहले अपने सर्वर साइड कोड के रिपोर्टिंग मोड में इसे चालू करके, अपनी नीति की जांच करें. यह जांच, खराब असर से बचाने के लिए करें. इसके अलावा, इस लॉजिक को मिडलवेयर या रिवर्स प्रॉक्सी में लागू किया जा सकता है. यह प्रोडक्शन ट्रैफ़िक पर लागू किए जाने पर आपकी नीति के उल्लंघन से जुड़े किसी भी उल्लंघन को लॉग करता है.
Google पर डेटा फ़ेच करने के मेटाडेटा के रिसॉर्स आइसोलेशन की नीति को रोल आउट करने के हमारे अनुभव के मुताबिक, ज़्यादातर ऐप्लिकेशन डिफ़ॉल्ट रूप से इस तरह की नीति के साथ काम करते हैं. साथ ही, क्रॉस-साइट ट्रैफ़िक को अनुमति देने के लिए, एंडपॉइंट में छूट की ज़रूरत बहुत ही कम होती है.
संसाधन आइसोलेशन की नीति लागू करना
जब आप यह जांच लें कि आपकी नीति सही प्रोडक्शन ट्रैफ़िक पर असर नहीं डालती है, तो आप पाबंदियां लागू करने के लिए तैयार हैं. इससे आपको यह गारंटी मिलती है कि दूसरी साइटें आपके संसाधनों का अनुरोध नहीं कर पाएंगी और आपके उपयोगकर्ताओं को क्रॉस-साइट हमलों से भी नहीं बचा पाएंगी.
इसके बारे में और पढ़ें
- W3C फ़ेच मेटाडेटा के अनुरोध के हेडर की खास बातें
- मेटाडेटा प्लेग्राउंड फ़ेच करें
- Google I/O के बारे में बातचीत: आधुनिक प्लैटफ़ॉर्म सुविधाओं की मदद से वेब ऐप्लिकेशन सुरक्षित करना (Slides)