लेख के लेखक, जिसका अनुवाद आज हम प्रकाशित कर रहे हैं, का कहना है कि रिएक्ट इंटरएक्टिव इंटरफेस बनाने के लिए उसकी पसंदीदा लाइब्रेरी है। प्रतिक्रिया का उपयोग करना आसान है और काफी अच्छी तरह से संरक्षित है। हालांकि, इसका मतलब यह नहीं है कि रिएक्ट एप्लिकेशन पूरी तरह से अयोग्य हैं। मन की अनुचित शांति में गिरना बहुत आसान है, यह तय करने के बाद कि आप इस तथ्य के कारण XSS हमलों के बारे में चिंता नहीं कर सकते कि परियोजना रिएक्ट का उपयोग करती है।
रिएक्ट में कमजोरियां अक्सर तब होती हैं जब डेवलपर को लगता है कि वह इस पुस्तकालय के सुरक्षात्मक तंत्र का उपयोग कर रहा है, हालांकि वास्तव में यह पता चला है कि ऐसा नहीं है। इसलिए, प्रतिक्रिया की क्षमताओं का सही ढंग से मूल्यांकन करना महत्वपूर्ण है, और यह जानने के लिए कि एक प्रोग्रामर को अपने दम पर किन कार्यों को हल करने की आवश्यकता है।
आज हम विशिष्ट प्रतिक्रिया कमजोरियों के बारे में बात करेंगे, कि कोड समीक्षा के दौरान उन्हें कैसे खोजा जाए, और उनका बचाव कैसे किया जाए।
पहला (बहुत छोटा) क्रॉस-साइट स्क्रिप्टिंग उदाहरण
क्रॉस साइट स्क्रिप्टिंग (XSS) एक क्लाइंट भेद्यता है जो गंभीर समस्याएं पैदा कर सकती है। XSS हमले तब होते हैं जब कोई हमलावर किसी वेबसाइट को रौंदने में सक्षम होता है और उसे अपने उपयोगकर्ताओं के ब्राउज़र में मनमाने ढंग से जावास्क्रिप्ट कोड निष्पादित करने के लिए मजबूर करता है।
परिलक्षित XSS हमले को एक लिंक के माध्यम से किया जाता है जिसमें पाठ जानकारी होती है जो कोड के रूप में ब्राउज़र द्वारा संसाधित होती है। उदाहरण के लिए, यह एक प्रपत्र फ़ील्ड है जिसमें क्लाइंट साइड पर, एक विशेष अनुरोध पाठ दर्ज किया जाता है।
एक संग्रहीत XSS हमला एक ऐसी स्थिति है जिसमें एक हमलावर की सर्वर तक पहुंच होती है, और जब सर्वर पर निष्पादित कोड उत्पन्न होता है जो क्लाइंट के वेब पेज पर पहुंच जाता है। ऐसे हमलों के विशिष्ट वैक्टर सर्वरों पर टिप्पणियां और चित्र अपलोड कर रहे हैं।
सैमी कृमि ने MySSpace XSS भेद्यता का फायदा उठाया। यह अब तक के सबसे तेजी से फैलने वाले वायरस में से एक था।
कमजोर वेबसाइट अपने उपयोगकर्ताओं को पासवर्ड या व्यक्तिगत डेटा चोरी करने के लिए बेनकाब कर सकती हैं। और यह अन्य कमजोरियों का शोषण करने का सामान्य तरीका है। दुर्भावनापूर्ण स्क्रिप्ट का उपयोग अक्सर स्पैम भेजने और उपयोगकर्ताओं को धोखाधड़ी वाली साइटों पर पुनर्निर्देशित करने के लिए किया जाता है। यह एक सफलतापूर्वक हमला साइट की प्रतिष्ठा और एसईओ प्रदर्शन को नुकसान पहुंचा सकता है।
भेद्यता # 1: पृष्ठ की प्रारंभिक स्थिति पर नियंत्रण, जिसका उपयोग सर्वर रेंडरिंग के दौरान किया जाता है
कभी-कभी, जब हम किसी पृष्ठ की प्रारंभिक स्थिति बनाते हैं, तो हम, जो खतरनाक है, JSON स्ट्रिंग के आधार पर एक दस्तावेज़ बनाते हैं। कोड में यह भेद्यता कुछ इस तरह दिखाई देती है:
<script>window.__STATE__ = ${JSON.stringify({ data })}</script>
यह इस तथ्य के कारण खतरनाक है कि
JSON.stringify() विधि, बिना कुछ भी "सोच" के, इसे प्रदान किए गए किसी भी डेटा को स्ट्रिंग रूप में (जब तक यह वैध JSON डेटा है), जो है पृष्ठ पर प्रदर्शित किया जाएगा। यदि
{ data } पास ऐसे फ़ील्ड हैं जिन्हें कोई अविश्वासी उपयोगकर्ता संपादित कर सकता है, जैसे कि उपयोगकर्ता नाम या उपयोगकर्ता जानकारी, निम्नलिखित कुछ ऐसे क्षेत्रों में एम्बेड किए जा सकते हैं:
{ username: "pwned", bio: "</script><script>alert('XSS Vulnerability!')</script>" }
इस पैटर्न का उपयोग अक्सर Redux का उपयोग करने वाले रिएक्ट एप्लिकेशन के सर्वर-साइड रेंडरिंग में किया जाता है। वह आधिकारिक Redux दस्तावेज़ीकरण में मौजूद था, और परिणामस्वरूप, कई ट्यूटोरियल और नमूना एप्लिकेशन टेम्प्लेट जो कि GitHub पर पाए जा सकते हैं, इसका उपयोग करते हैं।
विश्वास नहीं होता? फिर अपने लिए देखें। पाठ के लिए Google खोजें "प्रतिक्रिया सर्वर साइड रेंडरिंग उदाहरण ऐप" और पहले पृष्ठ से किसी भी खोज परिणाम पर इस हमले का प्रयास करें।
। कोड समीक्षा के दौरान भेद्यता की पहचान
JSON.stringify() पद्धति के लिए कॉल देखें जो
JSON.stringify() चर को स्वीकार करते हैं जिनमें
script टैग में अविश्वसनीय डेटा हो सकता है। यहाँ एक उदाहरण है जो Redux प्रलेखन में हुआ करता था:
function renderFullPage(html, preloadedState) { return ` <!doctype html> <html> <head> <title>Redux Universal Example</title> </head> <body> <div id="root">${html}</div> <script> window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState)} </script> <script src="/static/bundle.js"></script> </body> </html> ` }
और यहाँ GitHub पर मिले सैंपल एप्लिकेशन का एक कोड है:
function htmlTemplate( reactDom, reduxState, helmetData ) { return ` <!DOCTYPE html> <html> <head> <meta charset="utf-8"> ${ helmetData.title.toString( ) } ${ helmetData.meta.toString( ) } <title>React SSR</title> <link rel="stylesheet" type="text/css" href="./styles.css" /> </head> <body> <div id="app">${ reactDom }</div> <script> window.REDUX_DATA = ${ JSON.stringify( reduxState ) } </script> <script src="./app.bundle.js"></script> </body> </html> `; }
कभी-कभी इस भेद्यता को खोजना थोड़ा अधिक कठिन होता है। निम्नलिखित कोड भी असुरक्षित हो जाएगा - यदि
context.data सही
context.data निष्पादित नहीं किया गया है:
const RenderedApp = htmlData.replace('{{SSR}}', markup) .replace('<meta-head/>', headMarkup) .replace('{{data}}', new ArrayBuffer(JSON.stringify(context.data)).toString('base64'))
सर्वर-साइड प्रतिपादन करते समय, ध्यान दें कि वास्तव में क्या प्रस्तुत किया जा रहा है। यदि उपयोगकर्ता प्रवेश करता है तो ठीक से डोम में परिरक्षित और प्रदर्शित नहीं किया जाता है, तो यह खतरनाक हो सकता है।
▍ संरक्षण
इस भेद्यता से बचाने के लिए विकल्पों में से एक
serialize-javascript एनपीएम मॉड्यूल का उपयोग करना है, जिसे आउटपुट JSON को ढालने के लिए डिज़ाइन किया गया है। यदि आप गैर-एनओडी.जेएस वातावरण में सर्वर रेंडरिंग कर रहे हैं, तो आपको अपनी भाषा के लिए उपयुक्त पैकेज चुनने की आवश्यकता होगी।
यहाँ मॉड्यूल स्थापित करने के लिए कमांड है:
$ npm install --save serialize-javascript
उसके बाद, आपको इसे एक फ़ाइल में आयात करना होगा और निम्न संवेदनशील
window साथ काम करने वाले कोड को फिर से लिखना होगा:
<script>window.__STATE__ = ${ serialize( data, { isJSON: true } ) }</script>
यहाँ इस विषय पर
एक महान लेख है।
भेद्यता №2: कपटी लिंक
<a> टैग में
href विशेषता हो सकती है, जिसमें साइट के दूसरे पृष्ठ का लिंक, किसी अन्य साइट का, वर्तमान पृष्ठ पर किसी स्थान का लिंक हो सकता है। लिंक में ऐसी स्क्रिप्ट हो सकती हैं जो कुछ इस तरह दिखती हैं:
javascript: stuff() । यदि आप इस HTML सुविधा के बारे में नहीं जानते हैं, तो अभी निम्न कोड को ब्राउज़र लाइन में कॉपी करके आज़माएँ:
data:text/html, <a href="javascript: alert('hello from javascript!')" >click me</a>
वेब डेवलपर्स के लिए, इसका मतलब है कि यदि लिंक की सामग्री उपयोगकर्ता द्वारा दर्ज किए गए डेटा के आधार पर सेट की जाती है, तो हमलावर
javascript: साथ शुरू होने वाले दुर्भावनापूर्ण कोड को जोड़ सकता है
javascript: इस डेटा के लिए। फिर, यदि उपयोगकर्ता खराब लिंक पर क्लिक करता है, तो ब्राउज़र में एक हमलावर स्क्रिप्ट लॉन्च की जाएगी।
यह भेद्यता निश्चित रूप से केवल रिएक्ट की विशेषता नहीं है, लेकिन यह उन समस्याओं में से एक है जो रिएक्ट डेवलपर्स अक्सर सामना करते हैं जब वे इसी मूल्य की उम्मीद करते हैं कि स्वचालित रूप से सही ढंग से बच गए। यह ध्यान दिया जाना चाहिए कि प्रतिक्रिया के
भविष्य के संस्करण में यह समस्या कम तीव्र होगी।
। कोड समीक्षा के दौरान भेद्यता की पहचान
क्या परियोजना उपयोगकर्ता उन पृष्ठों के लिंक जोड़ सकते हैं जिन पर अन्य उपयोगकर्ता क्लिक कर सकते हैं? यदि ऐसा है, तो निम्नलिखित की तरह पृष्ठ पर एक "लिंक" जोड़ने का प्रयास करें:
javascript: alert("You are vulnerable to XSS!")
यदि संबंधित संदेश बॉक्स लिंक पर क्लिक करके प्रदर्शित किया जाता है, तो इसका मतलब है कि परियोजना XSS हमलों के लिए असुरक्षित है। जहां भी आप लिंक जोड़ सकते हैं, यह कोशिश करें। यह संभावना है कि ऐसी सभी जगहें असुरक्षित नहीं होंगी।
▍ संरक्षण
इस भेद्यता के खिलाफ संरक्षण केवल रिएक्ट परियोजनाओं के लिए उपयुक्त नहीं है। वास्तव में क्या किया जाना चाहिए यह आवेदन पर निर्भर करता है। इसके अलावा, आपको सर्वर पर सुधार करने की आवश्यकता हो सकती है।
आप सोच सकते हैं कि समस्या को हल करने के लिए, यह
javascript: को हटाने के लिए पर्याप्त है
javascript: डेटा से उपसर्ग। यह ब्लैकलिस्ट रणनीति का उपयोग करने का एक उदाहरण है, जिसे
डेटा की सफाई में सफल नहीं माना जा सकता है। हैकर्स के पास ऐसे फिल्टर को बायपास करने के लिए सरल तरीके हैं, इसलिए इस तरह के एक कदम (या इसके अलावा) के बजाय, सुनिश्चित करें कि लिंक एक श्वेतसूचीबद्ध प्रोटोकॉल का उपयोग करते हैं (उदाहरण के लिए,
http: और HTML संस्थाओं से बच सकते हैं।
यहां इस विषय पर
एक विस्तृत लेख है गुणों के परिरक्षण के बारे में जो एक हमलावर को नियंत्रित कर सकता है।
एक और रणनीति जो परियोजना में एक अतिरिक्त स्तर की सुरक्षा जोड़ सकती है, वह है नए ब्राउज़र टैब में कस्टम लिंक खोलने के लिए तंत्र का उपयोग करना। हालांकि, मैं इस रणनीति को परियोजना की एकमात्र "रक्षा की रेखा" के रूप में उपयोग करने की अनुशंसा नहीं करूंगा। ओपनिंग
javascript: एक नए टैब में लिंक पेज तत्वों के गैर-मानक व्यवहार का एक उदाहरण है। अधिकांश ब्राउज़र उपयोगकर्ता को नुकसान पहुँचाए बिना एक खाली टैब में स्क्रिप्ट को चलाएंगे, लेकिन इसकी गारंटी नहीं है, और आप संभवतः इसके चारों ओर प्राप्त कर सकते हैं, जो ब्राउज़र पर निर्भर करता है।
विशेष
UserLink घटक का उपयोग करने पर विचार करें, जो इस तथ्य को जन्म देगा कि असुरक्षित
<a> टैग भविष्य में आपके प्रोजेक्ट के पृष्ठों पर पहुंचने की संभावना कम है। इसके अलावा, यह परियोजना के लिए कुछ परीक्षणों और लाइनिंग नियमों को जोड़ने के लायक है, जिसका उद्देश्य संभावित खतरनाक कोड की पहचान करना और इसे उत्पादन में आने से रोकना है।
लिंक केवल इकाइयाँ नहीं हैं जिनका उपयोग इस तरह से किया जा सकता है। लेकिन वे रिएक्ट अनुप्रयोगों में सबसे संभावित हमले का लक्ष्य हैं। कोई भी तत्व इस हमले के लिए असुरक्षित हो सकता है अगर हमलावर अपने
URI मूल्य को नियंत्रित कर सकता है। इस हमले को अंजाम देने की एक और संभावना, उदाहरण के लिए, एक दृश्य डिजाइन है। उन विशेषताओं की एक पूरी सूची जिसमें URI हो सकते हैं वे ब्राउज़र खोज (
Ctrl+F ) का उपयोग करके कीवर्ड
%URI का उपयोग करके
इस सूची में पाई जा सकती हैं।
कमजोरता # 3: निर्माण के अर्थ को गलत तरीके से समझना गलत है
मैं प्रतिक्रिया के लिए बहुत आभारी हूं कि सुरक्षा चेतावनी सीधे विधि के नाम पर है। यह
dangerouslySetInnerHTML से नाम है
dangerouslySetInnerHTML । इस चेतावनी के बावजूद, हम अभी भी अक्सर इस तथ्य से सामना करते हैं कि डेवलपर्स असुरक्षित संचालन करके जोखिम लेते हैं। इसे ही
eval() कहा जा सकता है।
Google खोज परिणामों के पहले पृष्ठ से साइट पर पाए गए निम्न उदाहरण पर विचार करें:
<script dangerouslySetInnerHTML={{ __html: `window.__PRELOADED_STATE__ = ${JSON.stringify(initialState)};`}}></script>
यह भेद्यता नंबर 1 का एक उदाहरण है, लेकिन एक विशेषता के साथ जो तुरंत इस तथ्य पर ध्यान आकर्षित करना चाहिए कि यहां कुछ गलत है। जहां मुझे यह मिला, यह समझाने का प्रयास किया गया: "हम डेटा को साफ करने और XSS के हमलों को रोकने के तरीके के रूप में
खतरनाक तरीके से InSHTML का उपयोग करते हैं।" खैर, नहीं! यह गलत है। ऐसा न करें।
dangerouslySetInnerHTML बारे में अधिक जानकारी के लिए InSHTML, रिएक्ट प्रलेखन पढ़ें।
एक और उदाहरण जो वास्तव में हर समय होता है, यह है कि एक टीम के सदस्यों ने यह कैसे पता लगाया कि जब वे
dangerouslySetInnerHTML से मार्कडअप मार्क को
dangerouslySetInnerHTML से सेटनरइन का उपयोग कर एक पेज में जोड़ते हैं, तो उनकी
भेद्यता थी। भविष्य में इससे खुद को बचाने के लिए, उन्होंने लाइनिंग के एक विशेष नियम का उपयोग करना शुरू कर दिया।
। कोड समीक्षा के दौरान भेद्यता की पहचान
पुल अनुरोध भेजने या मर्ज संचालन करने से पहले,
dangerouslySetInnerHTML से कोड के लिए कोड को खोजने के लिए उपयोगी है
eval और
eval strings (मैं भी इस तरह से
console.log तलाश करता हूं।) इस तरह के लिंटर नियम का उपयोग करें।
▍ संरक्षण
सुनिश्चित करें कि
dangerouslySetInnerHTML तरीके से उपयोग किए जाने के सभी मामलों में
dangerouslySetInnerHTML विधि, केवल वह डेटा जिस पर आप भरोसा कर सकते हैं, वह पृष्ठ पर लोड है। आपको कैसे पता चलेगा कि डेटा पर भरोसा किया जा सकता है? अगर आपके पास कुछ नहीं आता है, तो यह एक खतरा हो सकता है। इसमें बाहरी API से डाउनलोड किया गया डेटा और मार्कडाउन टूल का उपयोग करके जारी किया गया डेटा शामिल है।
घटक स्पूफिंग नोट
2015 में,
किसी को पता चला कि आप उन घटकों को JSON पास करके घटकों को खराब कर सकते हैं जो पाठ की अपेक्षा करते हैं। मैं एक घटक स्पूफिंग संदेश का केवल एक मामला और इस संदेश के कारण होने वाली
लंबी चर्चा को खोजने में सक्षम था। XSS हमलों को रोकने के लिए प्रतिक्रिया क्या जिम्मेदार है, इस पर ध्यान केंद्रित किया गया। नतीजतन, रिएक्ट डेवलपर्स ने एक
फिक्स जारी किया जो लगता है कि इस भेद्यता को ठीक करने में मदद करता है।
मैंने लेख में इस भेद्यता के बारे में एक कहानी को शामिल नहीं करने का फैसला किया, लेकिन यह विषय आगे के शोध के लिए रुचि का हो सकता है।
एसएसआर नोट
सर्वर का भेद्यता प्रदान करना इस तथ्य के कारण बहुत व्यापक है कि यह Redux प्रलेखन में मौजूद था और परिणामस्वरूप, कई अन्य सामग्रियों में फैल गया। यह समस्या 2016 में तय हुई थी। लेकिन आज भी, तीन वर्षों के बाद, शुरुआती गाइड पूरे इंटरनेट पर बिखरे हुए हैं जो अभी भी सिखाते हैं कि आपको क्या नहीं सिखाना चाहिए।
वैसे, यहां आपका होमवर्क है: गिटहब पर इस समस्या का एक उदाहरण ढूंढें और इसे ठीक करने के लिए एक पुल अनुरोध भेजें।
यहाँ एक उदाहरण है ।
एक साथ हम एक बार और सभी के लिए इस भेद्यता से छुटकारा पा सकते हैं!
प्रिय पाठकों! क्या आपने अपने रिएक्ट प्रोजेक्ट्स पर हमलों का सामना किया है?
