- Polyfill.js पुराने ब्राउज़र सपोर्ट के लिए एक open source लाइब्रेरी है, जिसका उपयोग 1 लाख से अधिक साइटों पर हो रहा है
- इस साल फ़रवरी में, एक चीनी कंपनी ने Polyfill.js का डोमेन और GitHub अकाउंट अधिग्रहित करने के बाद, उस डोमेन के ज़रिए मोबाइल डिवाइसों में malware inject करना शुरू कर दिया
- 25 जून अपडेट: Google ने पहले ही polyfill.io का उपयोग करने वाली e-commerce साइटों के Google Ads को ब्लॉक करना शुरू कर दिया है
- अटैक का तरीका: HTTP header के आधार पर dynamically generated code केवल कुछ खास मोबाइल डिवाइसों पर और कुछ खास समय पर ही सक्रिय होता है, और यदि admin user या web analytics service की पहचान हो जाए तो execution में देरी करता है
- malware का उदाहरण: मोबाइल यूज़र्स को फ़र्ज़ी Google Analytics डोमेन (www. googie-anaiytics .com) के ज़रिए sports betting साइटों पर redirect करना
- समाधान: Polyfill.js के मूल लेखक ने सलाह दी है कि modern browser में इसकी अब ज़रूरत नहीं है, इसलिए इस लाइब्रेरी का उपयोग अब नहीं करना चाहिए, और Fastly व Cloudflare भरोसेमंद alternatives प्रदान करते हैं
- यह घटना एक विशिष्ट सप्लाई चेन अटैक का उदाहरण है
- अतिरिक्त टूल: Sansec की मुफ्त CSP monitoring service, Sansec Watch, और eComscan backend scanner, Polyfill.io detection को सपोर्ट करते हैं
GN⁺ की राय
- सप्लाई चेन अटैक का जोखिम: यह open source प्रोजेक्ट के अधिग्रहण के बाद पैदा हो सकने वाले security risk का एक स्पष्ट उदाहरण है। खासकर, जितनी अधिक साइटों में उपयोग होने वाली लाइब्रेरी होगी, नुकसान उतना बड़ा हो सकता है।
- वैकल्पिक लाइब्रेरी का उपयोग: Fastly और Cloudflare जैसे भरोसेमंद alternatives का उपयोग करना महत्वपूर्ण है। साथ ही, यदि नवीनतम ब्राउज़र सपोर्ट पर्याप्त है, तो Polyfill.js का उपयोग बंद करने पर भी विचार किया जा सकता है।
- security monitoring की ज़रूरत: CSP monitoring service जैसे security tools का उपयोग करके code changes पर real time में नज़र रखना महत्वपूर्ण है।
- admin detection और delayed execution: malware का admin या analytics service को पहचानकर execution में देरी करना security solution को bypass करने की कोशिश है, और इसके लिए समाधान की ज़रूरत है।
- शिक्षा और जागरूकता बढ़ाना: डेवलपर्स और operators के लिए सप्लाई चेन अटैक के जोखिम को समझना, नियमित security training करना और नवीनतम security trends पर नज़र रखना महत्वपूर्ण है।
3 टिप्पणियां
कहा जा रहा है कि सिर्फ
polyfill.ioडोमेन ही नहीं, बल्किbootcdn.net,bootcss.com,staticfile.net,staticfile.org,unionadjs.com,xhsbpza.com,union.macoms.la,newcrbpc.comआदि को भी ब्लॉक करना चाहिए।https://hi.news.hada.io/topic?id=15118
करीब एक महीने पहले यह मुद्दा GN में उठाया गया था, तब से मैं इसे दिलचस्पी के साथ देख रहा हूँ. भले ही समस्या की वजह कुछ हद तक साफ हो जाए, फिर भी ऐसा लगता है कि सुधार और बाद की कार्रवाई में लगने वाले समय के दौरान बहुत सी जगहें लगातार हमलों के संपर्क में बनी रहेंगी. घुसपैठ की घटनाएँ लगातार बढ़ रही हैं और security experts की कमी भी हो रही है, इसलिए चिंता होती है कि यह स्थिति कुछ समय तक और गंभीर होती जाएगी.
Hacker News की राय
पब्लिक CDN इस्तेमाल करने का जोखिम: पब्लिक CDN का उपयोग करने पर मोबाइल डिवाइसों में malicious code inject किया जा सकता है। इसे कम करने के लिए SRI (Subresource Integrity) का उपयोग किया जा सकता है, लेकिन सबसे अच्छा समाधान CDN service के जरिए इसे सीधे host करना है।
गेम थ्योरी का दृष्टिकोण: open source software maintenance में बिना किसी reward के बहुत-सी sites को support करना पड़ता है, और इससे अंततः security issues पैदा हो सकते हैं।
Washington Post और Fox News का external content: दोनों websites में बहुत सारा external content शामिल है, और यह attack target बन सकता है।
Cloudflare का अनुमान: Cloudflare ने पहले ही इस समस्या का अनुमान लगा लिया था और इसे कम करने के लिए solutions दिए थे।
polyfill service के संस्थापक की राय: उन्होंने polyfill service project बनाया था, लेकिन domain ownership उनके पास नहीं थी, और अभी वह domain malicious code inject कर रहा है। तुरंत इसका उपयोग बंद करने की सलाह दी गई है।
पहले से अनुमानित समस्या: यह 4 महीने पहले से अनुमानित समस्या थी, और अधिक लोगों को इसके बारे में जागरूक होकर कार्रवाई करनी चाहिए थी।
sports betting site पर redirect: कुछ मामलों में users को उनकी इच्छा के खिलाफ दूसरी sites पर redirect किया जा सकता है, और यह कुछ users पर प्रभावी हो सकता है।
SRI का ज़िक्र न होना: यह हैरानी की बात है कि article में SRI का ज़िक्र नहीं है। SRI कम लागत वाला और बहुत प्रभावी समाधान है।
developers के साथ बातचीत: कई developers CDN hijacking को लेकर उदासीन हैं, और इससे security issues पैदा हो सकते हैं।
self-hosting की सिफारिश: dependencies को हमेशा खुद host करना बेहतर है, और इससे user privacy की रक्षा करने में भी मदद मिलती है।