मैं यह कैसे सुनिश्चित कर सकता हूं कि सीडीएन पर दी गई मेरी जावास्क्रिप्ट फाइलें बदल नहीं रही हैं?

Question

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

मैं समझता हूं कि अगर मैं एसएसएल का उपयोग कर रहा हूं तो यह कार्य बहुत आसान है, लेकिन फिर भी, मैं यह सुनिश्चित करना चाहता हूं कि एसएसएल के बिना HTTP पर भी सही फाइलें परोसी जाएं।

जहाँ तक मैं खोज सकता हूँ, जावास्क्रिप्ट फ़ाइलों के लिए डिजिटल हस्ताक्षर जैसा कोई मौजूदा तंत्र नहीं है जो प्लेटफ़ॉर्म पर समर्थित है। शायद इसकी जरूरत नहीं है?

क्या जावास्क्रिप्ट फ़ाइलों के लेखक को सत्यापित करने के लिए ब्राउज़रों में कुछ विधि बनाई गई है? क्या ऐसा कुछ है जो मैं इसे सुरक्षित तरीके से करने के लिए कर सकता हूं?

Comments

जब भी मुझे यह सवाल दिलचस्प लगता है, क्या यह ऑफ टॉपिक नहीं है?

— evolutionxbox

आप http पर फ़ाइलों की सेवा क्यों करेंगे?

— njzk2

"लेकिन ऐसा कोई तंत्र क्यों नहीं है?" क्योंकि यह वास्तव में कठिन है । एक बार जब आपका डेटा आपके सर्वर से निकल जाता है, तो यह टोस्ट होता है। HTTPS मदद करता है लेकिन अगर यह एक सादा HTTP कनेक्शन है तो कोई भी सत्यापन विफल हो सकता है (या बल्कि - पास)। एक MITM हमला आपके अपेक्षित हस्ताक्षर और / या आपके द्वारा ब्राउज़र से पहले जो भी प्रदान किया जाता है उसके हस्ताक्षर संशोधित कर सकते हैं। इसलिए, जब उपयोगकर्ता कुछ पेलोड प्राप्त करता है तो इसे पूरी तरह से सुरक्षित माना जाएगा ... जब यह जरूरी नहीं है कि।

— वीएलजी

"लेकिन ऐसा कोई तंत्र क्यों नहीं है?" क्योंकि HTTPS में पहले से ही एक सस्ता, प्रभावी और व्यापक रूप से लागू समाधान है।

— केविन क्रुमविडे 21

यह संभवतः सर्वरफॉल्ट या सिक्योरिटी पर होना चाहिए, क्योंकि यह वास्तव में सुरक्षित तरीके से फाइल परोसने के बारे में है, और प्रोग्रामिंग का कोई भी संबंध केवल स्पर्शशील है क्योंकि कहा जाता है कि फाइल सोर्स कोड का प्रतिनिधित्व करते हैं।

— अंडरस्कोर_ड

Answer 1

तथ्य की बात के रूप में, इस तरह की एक सुविधा वर्तमान में सबस्रोइट इंटीग्रिटी के नाम से तैयार की जा रही है । टैग की integrityविशेषता देखें <script>। जबकि बोर्ड में अभी तक पूरी तरह से अपनाया नहीं गया है , यह सिर्फ इस उद्देश्य को पूरा करता है।

integrity

इनलाइन मेटाडेटा समाहित करता है जो एक उपयोगकर्ता एजेंट यह सत्यापित करने के लिए उपयोग कर सकता है कि एक भ्रूण संसाधन को अप्रत्याशित हेरफेर से मुक्त किया गया है। Subresource Integrity देखें।

स्रोत

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

स्रोत

---

उदाहरण:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

---

ध्यान दें कि यदि आप अपने संसाधनों को सादे HTTP के माध्यम से स्थानांतरित कर रहे हैं तो यह मध्य हमलों में मैन के खिलाफ आपकी रक्षा नहीं करेगा । इस मामले में, हैश कोड को हमलावर द्वारा खराब किया जा सकता है, जो बेकार हो चुकी स्क्रिप्ट फ़ाइलों के खिलाफ बचाव का प्रतिपादन करता है।

इस कारण से, आपको हमेशा ऊपर वर्णित सुरक्षा उपायों के अलावा, सादे HTTP के बजाय सुरक्षित HTTPS कनेक्शन का उपयोग करना चाहिए।

Comments

मुझे लगता है कि यह ध्यान देने योग्य है कि अखंडता की जांच आसानी से यह मानते हुए खराब हो सकती है कि ओपी अपने एचटीएमएल के साथ-साथ अपनी संपत्ति फ़ाइलों में एचटीएमएल भेजने की योजना बना रहा है। यदि उनकी साइट HTTPS है और वे HTTP के माध्यम से संपत्ति की सेवा करना चाहते हैं तो अधिकांश ब्राउज़र इसे पसंद नहीं करने वाले हैं और चुपचाप HTTP परिसंपत्तियों की उपेक्षा करते हैं।

— मंकीज़े

@MonkeyZeus यह केवल तभी सही होगा जब MITM हमले के मामले में या यदि हमारा स्वयं का सर्वर समझौता किया गया हो, सही है? मेरी समझ यह है कि प्रश्न स्पष्ट रूप से पूछता है कि एक समझौता किए गए सीडीएन के खिलाफ कैसे बचाव किया जाए।

— तिमो

@TimoSta बिल्कुल! इन जांचों के बिना, यदि आप उदाहरण के लिए स्क्रिप्ट शामिल करते हैं https://code.jquery.com/, तो कोई भी व्यक्ति जो code.jquery.comआपकी साइट पर XSS कर सकता है, चाहे वह code.jquery.comHTTPS पर एक्सेस किया जा रहा हो या नहीं । इन चेकों के स्थान पर हमलावर केवल लिपियों को लोड होने से रोक सकता है, न कि उन्हें दुर्भावना से बदलने का।

— Ajedi32

@MonkeyZeus मैंने आपकी चिंताओं को बताते हुए मेरे उत्तर में एक नोट जोड़ा। क्या आप शब्दांकन से सहमत हैं?

— तिमो

@TimoSta बहुत अच्छा, मुझे यह पसंद है! btw, मैंने अपनी पहली टिप्पणी :-) पोस्ट करने से पहले भी +1 किया था

— मंकीज़ियस

Answer 2

आप सबस्रोइट अखंडता की तलाश कर रहे हैं जांच के ।

उदाहरण के लिए, यहाँ jQuery CDN स्निपेट है:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>

Comments

पूरी तरह से बेकार क्योंकि एक हमलावर अखंडता क्षेत्र को उसी समय संशोधित कर सकता है जब वे उस स्क्रिप्ट को संशोधित करते हैं जिसे आप डाउनलोड कर रहे हैं।

— ऑर्बिट

@LightnessRacesinOrbit: यदि आप अपने स्वयं के डोमेन को नियंत्रित नहीं करते हैं जो HTTPS तक पहुँचा है लेकिन नियंत्रण नहीं है code.jquery.com। यह आपको एक समझौता करने से बचा सकता है code.jquery.com।

— सिल्वरलाइटफॉक्स

@SilverlightFox: ठीक है, MITM हमलों के खिलाफ पूरी तरह से बेकार *

— को कक्षा में

@LightnessRacesinOrbit हां। फिर भी बहुत उपयोगी है और उदाहरण के लिए इस हमले को रोका होगा: bleepingcomputer.com/news/security/…

— एड्रियन मौट

Answer 3

अस्वीकरण: हमेशा की तरह, आपको केवल https का उपयोग करते समय इन तंत्रों के किसी भी उपयोग के बारे में विचार करना चाहिए, क्योंकि वे http के साथ मिटम के माध्यम से आसानी से अक्षम हो सकते हैं

उपरोक्त उत्तरों में तंत्र के अलावा, आप मूल पृष्ठ पर सामग्री-सुरक्षा नीति http प्रतिक्रिया शीर्षकों का भी उपयोग कर सकते हैं ।

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

सामग्री-सुरक्षा-नीति: स्क्रिप्ट- src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

यहाँ ध्यान देने योग्य बातें हैं। Sha * - उपसर्ग हैश उत्पन्न करने के लिए उपयोग किए जाने वाले एल्गोरिथ्म को निर्दिष्ट करता है। उपरोक्त उदाहरण में, sha256- का उपयोग किया जाता है। CSP भी sha384- और sha512- का समर्थन करता है। हैश बनाते समय टैग शामिल नहीं हैं। इसके अलावा पूंजीकरण और व्हाट्सएप मामला, जिसमें व्हाट्सएप प्रमुख या अनुगामी है।

Chrome 40 का उपयोग करना या बाद में आप DevTools खोल सकते हैं, फिर अपना पृष्ठ पुनः लोड कर सकते हैं। कंसोल टैब में आपकी प्रत्येक इनलाइन स्क्रिप्ट के लिए सही sha256 हैश के साथ त्रुटि संदेश होंगे।

यह तंत्र लगभग कुछ समय के लिए रहा है, इसलिए ब्राउज़र का समर्थन बहुत अच्छा है, बस जाँच करना सुनिश्चित करें।

इसके अतिरिक्त, यदि आप यह सुनिश्चित करना चाहते हैं कि पुराने गैर-अनुपालन वाले ब्राउज़र असुरक्षित नहीं हैं, तो आप उस पृष्ठ के शीर्ष पर एक तुल्यकालिक पुनर्निर्देशित स्क्रिप्ट शामिल कर सकते हैं जिसे नीति द्वारा अनुमति नहीं है।

Comments

लगभग कुछ समय के लिए किया गया है, लेकिन ब्राउज़र का समर्थन बहुत अच्छा नहीं है। caniuse.com/subresource-integrity

— Sp0T

@ Sp0t - सबसोर्स सोर्स अखंडता (आपका लिंक क्या है) अन्य उत्तरों में तंत्र है। मेरा जवाब सामग्री सुरक्षा नीति के बारे में है, जिसमें बहुत बेहतर समर्थन है

— फैबियो बेल्ट्रामिनी

Answer 4

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

Answer 5

यदि आपका विरोधी मॉडल किसी हमलावर को जावास्क्रिप्ट फ़ाइलों को संशोधित करने की अनुमति देता है क्योंकि वे CDN से वितरित होते हैं, तो आपका विरोधी मॉडल हमलावर को संशोधित करने के लिए स्रोत को संशोधित करने की अनुमति देता है क्योंकि यह सत्यापन पर किसी भी प्रयास को हटाने के लिए, स्रोत पते को अन्य से बदलने के लिए दिया जाता है। सीडीएन, और / या जावास्क्रिप्ट के संदर्भ को पूरी तरह से हटाने के लिए।

और आपके एप्लिकेशन का निर्धारण कैसे कर सकते हैं कि उपयोगकर्ता का रिज़ॉल्वर क्या है या HTTP अनुरोधों के माध्यम से CDN के लिए सही ढंग से हल नहीं हो रहा है (या किसी अन्य तंत्र में विश्वास की सत्यापित श्रृंखला नहीं है), के कीड़ों को खोलने की अनुमति नहीं देता है।

/ Etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...

Comments

पहला वाक्य स्पष्ट रूप से असत्य है। क्या होगा यदि संदर्भित पृष्ठ HTTPS पर लोड हो और जावास्क्रिप्ट फ़ाइल HTTP-not-S पर लोड हो?

— user253751

या क्या होगा यदि CDN स्वयं समझौता किया गया है, लेकिन आपका अपना सर्वर नहीं है?

— Ajedi32

@ मिनीबिस: मैं यह मान सकता हूं कि ओपी इतना तर्कहीन नहीं है कि इस तरह के परिदृश्य का प्रस्ताव रखा जाए।

— एरिक टावर्स

@immibis यह नहीं है कि आमतौर पर ब्राउज़र HTTPS पृष्ठों को HTTP पर JS लोड करने की अनुमति क्यों नहीं देते हैं?

— बारमर

@ मिनीबिस मैं कह रहा था कि यह ऐसी स्थिति में सुधार करता है जो संभव भी नहीं है, क्योंकि ब्राउज़र इसे अस्वीकार कर देते हैं।

— बरमार

Answer 6

आप इसे Subresource Integrity के साथ सुनिश्चित कर सकते हैं। कई सार्वजनिक सीडीएन में सीडीएन वेबसाइटों पर दिए गए एम्बेड कोड में एसआरआई हैश शामिल हैं। उदाहरण के लिए, पेजसीडीएन पर, जब आप jQuery सीडीएन पृष्ठ पर jquery फ़ाइल पर क्लिक करते हैं, तो आपको URL की प्रतिलिपि बनाने या स्क्रिप्ट टैग का उपयोग करने का विकल्प मिलता है जिसमें नीचे SRI हैश होता है:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

पेज लोड होने पर, ब्राउज़र इस संसाधन के लिए एक अनुरोध जारी करेगा और अनुरोध पूरा होने पर यह स्क्रिप्ट टैग में अखंडता मान के रूप में प्राप्त फ़ाइल के हैश से मेल खाएगा। यदि दोनों हैश मेल नहीं खाते हैं, तो ब्राउज़र jquery फ़ाइल को छोड़ देगा।

फिलहाल, यह सुविधा दुनिया भर के 91% ब्राउज़रों द्वारा समर्थित है। कैनीयूज़ पर अधिक जानकारी ।