डेवलपर टूल · SHA हैश कैलकुलेटर
उपसंसाधन अखंडता: स्क्रिप्ट की जांच करने के लिए ब्राउज़र SHA-384 का उपयोग कैसे करते हैं
· पेजभूमि
शा-256 Base64 ब्राउज़र-एपिस सुरक्षा
अखंडता विशेषता ब्राउज़र को CDN स्क्रिप्ट को अस्वीकार करने देती है जिसके बाइट्स बदल गए हैं। यह पोस्ट विशेषता के प्रारूप की व्याख्या करती है, क्यों Base64 में SHA-384 आम पसंद है, और SRI किस चीज़ से सुरक्षा नहीं कर सकता है।
CDN जो किसी भी चीज़ की सेवा कर सकता है - आपूर्ति-श्रृंखला जोखिम SRI के लिए डिज़ाइन किया गया था
किसी वेब पेज पर एक स्क्रिप्ट टैग में एक अखंडता विशेषता हो सकती है: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`। अखंडता मान स्क्रिप्ट के बाइट्स का एक क्रिप्टोग्राफ़िक डाइजेस्ट है। जब ब्राउज़र स्क्रिप्ट डाउनलोड करता है, तो यह प्राप्त बाइट्स के डाइजेस्ट की गणना करता है और अखंडता विशेषता के विरुद्ध तुलना करता है। यदि वे मेल खाते हैं, तो स्क्रिप्ट लोड हो जाती है। यदि वे मेल नहीं खाते हैं, तो ब्राउज़र इसे लोड करने से इंकार कर देता है और कंसोल में विफलता की रिपोर्ट करता है। यह संशोधित कोड परोसने वाले CDN से, या नेटवर्क हमलावर द्वारा प्रतिक्रिया को रोकने और बदलने से बचाता है।
सबरिसोर्स इंटीग्रिटी (SRI) एक W3C विशिष्टता है जो स्क्रिप्ट और स्टाइलशीट पर लागू होती है। यह एकमात्र क्रिप्टोग्राफ़िक गारंटी है जो एक ब्राउज़र क्रॉस-ओरिजिनल संसाधन की सामग्री के बारे में कर सकता है: बाइट्स को डाइजेस्ट से मेल खाना चाहिए, या संसाधन अस्वीकार कर दिया जाएगा। इससे यह साबित नहीं होता कि संसाधन किसने बनाया, केवल यह कि डाइजेस्ट की गणना के बाद से इसमें कोई बदलाव नहीं हुआ है। एक प्रतिष्ठित CDN से HTTPS पर परोसे गए संसाधन के लिए, डाइजेस्ट CDN के साथ छेड़छाड़ होने या विशेष रूप से आपको पुरानी कैश्ड सामग्री परोसने के खिलाफ सुरक्षा प्रदान करता है।
अखंडता विशेषता - एल्गोरिदम उपसर्ग, हाइफ़न, Base64 डाइजेस्ट, और एकाधिक हैश के लिए समर्थन
अखंडता विशेषता का एक विशिष्ट प्रारूप होता है: एल्गोरिदम-नाम, हाइफ़न, Base64 में डाइजेस्ट। उदाहरण: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. एल्गोरिदम का नाम SHA-256, SHA-384 या SHA-512 हो सकता है। Base64 एन्कोडिंग है, हेक्साडेसिमल नहीं; यह SRI विनिर्देश द्वारा जानबूझकर किया गया चयन है। Base64 हेक्स की तुलना में अधिक कॉम्पैक्ट है (समान डाइजेस्ट के लिए लगभग 33% shorter), जो HTML विशेषताओं में एम्बेड करते समय मायने रखता है। हाइफ़न एल्गोरिथम नाम को डाइजेस्ट से अलग करता है। एकाधिक अखंडता मानों को सूचीबद्ध किया जा सकता है, स्थान से अलग किया जा सकता है: यदि उनमें से कोई भी मेल खाता है, तो संसाधन स्वीकार कर लिया जाता है।
SHA-384 क्यों? SRI विनिर्देश SHA-256, SHA-384 और SHA-512 की अनुमति देता है। SHA-384 समुदाय डिफ़ॉल्ट बन गया क्योंकि यह आकार /security संतुलन प्रदान करता है। SHA-256 छोटा है (Base64 में 32 bytes, 44 वर्ण) लेकिन SHA-384 व्यापक है (Base64 में 48 bytes, 64 वर्ण) और SHA-256 की तुलना में विशेषता आकार में सार्थक वृद्धि नहीं करता है। SHA-512 उपलब्ध है लेकिन इसका उपयोग शायद ही कभी किया जाता है क्योंकि इसका बड़ा डाइजेस्ट इस उपयोग के मामले के लिए आवश्यक नहीं लगता है। SHA-384 का चुनाव ऐतिहासिक और व्यावहारिक है, न कि बेहतर सुरक्षा गुणों का प्रतिबिंब (इस उद्देश्य के लिए तीनों क्रिप्टोग्राफ़िक रूप से मजबूत हैं)।
SHA-384 की पेशकश की जाती है और यह आवश्यक Base64 सामग्री का उत्पादन करता है; टूल से सामुदायिक प्राथमिकता का अनुमान नहीं लगाया जाता है
SRI में Base64 एन्कोडिंग मानक Base64 है, Base64url नहीं। मानक Base64 + और / वर्णों का उपयोग करता है, जो प्रतिशत-एन्कोडिंग के बिना HTML विशेषताओं में मान्य हैं, हालांकि URL और फॉर्म डेटा में उनके विशेष अर्थ हैं। SRI प्रारूप HTML विशेषताओं के लिए डिज़ाइन किया गया है, URL के लिए नहीं, इसलिए मानक Base64 उपयुक्त है। यदि आप हाथ से एक अखंडता मान बना रहे हैं, तो आप SHA-384 डाइजेस्ट (बाइट्स का एक क्रम) की गणना करते हैं, फिर उन बाइट्स को मानक Base64 के रूप में एन्कोड करते हैं, फिर `sha384-` को जोड़ते हैं और अखंडता विशेषता में पेस्ट करते हैं।
ब्राउज़र समान चरणों को उल्टा करता है: अखंडता विशेषता से Base64 निकालें, डाइजेस्ट को पुनर्प्राप्त करने के लिए बाइट्स को डीकोड करें, डाउनलोड की गई स्क्रिप्ट बाइट्स के SHA-384 की गणना करें और दो डाइजेस्ट मानों की तुलना करें। उन्हें बिल्कुल मेल खाना चाहिए; डाइजेस्ट में एक-बिट अंतर अस्वीकृति का कारण बनता है। कोई अस्पष्ट मिलान या आंशिक क्रेडिट नहीं है: अखंडता द्विआधारी है।
क्रॉस-ओरिजिन SRI व्यवहार के लिए इस हैश कैलकुलेटर से परे ब्राउज़र दस्तावेज़ की आवश्यकता होती है
क्रॉस-ऑरिजिन प्रतिक्रियाओं पर SRI को CORS की आवश्यकता होती है। यदि आप किसी भिन्न मूल से स्क्रिप्ट लोड करते हैं, तो सर्वर को `Access-Control-Allow-Origin: *` या एक विशिष्ट मूल हेडर के साथ प्रतिक्रिया देनी होगी जिसमें आपका भी शामिल है। CORS हेडर के बिना, ब्राउज़र SRI की जांच नहीं कर सकता, क्योंकि CORS के बिना यह पुष्टि नहीं कर सकता कि प्रतिक्रिया निकाय सर्वर द्वारा भेजे जाने वाले संदेश से मेल खाता है। CORS हेडर सर्वर का कथन है कि यह प्रतिक्रिया जांचने के लिए सुरक्षित है; SRI आपकी जांच है कि बाइट्स सही हैं। साथ में, वे एक आपूर्ति-श्रृंखला प्रतिबद्धता बनाते हैं: सर्वर आपको सामग्री को सत्यापित करने की अनुमति देता है, और आप ऐसा करते हैं।
यदि किसी क्रॉस-ओरिजिनल स्क्रिप्ट में CORS हेडर का अभाव है और उसमें एक अखंडता विशेषता है, तो ब्राउज़र इसे डाउनलोड करेगा (यदि उस मूल की स्क्रिप्ट को साइट के CSP द्वारा अनुमति दी गई है), लेकिन यह अखंडता को सत्यापित नहीं करेगा। स्क्रिप्ट को ऐसे लोड किया जाएगा जैसे कि अखंडता विशेषता अनुपस्थित थी। यह SRI की विफलता नहीं है; यह एक सुरक्षा सीमा है: आप उस प्रतिक्रिया को सत्यापित नहीं कर सकते जिसे आप पढ़ नहीं सकते।
बेमेल होने पर क्या होता है - ब्राउज़र संसाधन को ब्लॉक कर देता है और कंसोल में रिपोर्ट करता है
जब ब्राउज़र एक अखंडता बेमेल का पता लगाता है, तो यह स्क्रिप्ट को निष्पादित करने से इंकार कर देता है और ब्राउज़र कंसोल में एक संदेश लॉग करता है। संदेश आम तौर पर URL, अपेक्षित हैश और परिकलित हैश का नाम देता है। विफलता परमाणु है: या तो संसाधन को वैसे ही लोड किया जाता है या इसे पूरी तरह से अस्वीकार कर दिया जाता है। कोई आंशिक लोडिंग या फ़ॉलबैक नहीं है. यदि कोई वेबसाइट उस स्क्रिप्ट पर भरोसा करती है और उसे अस्वीकार कर दिया जाता है, तो साइट टूट सकती है। यह जानबूझकर किया गया है: गलत कोड डिलीवर करना बिना कोड डिलीवर करने से भी बदतर है, और मौन विफलताएं हमलों को अनिश्चित काल तक जारी रखने में सक्षम बनाती हैं।
SRI सेटअप का परीक्षण करना सीधा है: ब्राउज़र कंसोल खोलें, पेज लोड करें और अखंडता बेमेल के बारे में संदेश देखें। यदि आपको कोई बेमेल दिखाई देता है, तो कंसोल में दिखाए गए गणना किए गए हैश की तुलना अपनी अखंडता विशेषता में दिखाए गए हैश से करें। यदि वे मेल नहीं खाते हैं, तो पुनः गणना करें: स्क्रिप्ट अद्यतन हो गई होगी और आपको एक नए डाइजेस्ट की आवश्यकता होगी।
कार्यान्वित उदाहरण - एक स्क्रिप्ट के लिए डाइजेस्ट की गणना करना और इसे Base64 चरण सहित एक अखंडता मान में स्वरूपित करना
SRI डाइजेस्ट की मैन्युअल रूप से गणना करने के लिए केवल स्क्रिप्ट बाइट्स और एक हैश टूल की आवश्यकता होती है। स्क्रिप्ट डाउनलोड करें, इसे ToolAcre SHA हैश कैलकुलेटर में पेस्ट करें, SHA-384 चुनें, Base64 आउटपुट कॉपी करें (हेक्स नहीं), `sha384-` को प्रीपेन्ड करें और इंटीग्रिटी एट्रिब्यूट में पेस्ट करें। यदि स्क्रिप्ट बड़ी है, तो उसे किसी फ़ाइल में सहेजने के लिए कर्ल या wget का उपयोग करना और फिर फ़ाइल को पढ़ना, चिपकाने की तुलना में तेज़ है। इनलाइन स्क्रिप्ट के लिए (URL के बजाय HTML में `<script>` टैग में), SRI लागू नहीं होता है; परिभाषा के अनुसार इनलाइन स्क्रिप्ट पर हमेशा भरोसा किया जाता है। SRI बाहरी संसाधनों के लिए है।
एक कारगर उदाहरण: मान लीजिए कि आप CDN से SRI के साथ jQuery लोड करना चाहते हैं। स्क्रिप्ट URL ढूंढें, इसे डाउनलोड करें (या इसे लाने के लिए कर्ल का उपयोग करें), बाइट्स को कैलकुलेटर में पेस्ट करें या कमांड लाइन पर `sha384sum` का उपयोग करें, SHA-384 डाइजेस्ट को Base64 के रूप में प्राप्त करें, और `sha384-[base64-digest]` के रूप में प्रारूपित करें। स्क्रिप्ट टैग की अखंडता विशेषता में चिपकाएँ। पेज लोड करें और सत्यापित करें कि कोई कंसोल त्रुटियाँ दिखाई न दें।
इसमें क्या शामिल नहीं है - स्क्रिप्ट जो जानबूझकर बदलती हैं, और ToolAcre जैसी साइटें जो बिल्कुल भी बाहरी स्क्रिप्ट लोड नहीं करती हैं और इसलिए उनके पास पिन करने के लिए कुछ भी नहीं है
SRI सभी आपूर्ति-श्रृंखला हमलों से रक्षा नहीं करता है। यह डाइजेस्ट की गणना के बाद बाइट्स को बदलने से बचाता है, लेकिन शुरू में समझौता किए गए कोड से डाइजेस्ट की गणना करने से नहीं। यदि आपके द्वारा डाइजेस्ट की गणना करने से पहले CDN से छेड़छाड़ की जाती है, तो SRI मदद नहीं कर सकता। डाइजेस्ट उतना ही भरोसेमंद है जितना वह स्रोत जिससे आपने इसकी गणना की है। अधिकतम आश्वासन के लिए, मूल स्रोत से डाइजेस्ट की गणना करें (उदाहरण के लिए, लाइब्रेरी का GitHub रिलीज़) और CDN से लोड करते समय उन डाइजेस्ट का उपयोग करें। रिलीज़ प्रक्रिया के माध्यम से डाइजेस्ट अनुरक्षक की ओर से एक प्रतिबद्धता बन जाता है।
SRI आपके द्वारा डाइजेस्ट की गणना करते समय किसी समझौता किए गए नेटवर्क से, या समझौता किए गए विकास मशीन से भी सुरक्षा नहीं करता है। यह केवल डाइजेस्ट बनने के समय और ब्राउज़र द्वारा स्क्रिप्ट लोड करने के समय के बीच स्क्रिप्ट में होने वाले परिवर्तनों से बचाता है। चल रहे आश्वासन के लिए, कुछ परिनियोजन SRI के अलावा रिलीज़ साइनिंग का उपयोग करते हैं: रिलीज़ को एक अनुरक्षक की कुंजी द्वारा हस्ताक्षरित किया जाता है, आप हस्ताक्षर को सत्यापित करते हैं, सत्यापित बाइट्स से डाइजेस्ट की गणना करते हैं और उसे SRI में उपयोग करते हैं।
यह आलेख हैश स्रोतों से ToolAcre की साइट-व्यापी बाहरी-स्क्रिप्ट सूची पर जोर नहीं देता है
ToolAcre SHA हैश कैलकुलेटर सीधे मानक Base64 में डाइजेस्ट उत्सर्जित करता है (`toBase64()` फ़ंक्शन से `base64` आउटपुट के रूप में)। SRI प्रारूप में कन्वर्ट करने के लिए, एल्गोरिदम नाम और एक हाइफ़न जोड़ें: `sha256-`, `sha384-` या `sha512-`। कैलकुलेटर उस उपसर्ग को स्वचालित रूप से लागू नहीं करता है क्योंकि हैश कई संदर्भों (जीआईटी, Docker, एनपीएम, URL) में दिखाई देता है जहां एल्गोरिदम का नाम अलग होता है या अलग तरीके से एन्कोड किया जाता है। सीमा स्पष्ट है: कैलकुलेटर आपके द्वारा पेस्ट किए गए UTF-8 टेक्स्ट को हैश करता है, फ़ाइलों या बाइनरी कुंजियों को नहीं। यह हेक्स और Base64 दोनों को आउटपुट करता है। आप अपने संदर्भ के आधार पर चुनते हैं कि किसका उपयोग करना है। SRI के लिए, विनिर्देश के अनुसार Base64 आवश्यक है। गिट और अन्य टूलों के लिए, हेक्स पारंपरिक है। एनपीएम और गो के लिए, Base64 का उपयोग किया जाता है। एन्कोडिंग विकल्प आपका है; डाइजेस्ट बाइट्स समान हैं.
SRI उन कुछ क्रिप्टोग्राफ़िक जांचों में से एक है जो एक ब्राउज़र केंद्रीकृत प्राधिकरण के बिना क्लाइंट-साइड पर कर सकता है। कंप्यूटिंग अपने आप को ToolAcre के SHA कैलकुलेटर जैसे विश्वसनीय टूल के साथ पचाती है और लोड किए गए संसाधनों के विरुद्ध उन्हें सत्यापित करना कुछ आपूर्ति-श्रृंखला हमलों के खिलाफ एक वेबसाइट को मजबूत करने का एक सुलभ तरीका है। सुरक्षा केवल पाचन जितनी ही अच्छी है; बाहरी संसाधन के प्रत्येक अद्यतन के बाद पुनः गणना करें और परीक्षण करें कि ब्राउज़र स्क्रिप्ट को अस्वीकार किए बिना लोड करता है।