SRI, समझाया गया: आपकी वेबसाइट के एसेट्स के लिए डिजिटल फिंगरप्रिंट

एक वाक्य में

सब-रिसोर्स इंटेग्रिटी (SRI) एक सुरक्षा सुविधा है जो ब्राउज़रों को यह सत्यापित करने देती है कि बाहरी स्रोतों, जैसे CDN, से प्राप्त की गई फ़ाइलों के साथ गुप्त रूप से कोई छेड़छाड़ नहीं की गई है।

यह क्या समस्या हल करता है

कल्पना कीजिए: आप एक शानदार नया वेब ऐप बना रहे हैं। इसे तेज़-तर्रार बनाने के लिए, आप React, Vue, या कुछ फैंसी फोंट जैसी कॉमन लाइब्रेरियों को परोसने के लिए एक कंटेंट डिलीवरी नेटवर्क (CDN) का उपयोग करते हैं। यह एक आम तरीका है। आपके उपयोगकर्ताओं को एक तेज़ अनुभव मिलता है क्योंकि फ़ाइल शायद किसी अन्य साइट पर जाने से उनके ब्राउज़र में पहले से ही कैश हो चुकी है, या यह उनके करीब के सर्वर से परोसी जाती है। दोनों के लिए फायदेमंद, है ना?

ज्यादातर मामलों में। लेकिन आपने अभी-अभी विश्वास का एक बहुत बड़ा तत्व पेश किया है। आप भरोसा कर रहे हैं कि CDN प्रदाता हमेशा वही सटीक फ़ाइल परोसेगा जो आप चाहते थे। क्या होगा अगर वह CDN हैक हो जाए? एक हमलावर दोस्ताना, मददगार react.min.js को एक दुर्भावनापूर्ण संस्करण से बदल सकता है: react.min.js-plus-a-crypto-miner-and-password-stealer।

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

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

यह पर्दे के पीछे कैसे काम करता है

SRI एक सरल HTML एट्रिब्यूट और कुछ गंभीर क्रिप्टोग्राफ़िक सिद्धांतों का एक चतुर मेल है। चलिए इसे तोड़ते हैं।

`integrity` एट्रिब्यूट

जादू एक नए एट्रिब्यूट से शुरू होता है जिसे आप अपने <script> और <link> टैग में जोड़ सकते हैं। इसका नाम, उपयुक्त रूप से, integrity है।

<script
  src="https://code.jquery.com/jquery-3.6.0.min.js"
  integrity="sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3"
  crossorigin="anonymous"></script>

इस एट्रिब्यूट में दो भागों वाली एक स्ट्रिंग होती है: एक हैश एल्गोरिथ्म प्रीफिक्स (यहाँ, sha384-) और एक Base64-एन्कोडेड क्रिप्टोग्राफ़िक हैश। यह उस फ़ाइल का "डिजिटल फिंगरप्रिंट" है जिसे आप प्राप्त करने की उम्मीद करते हैं।

हैश: एक डिजिटल फिंगरप्रिंट

एक क्रिप्टोग्राफ़िक हैश फ़ंक्शन एक गणितीय एल्गोरिथ्म है जो एक इनपुट (जैसे जावास्क्रिप्ट फ़ाइल की पूरी सामग्री) लेता है और वर्णों की एक छोटी, निश्चित आकार की स्ट्रिंग उत्पन्न करता है, जिसे हैश कहा जाता है। इसे एक सुपर-पावर्ड चेकसम की तरह समझें।

इन हैश में कुछ महत्वपूर्ण गुण होते हैं:

निर्धारक (Deterministic): एक ही इनपुट फ़ाइल हमेशा एक ही सटीक हैश उत्पन्न करेगी।
हिमस्खलन प्रभाव (Avalanche Effect): इनपुट फ़ाइल में बस एक अक्षर बदलें—एक स्पेस जोड़ें, एक वैरिएबल का नाम बदलें—और परिणामी हैश पूरी तरह से अलग और अपरिचित होगा।
एक-तरफ़ा (One-way): प्रक्रिया को उलटना व्यावहारिक रूप से असंभव है। आप हैश लेकर यह पता नहीं लगा सकते कि मूल फ़ाइल की सामग्री क्या थी।

SRI मानक तीन सुरक्षित हैश एल्गोरिदम का समर्थन करता है: SHA-256, SHA-384, और SHA-512। संख्या हैश की बिट-लंबाई को संदर्भित करती है, और बड़ा आमतौर पर मजबूत होता है। SHA-384 एक बढ़िया ऑल-अराउंड विकल्प है।

तो, जब आप किसी CDN फ़ाइल से लिंक करने वाले होते हैं, तो आप पहले उसका हैश जेनरेट करते हैं। आप अनिवार्य रूप से उस क्षण में फ़ाइल का एक स्नैपशॉट ले रहे हैं और ब्राउज़र को बता रहे हैं, "असली jquery-3.6.0.min.js ऐसा दिखता है।"

`crossorigin` एट्रिब्यूट

उदाहरण में वह crossorigin="anonymous" देखा? यह सिर्फ सजावट के लिए नहीं है; यह अनिवार्य है। एक ब्राउज़र के लिए एक अलग ऑरिजिन से एक रिसोर्स लाने के लिए (जैसे, आपकी साइट my-app.com code.jquery.com से एक स्क्रिप्ट ला रही है) और SRI जांच के लिए उसकी सामग्री का निरीक्षण करने के लिए, उसे क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) के माध्यम से अनुमति की आवश्यकता होती है।

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

सब कुछ एक साथ रखना: ब्राउज़र की चेकलिस्ट

जब एक ब्राउज़र integrity एट्रिब्यूट वाले टैग का सामना करता है, तो वह इस सख्त प्रोटोकॉल का पालन करता है:

यह <script> टैग को देखता है और src, integrity, और crossorigin एट्रिब्यूट्स को नोट करता है।
यह src URL पर फ़ाइल के लिए एक अनुरोध भेजता है। crossorigin के लिए धन्यवाद, यह एक CORS अनुरोध है।
फ़ाइल डाउनलोड हो जाती है।
महत्वपूर्ण रूप से, कुछ भी निष्पादित करने से पहले, ब्राउज़र डाउनलोड की गई फ़ाइल की सामग्री का अपना हैश गणना करता है, उसी एल्गोरिथ्म का उपयोग करके जो integrity एट्रिब्यूट में निर्दिष्ट है (जैसे, sha384)।
फिर यह अपने ताज़ा गणना किए गए हैश की तुलना उस हैश से करता है जो आपने एट्रिब्यूट में प्रदान किया था।
यदि वे मेल खाते हैं: बहुत बढ़िया! फ़ाइल प्रामाणिक है। ब्राउज़र स्क्रिप्ट को निष्पादित करता है या स्टाइलशीट लागू करता है।
यदि वे मेल नहीं खाते हैं: रेड अलर्ट! ब्राउज़र मानता है कि फ़ाइल के साथ छेड़छाड़ की गई है। यह पूरी तरह से फ़ाइल को खारिज कर देता है और इसे निष्पादित नहीं करता है। इसके बाद यह डेवलपर कंसोल पर एक Failed to find a valid digest त्रुटि भेजता है। आपकी साइट टूटी हुई दिख सकती है (जैसे, एक गायब चार्ट या फ़ॉन्ट), लेकिन आप सफलतापूर्वक एक बड़ी मुसीबत से बच गए हैं।

असल दुनिया की कहानियाँ

विकृत एनालिटिक्स डैशबोर्ड

एक मार्केटिंग टीम एक डैशबोर्ड पर निर्भर थी जो अपने अभियान डेटा की कल्पना करने के लिए एक थर्ड-पार्टी चार्टिंग लाइब्रेरी का उपयोग करती थी, जिसे एक छोटे CDN से खींचा गया था। डेवलपर, जिसने अभी-अभी सुरक्षा सर्वोत्तम प्रथाओं के बारे में पढ़ा था, ने लाइब्रेरी के <script> टैग में SRI हैश जोड़े थे। एक सोमवार की सुबह, CDN को एक संक्षिप्त समझौते का सामना करना पड़ा। एक हमलावर ने लोकप्रिय चार्टिंग लाइब्रेरी को एक स्क्रिप्ट से बदल दिया जो सिर्फ एक विशाल, मजाक उड़ाता हुआ ASCII आर्ट चेहरा प्रदर्शित करती थी।

जब मार्केटिंग टीम ने अपना डैशबोर्ड लोड किया, तो चार्ट टूट गए थे। उन्होंने खाली बक्से देखे। उन्होंने आईटी को फोन किया, नाराज होकर। डेवलपर ने ब्राउज़र कंसोल की जाँच की और सुंदर, सुंदर SRI सत्यापन त्रुटि देखी। ब्राउज़र ने संशोधित फ़ाइल का पता लगा लिया था, इसे चलाने से इंकार कर दिया था, और विकृति को रोक दिया था। एक बड़ी सुरक्षा घटना और घबराए हुए C-suite (कंपनी के टॉप अधिकारी) के बजाय, यह एक 15 मिनट की जांच थी जो अस्थायी रूप से एक अलग CDN की ओर इशारा करने के साथ समाप्त हुई।

सबक: SRI एक संभावित सुरक्षा तबाही को एक काबू में आने वाली उपलब्धता की समस्या में बदल देता है।

चालाक क्रिप्टो-माइनर

एक लोकप्रिय, हल्की जावास्क्रिप्ट यूटिलिटी लाइब्रेरी जो एक मुफ्त CDN पर होस्ट की गई थी, इंडी डेवलपर्स की पसंदीदा थी। एक हमलावर ने CDN तक पहुंच प्राप्त की और लाइब्रेरी फ़ाइल को संशोधित किया, जिसमें कुछ उलझे हुए कोड की लाइनें जोड़ी गईं जो एक WebAssembly क्रिप्टो-माइनर को चालू करती थीं। फ़ाइल का आकार मुश्किल से बदला, और लाइब्रेरी के मुख्य कार्य अभी भी पूरी तरह से काम कर रहे थे।

SRI के बिना लाइब्रेरी का उपयोग करने वाली वेबसाइटों ने अचानक अपने उपयोगकर्ताओं के लैपटॉप के पंखे तेज़ी से घूमने और उनकी बैटरी खत्म होने का कारण बनना शुरू कर दिया। उपयोगकर्ताओं ने सुस्ती की शिकायत की, लेकिन इसका निदान करना मुश्किल था। साइटें खुद ठीक दिख रही थीं। हालांकि, जिन साइटों ने SRI लागू किया था, वे सुरक्षित थीं। उनके ब्राउज़रों ने संशोधित स्क्रिप्ट को ब्लॉक कर दिया, और जबकि यूटिलिटी फ़ंक्शन टूट गए, उनके उपयोगकर्ताओं के सीपीयू सुरक्षित थे।

सबक: SRI न केवल स्पष्ट विकृतियों को पकड़ता है, बल्कि सूक्ष्म, परजीवी हमलों (parasitic attacks) को भी पकड़ता है जो आपकी साइट की प्रतिष्ठा को नुकसान पहुंचा सकते हैं।

भुला दिया गया फ़ॉन्ट अपडेट

एक डिजाइनर ने एक थर्ड-पार्टी फ़ॉन्ट फाउंड्री से एक फ़ॉन्ट के एक विशिष्ट संस्करण का उपयोग करने पर जोर दिया, जिसे उनके CDN के माध्यम से परोसा गया। डेवलपर ने कर्तव्यनिष्ठा से <link> टैग की नकल की, जिसमें उसका SRI हैश भी शामिल था। साइट लॉन्च हुई और बहुत अच्छी लग रही थी। छह महीने बाद, फाउंड्री ने नए मुद्रा प्रतीकों को जोड़ने और केर्निंग में सुधार करने के लिए फ़ॉन्ट फ़ाइल को अपडेट किया। यह एक वैध, मददगार अपडेट था।

अचानक, साइट का टेक्स्ट बदसूरत, डिफ़ॉल्ट Arial में बदल गया। डेवलपर तब तक हैरान था जब तक उसने कंसोल की जाँच नहीं की और SRI त्रुटि नहीं देखी। ब्राउज़र सही ढंग से नई, संशोधित फ़ॉन्ट फ़ाइल को ब्लॉक कर रहा था क्योंकि उसका हैश अब HTML में पुराने से मेल नहीं खाता था। "हमला" सिर्फ एक हानिरहित अपडेट था, लेकिन SRI ने अपना काम किया। समाधान सरल था: अद्यतन फ़ॉन्ट के लिए एक नया हैश जेनरेट करें और परिवर्तन को डिप्लॉय करें।

सबक: SRI सख्त वर्जनिंग लागू करता है। यह आपको दुर्भावनापूर्ण परिवर्तनों और अप्रत्याशित अपस्ट्रीम अपडेट से बचाता है, जो आपको आपके द्वारा उपयोग किए जाने वाले एसेट्स के बारे में जानबूझकर होने के लिए मजबूर करता है।

आम गलतियाँ और जाल

crossorigin="anonymous" को भूल जाना। यह #1 गलती है। इसके बिना, ब्राउज़र को रिसोर्स का निरीक्षण करने के लिए CORS की अनुमति नहीं होती है, इसलिए सुरक्षा के लिए, यह बस इसे ब्लॉक कर देता है। कोई इंटेग्रिटी जांच नहीं होती है। आपकी स्क्रिप्ट या स्टाइल बस लोड होने में विफल हो जाती है।
गलत चीज़ को हैश करना। आपको उस सटीक फ़ाइल सामग्री को हैश करना होगा जो ब्राउज़र को मिलती है। यदि आप मिनिफाइड CDN संस्करण से लिंक कर रहे हैं तो स्क्रिप्ट के स्थानीय, असम्पीडित संस्करण को हैश न करें। URL स्ट्रिंग को ही हैश न करें। आपको फ़ाइल के बॉडी का हैश चाहिए।
कमजोर हैश एल्गोरिदम का उपयोग करना। MD5 और SHA-1 में ज्ञात कमजोरियां हैं और सुरक्षा उद्देश्यों के लिए इनका उपयोग नहीं किया जाना चाहिए। स्पेक के अनुसार ब्राउज़रों को कम से कम SHA-256, SHA-384, और SHA-512 का समर्थन करना आवश्यक है। उन्हीं का उपयोग करें।
एक वैध अपडेट के बाद हैश को अपडेट न करना। SRI एक बग नहीं, बल्कि एक फीचर है। यदि आप जिस फ़ाइल से लिंक कर रहे हैं, वह किसी भी कारण से अपडेट हो जाती है, तो आपको एक नया इंटेग्रिटी हैश जेनरेट करना होगा और अपने HTML integrity एट्रिब्यूट को अपडेट करना होगा। ऐसा करने में विफलता के परिणामस्वरूप रिसोर्स ब्लॉक हो जाएगा।
यह सोचना कि यह आपके अपने सर्वर की सुरक्षा करता है। SRI को थर्ड-पार्टी रिसोर्सेज को मान्य करने के लिए डिज़ाइन किया गया है। यदि किसी हमलावर ने आपके सर्वर से इतनी छेड़छाड़ की है कि वह आपकी HTML फ़ाइलों को बदल सकता है, तो वे बस अपनी दुर्भावनापूर्ण स्क्रिप्ट से मेल खाने के लिए SRI हैश को बदल सकते हैं। यह समान-ऑरिजिन रिसोर्सेज के लिए कोई लाभ प्रदान नहीं करता है।

यह आपके रडार पर क्यों होना चाहिए

आपको हर बार SRI के बारे में सोचना चाहिए जब आप एक <script src="..."> या <link rel="stylesheet" href="..."> लिखते हैं जो एक ऐसे डोमेन की ओर इशारा करता है जिसे आप नियंत्रित नहीं करते हैं।

यह आधुनिक वेब सुरक्षा का एक मूलभूत हिस्सा है। NPM, CDNs, और थर्ड-पार्टी निर्भरता के एक जटिल जाल पर बनी दुनिया में, आपकी सप्लाई चेन एक बहुत बड़ा अटैक सरफेस है। SRI उस सतह को कठोर करने के लिए सबसे सरल और सबसे प्रभावी उपकरणों में से एक है। यह एक समझौता किए गए CDN के खिलाफ आपकी रक्षा की पहली पंक्ति है। कंटेंट सिक्योरिटी पॉलिसी (CSP) के साथ मिलकर, यह मजबूत, स्तरित सुरक्षा प्रदान करता है।

जब आप कोई रिसोर्स जोड़ते हैं तो SRI जोड़ने में कुछ अतिरिक्त सेकंड लगते हैं, लेकिन यह आपको भविष्य में बहुत दर्द से बचा सकता है। यह एक शांत, खतरनाक कारनामे को एक ज़ोरदार, सुरक्षित विफलता में बदल देता है।

और गहराई से जानें

MDN Web Docs: Subresource Integrity - डेवलपर्स के लिए निश्चित संदर्भ।
W3C Recommendation: Subresource Integrity - आधिकारिक तकनीकी विनिर्देश। यदि आप सबसे गहरी जानकारी चाहते हैं, तो यह वही है।
Can I use... Subresource Integrity - SRI के लिए अद्यतित ब्राउज़र संगतता चार्ट।
Wikipedia: Cryptographic hash function - SRI के पीछे "फिंगरप्रिंटिंग" के जादू को बेहतर ढंग से समझने के लिए।
Scott Helme: Subresource Integrity - एक सुरक्षा विशेषज्ञ का क्या, क्यों और कैसे पर एक शानदार ब्लॉग पोस्ट।