क्लाइंट एप्लीकेशन सिक्योरिटी: फ्रंट-एंड डेवलपर के लिए प्रैक्टिकल टिप्स

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

अपने प्रोजेक्ट के उदाहरण पर, मैं इस बारे में बात करूंगा कि आज क्लाइंट एप्लिकेशन किस तरह से हमला कर रहे हैं और आप इन खतरों से कैसे बच सकते हैं।

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

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

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

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

Git

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

लेकिन अगर आपके पास ऐसा कोई भंडारण नहीं है तो क्या होगा? आप फ़ाइलों को उन रहस्यों के साथ एन्कोड और छिपाने के लिए टूल का उपयोग कर सकते हैं जो संस्करण नियंत्रण प्रणालियों की क्षमताओं का विस्तार करेंगे।

पहली बात जो दिमाग में आती है वह है यूनिवर्सल ब्लैकबॉक्स समाधान। इसका उपयोग किसी भी संस्करण नियंत्रण प्रणाली के साथ किया जा सकता है, उदाहरण के लिए, मर्क्यूरियल, गिट आदि। इसके अलावा, Git के दो एक्सटेंशन हैं: git-crypt और git-secret। मैं दूसरे का उपयोग करने की सलाह देता हूं, क्योंकि यह मुझे आधिकारिक दस्तावेज में वर्णन के संदर्भ में उपयोग करने के लिए सबसे अधिक सुविधाजनक और अधिक समझ में आता था। गिट-सीक्रेट स्थापित करने के बाद, आपको इसे गिट रिपॉजिटरी में इनिशियलाइज़ करना होगा। .Gitattributes फ़ाइल में उपयोग करने के लिए एक्सटेंशन निर्दिष्ट करना याद रखें। अगला, रहस्यों की पहुंच को कॉन्फ़िगर करें: उन उपयोगकर्ताओं की पहचान करें जिन्हें आप संवेदनशील डेटा तक पहुंच प्रदान करना चाहते हैं। फिर संवेदनशील डेटा के साथ फाइलें जोड़ें और उन्हें git-secret-hide । आप git-secret-reveal. माध्यम से छिपी हुई फ़ाइलें प्राप्त कर सकते हैं git-secret-reveal.

Webpack

खतरों को खत्म करने का एक और तरीका है वेबपैक को सही तरीके से कॉन्फ़िगर करना। XSS, XEE और इसी तरह के हमलों से बचाने के लिए, आपको CORS (क्रॉस-ऑरिजनल रिसोर्स शेयरिंग) और CSP (कंटेंट सिक्योरिटी पॉलिसी) नीतियों का पालन करने पर विचार करना होगा। दोनों मामलों में, प्रोजेक्ट में उपयोग की जाने वाली कुछ स्क्रिप्ट की प्रामाणिकता की जांच करने के लिए हेडर का पालन करना महत्वपूर्ण है। ब्राउज़रों के पास किसी विशेष स्रोत की विश्वसनीयता की जांच करने के लिए तंत्र हैं, उदाहरण के लिए, अगर कॉर्स और सीएसपी गलत तरीके से कॉन्फ़िगर किए गए हैं, तो सफारी हर कदम पर चेतावनी जारी करेगा।

कॉर्स और सीएसपी के अनुपालन के दो तरीके हैं। पहला बैक एंड में प्रतिक्रिया हेडर कॉन्फ़िगर करना है। दूसरा मेटा टैग और विशेषताओं के माध्यम से दोनों नीतियों को पंजीकृत करना है। उत्तरार्द्ध विधि की सिफारिश की जाती है यदि आपके पास आलसी बैक-एंड डेवलपर्स हैं, तो वे हमेशा व्यस्त रहते हैं और वे सुरक्षा नीतियों में रुचि नहीं रखते हैं। एप्लिकेशन बनाते समय मेटा टैग को तुरंत पंजीकृत किया जा सकता है। Html-webpack-plugin, html-webpack-बाहर-एसेट्स-plugin, script-ext-html-webpack-plugin, csp-html-webpack-plugin और crypto जैसे प्लगइन्स इसमें हमारी मदद करेंगे। इसके अलावा, यदि आपके पास आपकी परियोजना में तृतीय-पक्ष संसाधन हैं (उदाहरण के लिए, CSS में उपयोग किए गए बाहरी फोंट के लिए लिंक; सीडीएन से लोड किए गए संसाधन और इसी तरह), तो मैं वेबपैक-सब-सोर्स-अखंडता-प्लगइन का उपयोग करने की सलाह देता हूं। इस प्रकार, आप ब्राउज़र को सूचित करेंगे कि स्क्रिप्ट में लोड किए गए संसाधन विश्वसनीय हैं, उनमें कोई इंजेक्शन नहीं है, वे पूरे और अनपेक्षित हैं। और यहां तक ​​कि अगर किसी ने संसाधन में दुर्भावनापूर्ण डेटा इंजेक्ट किया है, और आपने इसे अपलोड किया है, तो आपको इसके लिए तैयार रहना चाहिए और अपने प्रोजेक्ट को इस तरह के खतरों से बचाना चाहिए।

मैं उस क्रम पर विशेष ध्यान देना चाहता हूं जिसमें प्लगइन्स के लिए क्लास इंस्टेंसेस बनाए जाते हैं। आदेश इस तरह होना चाहिए:

 const SHA256 = (str) => CRYPTO.createHash('sha256').update( str, 'utf8').digest('base64'); const sha256Str = SHA256( '' + Date.now() ); […] new HtmlWebpackPlugin({   filename: 'index.html',   template: 'public/index.html' }), new ScriptExtHtmlWebpackPlugin({    custom: [{           test: /\.js$/,           attribute: 'nonce',           value: 'nonce-' + sha256Str    }] }), new HtmlWebpackExcludeAssetsPlugin(), new CspHtmlWebpackPlugin({    'base-uri': '\'self\'',    'object-src': '\'none\'',    'script-src': ['\'self\'', '\'unsafe-eval\'', '\'nonce-' + sha256Str + '\''],    'style-src': ['\'unsafe-inline\'', '\'self\''] }, {    devAllowUnsafe: false,    enabled: true,    hashingMethod: 'sha256' }), new SriPlugin({    hashFuncNames: ['sha256', 'sha384'],    enabled: true }), […] 

फिर, असेंबली के दौरान <hed> http-equiv=content-security-policy मेटा टैग प्रदर्शित करेगा। निर्देश content में लिखे जाएंगे, जो कहते हैं कि किन लिपियों और संसाधनों पर भरोसा किया जा सकता है।

base-uri यूआरएल निर्देश दिखाता है कि स्क्रिप्ट, सीएसएस, चित्र और अधिक को लोड करने के लिए किस आधार URL का उपयोग किया जाता है।

ऑब्जेक्ट आमतौर पर लोड नहीं करते हैं, इसलिए object-sr सी निर्देश के लिए none सेट none करता है।

script-src निर्देश JS स्क्रिप्ट पर लागू होता है।

प्रत्येक बार nnce-<hshVlue> प्रकार की विशेषता दर्ज करना न भूलें। इसके अलावा, हैश की गणना SHA256 या SHA512 एल्गोरिथ्म का उपयोग करके की जानी चाहिए।

style-src निर्देश के लिए, हमारी परियोजना की ख़ासियत है: हम प्रत्येक घटक के लिए CSS लिखने और उन्हें एक-दूसरे से अलग करने के लिए स्टाइल-घटकों का उपयोग करते हैं। और इसलिए यह निर्दिष्ट करना आवश्यक है कि हम style-src unsafe-inline और self का उपयोग style-src में किया जाता है, अन्यथा स्टाइल-घटक बंद हो जाएंगे।

script टैग स्वचालित रूप से nnce-<hshVlue> , integrity और cross-origin सेट हो जाएगा। वे ब्राउज़र को बताते हैं कि विश्वसनीय स्रोतों से संसाधन खींचे जा रहे हैं। अन्यथा, यदि ब्राउज़र देखता है कि संसाधन CSP या CORS से मेल नहीं खाता है, तो यह बस इस स्क्रिप्ट या CSS फ़ाइल को लोड नहीं करता है, और यह कंसोल में कुछ लिखेगा जैसे: "इस स्क्रिप्ट पर ध्यान दें, इस लाइन पर जहाँ आप इनिशियलाइज़ करते हैं यह। देखो, तुम्हें कुछ गड़बड़ है! ” ।

MDN , OWASP और W3C प्रलेखन CSP और CORS नीतियों को लागू करने के लिए दिशानिर्देश प्रदान करता है। इसके अलावा, कोई भी पैठ परीक्षण उपकरण परियोजना में कोर और सीएसपी नियमों के अनुपालन की रिपोर्ट करेगा। कोई भी ढांचा या उपकरण जो किसी परियोजना का स्वत: परीक्षण करेगा, खामियों को इंगित करेगा।

उपयोगकर्ता प्रमाणीकरण

हम OpenID कनेक्ट और कर्बरोस प्रोटोकॉल का उपयोग करते हैं। बाहरी उपयोगकर्ताओं को प्रमाणित करने के लिए एक काफी सामान्य OpenID मानक का उपयोग किया जाता है।

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

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

प्रमाणीकरण को पासपोर्ट, जेएस और एक्सप्रेस-सत्र पैकेजों के साथ-साथ प्रामाणिक एसडीके का उपयोग करके आधुनिक अनुप्रयोगों में लागू किया जा सकता है।

यदि आप OpenID Connect या किसी अन्य प्रोटोकॉल के माध्यम से प्रमाणीकरण सेवा विकसित करने में असमर्थ हैं, तो एक प्रॉक्सी लेयर का उपयोग करें, जैसे कि Auth0 और इसी तरह, ताकि प्रमाणीकरण एक तृतीय-पक्ष कंपनी के माध्यम से हो जो उपयोगकर्ताओं को इंटरनेट संसाधनों तक सुरक्षित पहुँच प्रदान करने में माहिर हो।

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

पासवर्ड हैशिंग

OWASP वेबसाइट अनुशंसा करती है कि आप डेटाबेस में निर्मित पासवर्ड हैशिंग सिस्टम का उपयोग न करें। इसके लिए, Argon2, PBKDF2, ccrypt और bcrypt जैसे पैकेज का उपयोग करना बेहतर है। मेरे अभ्यास में, मैं आर्गन 2 का उपयोग करता हूं - यह जीसीसी, पीजीपी / जीपीजी एल्गोरिदम, आदि के लिए एक आवरण है, लेकिन इसके लिए आपको पहले जीसीसी पैकेज स्थापित करना होगा। आर्गन 2 उपयोग योजना:

 1.  GCC >= 4.8 install $ brew install gcc 

 2.     - $ npm install -g node-gyp 

 3.   Argon2 $ npm install argon2 

 4.   import * as ARGON from 'argon2'; ARGON.generateSalt().then( (salt: string) => {  ARGON.hash('some-user-password', salt)    .then((hash : string) => {       console.log('Successfully created Argon2 hash:', hash);       // TODO: store the hash in the user database  }); }); argon2.verify( 'previously-created-argon-hash-here', 'some-user-password').then(() => {  console.log('Successful password supplied!');  // TODO: log the user in }).catch(() => {  console.log('Invalid password supplied!'); }); , यहाँ', 4.   import * as ARGON from 'argon2'; ARGON.generateSalt().then( (salt: string) => {  ARGON.hash('some-user-password', salt)    .then((hash : string) => {       console.log('Successfully created Argon2 hash:', hash);       // TODO: store the hash in the user database  }); }); argon2.verify( 'previously-created-argon-hash-here', 'some-user-password').then(() => {  console.log('Successful password supplied!');  // TODO: log the user in }).catch(() => {  console.log('Invalid password supplied!'); }); 

कहानियो

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

हैकर्स मुसीबत में नहीं पड़ते। सबसे पहले, वे संसाधन की खोज का संचालन करते हैं, कमजोरियों और हमले के वेक्टर का निर्धारण करते हैं। उदाहरण के लिए, वे डेटा को हेरफेर करते हैं या परिवहन प्रोटोकॉल में निहित कमजोरियों का फायदा उठाते हैं। हमले के वेक्टर को किसी विशेष ऑपरेटिंग सिस्टम की कमजोरियों के लिए लक्षित किया जा सकता है; किसी भी UNIX सिस्टम में उनमें से बहुत सारे हैं। लेकिन कमजोरियों का उपयोग केवल तभी किया जा सकता है जब व्यवस्थापक ने सुरक्षा नीतियों को खराब तरीके से कॉन्फ़िगर किया हो, उदाहरण के लिए, गलत तरीके से सेट किए गए URL जो बाहर जाते हैं।

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

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

धमकी लॉगिंग और निगरानी

पहले से ज्ञात कमजोरियों के साथ संकुल के उपयोग के रूप में इस तरह का खतरा है। Npm ऑडिट, Snyk और LGTM जैसे खतरे का विश्लेषण करने वाले ऐसे हालात में मदद करेंगे। एनपीएम ऑडिट एक मानक उपयोगिता है जिसे एनपीएम में बनाया गया है, लेकिन आपको लगातार इस कमांड को कॉल करना होगा या बैसाखी के साथ आना होगा। इसलिए, मैं आपको Snyk का उपयोग करने की सलाह देता हूं। इस परियोजना का अपना डेटाबेस कमजोरियों के साथ है। जब आप परीक्षण शुरू करते हैं, तो Snyk इस डेटाबेस को एक्सेस करता है और गोपनीय रूप से आपके Snyk प्रोजेक्ट को रिपोर्ट अपलोड करता है, जो बाहरी लोगों के लिए सुलभ नहीं है। सच है, आप अपने प्रोजेक्ट को केवल 300 बार मुफ्त में जांच सकते हैं, और जब आप प्रत्येक प्री-कमेटी की जांच करते हैं, तो ये 300 मुफ्त प्रयास बहुत जल्दी समाप्त हो जाते हैं। इसलिए, प्री-पुश या प्री-मर्ज हुक के लिए परीक्षण चलाना बेहतर है।

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

मैं परियोजना के बहुत शुरुआत से Snyk पैकेज का उपयोग करने की सलाह देता हूं, और कंसोल से स्कैन शुरू करता हूं। यहां सब कुछ सरल है: स्थापना के बाद, खाते के लिए लॉगिन और पासवर्ड सेट करें, और परीक्षण स्वयं इस तरह से किया जा सकता है:

• Npm i snyk —D निर्भरता स्थापित करने और "snyk" निर्दिष्ट करने के बाद: package.json में सही, चलाएँ:

 ./node_modules/.bin/snyk wizard --dev 

• Package.json में स्क्रिप्ट और सेटिंग्स जोड़ें:

 { ... "scripts": {  ...  "test": "npm run test:snyk && npm run test:jest",  ...  "test:snyk": "snyk test --dev",  ...  "prepare": "npm run prepare:snyk",  "prepare:snyk": "snyk protect" }, "husky": {  "hooks": {   "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",   "pre-commit": "npm run test:snyk && npm run lint && npm run test:jest",   "pre-push": [    "npm run test:snyk",    "npm run lint",    "npm run test:jest",    "npm run build:production"   ],   ...  } }, "snyk": true } 

ऊपर, हमने सुरक्षा खतरों के लिए एक स्थानीय जांच को देखा। ज्ञात खतरों के लिए पैकेजों की जांच करने के लिए, मैं एलजीटीएम का उपयोग करने की भी सलाह देता हूं। इस प्रोजेक्ट का उपयोग GitHub या Bitbucket के संयोजन के साथ करें (जब तक कि आपने इसे आज़माया नहीं, यह आवश्यक नहीं था), और कोड को हर पुश के साथ तुरंत चेक किया जाएगा।

आवेदन की निगरानी

फ्रंट-एंड के क्षेत्र में, उपकरण पहले से ही अच्छी तरह से स्थापित हैं, हर स्वाद के लिए उपकरण क्लाइंट भाग में प्रवेश और निगरानी के लिए उपलब्ध हैं। सबसे प्रसिद्ध संतरी, TrackJS और InsightOps हैं। संतरी सर्वर को उसके भौतिक सर्वर पर तैनात किया जा सकता है। उदाहरण के लिए, हमारी दो परियोजनाओं में हमने एक अलग सर्वर का उपयोग किया, जो अनुप्रयोगों के संचालन को लॉग करने के लिए पूरी तरह से कॉन्फ़िगर किया गया था। हम URL पर गए और वहां के सभी लॉग हटा दिए। यदि अनुप्रयोग में कोई त्रुटि उत्पन्न होती है, तो इसे एक कोशिश कैच ब्लॉक में लपेटा जाता है और रावेन पैकेज विधियों के माध्यम से सेंट्री सर्वर पर भेजा जाता है। सब कुछ सरल और सुविधाजनक है। यदि आप संतरी में अस्पष्ट URL देखते हैं जो आपने रजिस्टर नहीं किया है, यदि आप एम्बेडिंग या अस्पष्ट संदेश देखते हैं, तो वे आपको हैक करने का प्रयास कर रहे हैं। मेरे व्यवहार में, यह नियमित रूप से हुआ। उदाहरण के लिए, परियोजनाओं में से एक - विज्ञापन ब्लॉकर्स और एंटीवायरस को बायपास करने के लिए एक सेवा - लगातार इसका मुकाबला करने, दरार करने की कोशिश कर रही थी।

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

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

निगरानी करने का सबसे अच्छा तरीका क्या है? कुछ छोटे URL लें, GET पैरामीटर लिखें और इस URL पर GET अनुरोध भेजें। सर्वर साइड में, इस URL को प्रोसेस करें, डेटाबेस में लॉग को लिखें और ग्राफाना को मॉनिटरिंग बढ़ाएँ। सब कुछ सरल है।

वह सब है। भविष्य में मैं वेब एप्लिकेशन को खतरों से बचाने के विषय पर लिखना जारी रखने की कोशिश करूंगा। हर कोई जो अंत तक पढ़ा है - मैं आपकी परियोजनाओं के लिए सुरक्षा चाहता हूं)))

विषय पर पढ़ने के लिए स्रोतों की सूची:

www.owasp.org/index.php/Main_Page

tproger.ru/translations/webapp-security

एस हॉक्स। यहां तक ​​कि तेज़ सिंगल पेज एप्लीकेशन: सुरक्षा

सीकॉर्ड, रॉबर्ट सी। सीईआरटी सी सुरक्षित कोडिंग मानक / रॉबर्ट सी। सीकॉर्ड। - 2008

चेतन करंडे। सिक्योरिटी नोड एप्लिकेशन - 2017

स्टीवन पामर। वेब एप्लिकेशन कमजोरियों का पता लगाने, शोषण, रोकथाम - 2011

रॉबर्ट शिमोंस्की, सीन-फिलिप ओरीआनो। क्लाइंट-साइड हमलों और रक्षा - 2012

मार्कस पिंटो, डैफिड स्टुटर्ड। वेब एप्लीकेशन हैकर की हैंडबुक: फाइंडिंग एंड एक्सप्लॉइटिंग सिक्योरिटी फ्लैव्स, 2 डी संस्करण - 2011

कार्ल दूना। आपका Node.js वेब अनुप्रयोग - 2015 सुरक्षित करें