क्लाइंट-साइड कोडिंग: दुर्भावनापूर्ण उपयोग को कैसे रोकें?

Question

पिछले कुछ वर्षों में, क्लाइंट-साइड (ब्राउज़र) अनुप्रयोगों के लिए रुझान वास्तव में दूर हो गया है।

अपने नवीनतम प्रोजेक्ट के लिए, मैंने समय के साथ प्रयास करने और क्लाइंट-साइड एप्लिकेशन लिखने का फैसला किया है।

इस एप्लिकेशन के भाग में उपयोगकर्ताओं को लेनदेन ईमेल भेजना शामिल है (उदाहरण के लिए, साइनअप, पासवर्ड रीसेट ईमेल आदि को मान्य करें)। मैं ईमेल भेजने के लिए एक तृतीय-पक्ष एपीआई का उपयोग कर रहा हूं।

आम तौर पर मैं अपने आवेदन एक सर्वर पर चल रहा होता। मैं अपने सर्वर पर कोड से तीसरे पक्ष के एपीआई को कॉल करूंगा।

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

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

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

मुझे लगता है कि मेरा सामान्य प्रश्न है - हम क्लाइंट-साइड एप्लिकेशन के दुर्भावनापूर्ण उपयोग को कैसे रोक सकते हैं?

Comments

किसी भी कारण से आपके पास यह ऐप आपके स्वयं के सर्वर के साथ संवाद नहीं करता है और फिर आपका सर्वर उन बाहरी सेवाओं के लिए अनुरोध करता है जो आपको उपयोग करने की आवश्यकता है? (इस तरह की कई सेवाएं उन्हें इस तरह से उपयोग करने के लिए निषिद्ध कर

— देंगी

यही कारण है कि एपीआई कुंजी अंततः व्यर्थ हैं। सर्वर को उस एप्लिकेशन पर भरोसा करने की कोशिश नहीं करनी चाहिए जो इसे भेज रही है; यह केवल उपयोगकर्ता पर भरोसा करना चाहिए।

— केविन पैंको

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

— लाएगी

आपको "ब्राउज़र ओनली ऐप्स" की ओर एक धक्का कहाँ दिखाई देता है? मैंने कभी भी ऐसा कुछ नहीं देखा जैसा आप वर्णन कर रहे हैं, ग्राहक कोड में रहस्य को एक बुरी तरह से बुरे विचार में रखते हुए, यहां तक ​​कि सबसे ज्यादा मरने वाले कठिन अंत वाले लोग जो मुझे पता है कि वे कभी नहीं करेंगे।

— व्हीलेयल्स

सुरक्षित संसाधनों के ग्राहक-पक्ष की रक्षा के लिए कोई भी प्रयास बर्बाद किया जाता है क्योंकि यह सुरक्षा के अपरिवर्तनीय कानूनों का उल्लंघन करता है। # 2/3 - यदि आपका सॉफ़्टवेयर आपके विरोधी कंप्यूटर पर चल रहा है, तो यह परिभाषा से आपका कंप्यूटर नहीं है और आप पहले ही खो चुके हैं। # 7 एन्क्रिप्शन द्वारा एक संसाधन की रक्षा करने का प्रयास आपको बर्बाद किया जाता है क्योंकि आपको क्लाइंट को डिक्रिप्शन कुंजी भी प्रदान करनी होती है। # 10 कोई भी तकनीक उपरोक्त को ठीक नहीं कर सकती है। blogs.technet.com/b/rhalbheer/archive/2011/06/16/…

— Dan Neely

Answer 1

आप ऐसा नहीं कर सकते, और अधिक लोग इसे समझते हैं, और वे जितना गहराई से समझते हैं, दुनिया के लिए बेहतर है।

उपयोगकर्ता के नियंत्रण में डिवाइस पर चलने वाला कोड नियंत्रित नहीं किया जा सकता है। स्मार्टफोन को जेलब्रेक किया जा सकता है। सेट-टॉप बॉक्स को क्रैक किया जा सकता है। जावास्क्रिप्ट कोड तक पहुंच को रोकने के लिए साधारण ब्राउज़र भी प्रयास नहीं करते हैं। यदि आपके पास चोरी या गाली देने लायक कुछ है, तो एक निर्धारित हमलावर ऐसा करने में सक्षम होगा , जब तक कि आप सर्वर-साइड के सभी चीजों को मान्य नहीं करते।

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

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

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

Comments

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

— फाल्को

इन दिनों, कंपनियों ने उन लोगों के खिलाफ कानूनी कार्रवाई की धमकी दी है जो प्रसंस्करण से पहले उनसे प्राप्त सामग्री को हैक करते हैं (अर्थात विज्ञापन ब्लॉकर्स के माध्यम से)। यह केवल यह दिखाने के लिए जाता है कि तकनीकी कार्रवाई कितनी असंभव है।

— काइलिन फोथ

यदि मैं पहले दो वाक्यों पर विस्तार से बता सकता हूं, तो सूक्ष्मता वाले लोगों को अक्सर याद आती है कि क्लाइंट-साइड ब्राउज़र ऐप्स का बिंदु भारी उठाने को बंद करना है। आपका सर्वर अभी भी विश्वसनीय संचालन के लिए ज़िम्मेदार है, जैसे ईमेल भेजना या डेटा एक्सेस करना। ग्राहक के पास उस डेटा से एक ग्राफ़ प्रस्तुत करना, हालाँकि, सुरक्षा मॉडल को बदले बिना आपको CPU समय (और पैसा) बचाता है।

— ssube

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

— अजेदी

@ Ajedi32 क्लाइंट-साइड क्षुधा हैं असुरक्षित। अगर किसी भी क्लाइंट द्वारा किया गया सर्वर-साइड चेक नहीं किया जाता है, तो सुरक्षित ऐप डिजाइन करना असंभव है। उस बिंदु पर क्लाइंट-साइड लॉजिक एक यूआई नेक्स्ट या बेसिक चेक को ऑफलोड करने का एक तरीका बन जाता है, लेकिन सब कुछ, सर्वर पर हमेशा चेक किया जाना चाहिए !! ।

Answer 2

यहाँ नियम है:

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

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

Answer 3

यह वास्तव में ऐसा मामला है जहां इसे पूरी तरह से क्लाइंट-साइड एप्लिकेशन बनाना उचित नहीं है।

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

Comments

नोट: जबकि यह क्लाइंट पक्ष को मान्य करने के लिए बहुत अच्छा है, कभी भी उन्हें सर्वर साइड को मान्य करने के लिए मत भूलना! जब तक आप अपने क्लाइंट कोड को ब्राउज़र में भेजते हैं, तब तक यह आपका कोड होना बंद हो जाता है! आपको फिर से भेजने वाले हर एक बिट को मान्य करना होगा!

— जोसेफ

Answer 4

आपका मध्य पैराग्राफ समस्या का दिल है:

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

क्‍लाइंट साइड ऐप का अर्थ यह नहीं है कि आपके पास सर्वर-साइड काम नहीं हो सकता है? क्लाइंट-साइड प्रोग्रामिंग के लिए धक्का सर्वर को खत्म करने के बारे में नहीं है, लेकिन नई प्रौद्योगिकियों का लाभ उठाते हैं जो ब्राउज़र अंततः बेहतर उपयोगकर्ता इंटरफेस बनाने के लिए समर्थन करते हैं।

.jsआपके द्वारा प्राप्त फ़ाइल के लिए , क्या आप सुनिश्चित हैं कि यह ब्राउज़र के लिए है? यह एक नोड। पुस्तकालय हो सकता है?

Comments

+1 वास्तव में अच्छे सुझाव के लिए कि JS फाइल NodeJS सर्वर के लिए अभिप्रेत है

— Machinarius

Answer 5

आइए इससे पीछे हटें और एक उच्च स्तरीय नज़र डालें .. क्या हम .. यूडोरा या आउटलुक (एक क्लाइंट साइड ऐप, जिसे ब्राउज़र की आवश्यकता भी नहीं है) कभी किसी कंपनी के लिए वित्तीय नुकसान का कारण बना? नहीं, कोई भी व्यक्ति POP / SMTP API को लिख सकता है और ग्राहक हो सकता है। लेकिन सर्वर को कोई नुकसान नहीं हुआ। सर्वर ने क्लाइंट एक्शन, कंप्यूटेशन, स्टोरेज, टेम्परेचर, डिस्क साइज़, रैम साइज़, मॉनिटर डीपीआई, जीपीयू, क्लाइंट के एफपीयू याडा यादा को सीमित नहीं किया, लेकिन वास्तव में यह निर्दिष्ट करता है कि यह और क्या जवाब देगा। क्या आपने कभी बैंक को तोड़ने के लिए उपयोग किए जाने वाले एमएसएन-मनी के बारे में सुना है?

आपका ब्राउज़र (यानी क्लाइंट साइड) ऐप उसी आर्किटेक्चर का उपयोग कर सकता है।

1. आप अपने सर्वर को एक एपीआई (जो कि BTW, हमेशा GET POST HEAD आदि के डेरिवेटिव के लिए उबलते हैं) के साथ बनाते हैं।
2. सर्वर पर, सुनिश्चित करें कि एपीआई केवल एक प्रमाणित और पहचान सत्यापित ग्राहक के साथ प्रत्येक और हर कॉल के लिए बात करता है।
3. फिर आपको परवाह नहीं है कि ग्राहक कौन है।
4. और फिर आप परवाह नहीं करते हैं कि यह एक ब्राउज़र, जेलब्रेक डिवाइस, Google ग्लास, डॉस 3.1 या एक तकनीकी नवप्रवर्तन महान-महान-महान-दादा के हाथों में एक नया नेक्सस है जो 2014 में यात्रा कर चुका है और सभी को याद किया है वह तकनीक जो पिछले 15 दशकों में हमारे जीवन को भर रही है।
5. अब आप क्लाइंट की तरफ से सब कुछ बंद कर सकते हैं।

SoapBoxBegin

@KilianFoth भोले और लापरवाह लोगों के लिए एक महत्वपूर्ण जागरूकता बिंदु उठाता है, मुख्य रूप से वे जो हर समय सुर्खियां पढ़ते हैं, लेकिन कभी नहीं सोचते कि यह उनके ऐप, उनके कोड, उनके नियोक्ता, उनके क्लाइंट, उनके स्वयं के बैंक खाते में होगा। इससे भी अधिक लापरवाह उनके नियोक्ता हैं (विशेषकर सीटीओ के) जो उन ऐप्स को बाहर निकालने की अनुमति देते हैं जो किसी भी सिस्टम को अप्रबंधित / अनियंत्रित प्रदर्शन से बाहर निकालते हैं। हालांकि मैं हमेशा इस बात पर हैरान हूं कि ऐसा लगता है कि "हम कभी नहीं सीखते हैं"।

SoapBoxEnd

इसलिए संक्षेप में। एक ठोस और तंग सर्वर साइड API बनाएं। ग्राहक जो कुछ भी संभाल सकता है, उसके आधार पर ग्राहक को बाकी सब कुछ लोड करें।

Answer 6

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

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

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

Answer 7

यह वास्तव में काफी सरल है। मान लें कि क्लाइंट कंप्यूटर और उस पर चलने वाले सभी सॉफ़्टवेयर एक चतुर दुर्भावनापूर्ण हैकर के पूर्ण नियंत्रण में हैं।

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

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

बेशक, कार्यान्वयन एक समस्या है, लेकिन महत्वपूर्ण बात यह है कि मानसिक दृष्टिकोण, यह धारणा कि "क्लाइंट" आपको लगता है कि आपका सर्वर एक ग्राहक नहीं बल्कि एक सक्रिय हमलावर है।

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

Answer 8

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

आम तौर पर मैं अपने आवेदन एक सर्वर पर चल रहा होता। मैं अपने सर्वर पर कोड से तीसरे पक्ष के एपीआई को कॉल करूंगा।

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

यदि आपके पास एपीआई कुंजी है, तो यह ग्राहक की ओर से काम करने का इरादा नहीं है। यदि आप क्लाइंट की ओर से एपीआई कुंजी देते हैं, तो किसी के पास इसकी पहुंच है, और फिर इसे स्वयं के उद्देश्य के लिए उपयोग कर सकते हैं। इसे स्टोर करके सर्वर-साइड का उपयोग करें जब क्लाइंट को इसकी आवश्यकता हो, तो Ajax / WebSockets का उपयोग करके परिणाम भेजें।

यह ऐसा है जैसे कि आपका बैंक कह रहा था: "ठीक है, मैं मुख्य डेटाबेस क्लाइंट साइड का पासवर्ड डालने जा रहा हूं ताकि क्लाइंट खुद से इसका अनुरोध कर सके और वह हमारे सर्वर को अब और परेशान नहीं करेगा।"