यदि मैं केवल उपयोगकर्ता नाम / पासवर्ड आधारित प्रमाणीकरण का उपयोग करता हूं तो वे पर्याप्त सुरक्षित नहीं होंगे?
नहीं, क्योंकि आप केवल WHO की पहचान API सर्वर तक कर रहे हैं , लेकिन WHAT इसे एक्सेस नहीं कर रहा है।
WHO और WHAT के बीच का अंतर API सर्वर तक पहुंच रहा है
WHO और WHAT के बीच के अंतर को बेहतर तरीके से समझने के लिए एक एपीआई सर्वर का उपयोग किया जाता है, आइए इस चित्र का उपयोग करें:
इरादा संचार चैनल किसी भी दुर्भावनापूर्ण इरादे के बिना एक वैध उपयोगकर्ता द्वारा, मोबाइल एप्लिकेशन के एक अपरिचित संस्करण का उपयोग करके, और बीच में हमला किए बिना एपीआई सर्वर के साथ सीधे संवाद करने के लिए, आपके द्वारा अपेक्षित रूप से उपयोग किए जा रहे मोबाइल ऐप का प्रतिनिधित्व करता है।
वास्तविक चैनल कई अलग-अलग परिदृश्यों का प्रतिनिधित्व कर सकता है, जैसे दुर्भावनापूर्ण इरादों वाला एक वैध उपयोगकर्ता, जो मोबाइल ऐप के रीपैकेज किए गए संस्करण का उपयोग कर सकता है, एक हैकर मोबाइल ऐप के वास्तविक संस्करण का उपयोग कर सकता है, जबकि बीच में आदमी उस पर हमला करता है, यह समझने के लिए कि कैसे आपके एपीआई के खिलाफ हमलों को स्वचालित करने में सक्षम होने के लिए मोबाइल ऐप और एपीआई सर्वर के बीच संचार किया जा रहा है। कई अन्य परिदृश्य संभव हैं, लेकिन हम यहां हर एक की गणना नहीं करेंगे।
मुझे आशा है कि अब तक आप पहले से ही एक सुराग हो सकता है क्यों डब्ल्यूएचओ और क्या ही नहीं हैं, लेकिन यदि नहीं यह एक पल में स्पष्ट हो जाएगा।
डब्ल्यूएचओ मोबाइल एप्लिकेशन है कि हम, प्रमाणित अधिकृत करते हैं और जगह OpenID Connect या OAUTH2 बहती है का उपयोग कर की तरह कई मायनों में पहचान, कर सकते हैं के उपयोगकर्ता है।
OAuth
आम तौर पर, OAuth ग्राहकों को एक संसाधन स्वामी की ओर से सर्वर संसाधनों के लिए "सुरक्षित प्रत्यायोजित पहुंच" प्रदान करता है। यह संसाधन मालिकों के लिए उनके क्रेडेंशियल साझा किए बिना उनके सर्वर संसाधनों तक तीसरे पक्ष की पहुंच को अधिकृत करने के लिए एक प्रक्रिया को निर्दिष्ट करता है। हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) के साथ काम करने के लिए विशेष रूप से डिज़ाइन किया गया, OAuth अनिवार्य रूप से संसाधन स्वामी की स्वीकृति के साथ, एक प्राधिकरण सर्वर द्वारा तीसरे पक्ष के क्लाइंट को टोकन जारी करने की अनुमति देता है। तृतीय पक्ष तब संसाधन सर्वर द्वारा होस्ट किए गए संरक्षित संसाधनों तक पहुंचने के लिए एक्सेस टोकन का उपयोग करता है।
ओपेनआईडी कनेक्ट
OpenID कनेक्ट 1.0 OAuth 2.0 प्रोटोकॉल के शीर्ष पर एक साधारण पहचान परत है। यह ग्राहकों को एक प्राधिकरण सर्वर द्वारा किए गए प्रमाणीकरण के आधार पर एंड-यूज़र की पहचान को सत्यापित करने की अनुमति देता है, साथ ही अंतः-उपयोगकर्ता के बारे में एक इंटरऑपरेबल और रीस्ट-जैसे तरीके से बुनियादी प्रोफ़ाइल जानकारी प्राप्त करने के लिए।
उपयोगकर्ता प्रमाणीकरण API सर्वर बता सकता है जबकि डब्ल्यूएचओ एपीआई का उपयोग कर रहा है, यह गारंटी नहीं दे सकता कि अनुरोध उत्पन्न किया है से क्या आप उम्मीद, मोबाइल एप्लिकेशन के मूल संस्करण।
अब हमें WHAT सर्वर को कॉल करने के तरीके की पहचान करने की आवश्यकता है , और यहां चीजें ज्यादातर डेवलपर्स की तुलना में अधिक मुश्किल हो सकती हैं। क्या API सर्वर के लिए अनुरोध करने वाले बात है। क्या यह वास्तव में मोबाइल ऐप का एक वास्तविक उदाहरण है, या पोस्टमैन जैसे उपकरण का उपयोग करके एपीआई सर्वर के साथ मैन्युअल रूप से प्रहार करते हुए एक बॉट, एक स्वचालित स्क्रिप्ट या हमलावर है?
आपके आश्चर्य के लिए आपको पता चल सकता है कि यह मोबाइल ऐप या एक स्वचालित स्क्रिप्ट का उपयोग करने वाले कानूनी उपयोगकर्ताओं में से एक हो सकता है जो एप्लिकेशन द्वारा प्रदान की गई सेवा का लाभ उठाने और लाभ उठाने की कोशिश कर रहा है।
खैर, WHAT की पहचान करने के लिए , डेवलपर्स एक एपीआई कुंजी का सहारा लेते हैं जो आमतौर पर उनके मोबाइल ऐप के कोड में हार्ड-कोड होता है। कुछ डेवलपर्स अतिरिक्त मील जाते हैं और मोबाइल ऐप में रन-टाइम पर कुंजी की गणना करते हैं, इस प्रकार यह एक रनटाइम रहस्य बन जाता है क्योंकि पूर्व दृष्टिकोण के विपरीत जब कोड में एक स्थिर रहस्य एम्बेडेड होता है।
उपरोक्त लेख को मैंने अपने लिखे एक लेख से निकाला था, जिसका शीर्षक आपका मोबाइल एप्लिकेशन एनई एपीआई कुंजी है? , और यह कि आप यहां पूरा पढ़ सकते हैं , यह एपीआई कुंजी के बारे में लेखों की एक श्रृंखला में पहला लेख है।
क्लाइंट डिवाइस में सेंसिटिव डेटा स्टोर करना
और मैं निश्चित रूप से सुरक्षा कारणों से डिवाइस में उस उपयोगकर्ता नाम / पासवर्ड को नहीं बचा सकता हूं? क्या मुझे साइन-अप में प्रत्येक उपयोगकर्ता के लिए एक GUID जारी करना चाहिए, इसे उनके डिवाइस में सहेजना चाहिए और हर बार एपीआई अनुरोध के दौरान पुनर्प्राप्त करना चाहिए?
डिवाइस में जो कुछ भी आप सहेजते हैं, भले ही एन्क्रिप्ट किया गया हो, फ्रिडा या एक्सपोज्ड जैसे टूल के साथ रन-टाइम के दौरान रिवर्स इंजीनियर हो सकता है।
फ्रीडा
ब्लैक बॉक्स प्रक्रियाओं में अपनी खुद की स्क्रिप्ट इंजेक्ट करें। किसी भी फ़ंक्शन को हुक करें, क्रिप्टो एपीआई पर जासूसी करें या निजी एप्लिकेशन कोड का पता लगाएं, किसी स्रोत कोड की आवश्यकता नहीं है। संपादित करें, हिट सहेजें, और तुरंत परिणाम देखें। सभी संकलन चरणों या कार्यक्रम पुनरारंभ के बिना।
Xposed
Xposed मॉड्यूल का एक ढांचा है जो बिना किसी APK को छुए सिस्टम और ऐप के व्यवहार को बदल सकता है। यह बहुत अच्छा है क्योंकि इसका मतलब है कि मॉड्यूल विभिन्न संस्करणों और यहां तक कि रोम के बिना किसी भी परिवर्तन (मूल कोड के रूप में लंबे समय तक काम कर सकते हैं
एक डिवाइस में हमलावर नियंत्रण वह भी किसी भी रहस्य को निकालने के लिए मध्य हमला में एक आदमी को करने के लिए एक प्रॉक्सी का उपयोग कर सकते हैं की पहचान करने का उपयोग कर सकते क्या या डब्ल्यूएचओ के रूप में मैं लेख में दिखाने चोरी एक आदमी के साथ कि API कुंजी हमला में :
जबकि हम मोबाइल ऐप कोड में एपीआई कुंजी को छिपाने के लिए जेएनआई / एनडीके जैसी उन्नत तकनीकों का उपयोग कर सकते हैं, यह एपीआई कुंजी चोरी करने के लिए किसी को मित्म हमले करने से रोक नहीं पाएगा। वास्तव में एक मीतम हमला इस बिंदु पर आसान है कि यह गैर डेवलपर्स द्वारा भी प्राप्त किया जा सकता है।
तो अब क्या ... क्या मैं उस बिंदु पर डूबा हूं जो मैं अपने एपीआई सर्वर को दुरुपयोग नहीं कर सकता हूं ??? कोई शांत तो नहीं ... उम्मीद अभी भी मौजूद है !!!
संभव समाधान
क्या कोई मुझे बता सकता है कि फेसबुक, फोरस्क्वेयर, या ट्विटर जैसे प्रसिद्ध एंड्रॉइड एप्लिकेशन अपने मोबाइल एप्लिकेशन से अपने सर्वर पर आने वाले प्रत्येक अनुरोध को प्रमाणित करने के लिए क्या उपयोग करते हैं?
क्षमा करें, लेकिन मेरे पास इस ऐप पर इतना ज्ञान नहीं है कि मैं आपको समझा सकूँ, लेकिन मैं आपको कुछ अन्य दृष्टिकोणों की ओर संकेत कर सकता हूँ।
अन्य कौन से पैटर्न उपलब्ध हैं और जो सबसे अधिक कुशल और सुरक्षित हैं, मुझे बस इसके लिए एक प्रक्रिया प्रवाह की आवश्यकता है।
तो कुछ भी जो क्लाइंट की तरफ से चलता है और एक एपीआई को एक्सेस करने के लिए कुछ सीक्रेट की जरूरत होती है, विभिन्न तरीकों से दुरुपयोग किया जा सकता है और आप मोबाइल एपीआई सिक्योरिटी टेक्नीक के बारे में लेखों की इस श्रृंखला पर अधिक जान सकते हैं । यह लेख आपको सिखाएगा कि एपीआई की सुरक्षा के लिए एपीआई कुंजी, उपयोगकर्ता एक्सेस टोकन, एचएमएसी और टीएलएस पिनिंग का उपयोग कैसे किया जा सकता है और उन्हें कैसे बाईपास किया जा सकता है।
WHAT की समस्या को हल करने के लिए आपके मोबाइल ऐप तक पहुँचने के लिए आपको मोबाइल एपीआई सुरक्षा तकनीकों के बारे में लेखों की श्रृंखला में उल्लिखित एक या सभी समाधानों का उपयोग करना होगा जिन्हें मैंने ऊपर उल्लेख किया है और स्वीकार किया है कि वे केवल आपके एपीआई सर्वर तक अनधिकृत पहुँच को कठिन बना सकते हैं। बाईपास लेकिन असंभव नहीं।
एक बेहतर समाधान को एक मोबाइल ऐप अटैचमेंट समाधान का उपयोग करके नियोजित किया जा सकता है जिससे एपीआई सर्वर को पता चल सकेगा कि एक वास्तविक मोबाइल ऐप से केवल अनुरोध प्राप्त हो रहा है।
मोबाइल ऐप अटैचमेंट
मोबाइल ऐप अटैचमेंट समाधान का उपयोग एपीआई सर्वर को यह जानने में सक्षम करेगा कि क्या अनुरोध भेज रहा है, इस प्रकार केवल असुरक्षित स्रोतों से अन्य सभी अनुरोधों को खारिज करते हुए एक वास्तविक मोबाइल ऐप से अनुरोधों का जवाब देने की अनुमति देता है।
मोबाइल ऐप सत्यापन समाधान की भूमिका रन-टाइम की गारंटी देने के लिए है कि आपके मोबाइल ऐप के साथ छेड़छाड़ नहीं की गई है, जड़ डिवाइस में नहीं चल रहा है, xPosed या फ्राइडा जैसी रूपरेखा द्वारा इंस्ट्रूमेंट नहीं किया जा रहा है, मिटम पर हमला नहीं किया जा रहा है और यह पृष्ठभूमि में एसडीके चलाकर हासिल किया जाता है। क्लाउड में चल रही सेवा ऐप को चुनौती देगी, और प्रतिक्रियाओं के आधार पर यह मोबाइल ऐप की अखंडता को प्रमाणित करेगा और डिवाइस चालू है, इसलिए एसडीके कभी भी किसी भी निर्णय के लिए जिम्मेदार नहीं होगा।
मोबाइल ऐप की अखंडता के सफल सत्यापन पर JWT टोकन जारी किया जाता है और एक रहस्य के साथ हस्ताक्षर किया जाता है कि केवल API सर्वर और क्लाउड में मोबाइल ऐप सत्यापन सेवा जागरूक हैं। मोबाइल ऐप के सत्यापन में विफलता के मामले में JWT टोकन को एक ऐसे रहस्य के साथ हस्ताक्षरित किया जाता है जिसे एपीआई सर्वर नहीं जानता है।
अब ऐप को हर एपीआई के साथ JWT टोकन को रिक्वेस्ट के हेडर में भेजना होगा। यह एपीआई सर्वर को केवल अनुरोधों की सेवा करने की अनुमति देगा जब यह JWT टोकन में हस्ताक्षर और समाप्ति समय को सत्यापित कर सकता है और सत्यापन विफल होने पर उन्हें मना कर सकता है।
एक बार जब मोबाइल ऐप अटैचमेंट सेवा द्वारा उपयोग किए जाने वाले रहस्य को मोबाइल ऐप द्वारा नहीं जाना जाता है, तो ऐप के छेड़छाड़, रूट किए गए डिवाइस में चलने या किसी कनेक्शन पर संचार करने पर भी इसे रन-टाइम पर रिवर्स करना संभव नहीं है। मध्य हमले में एक आदमी का लक्ष्य।
मोबाइल ऐप अटैचमेंट सेवा पहले से ही एप्रोच (मैं यहां काम करता है) पर एसएएएस समाधान के रूप में मौजूद है, जो आईओएस, एंड्रॉइड, रिएक्ट नेटिव और अन्य सहित कई प्लेटफार्मों के लिए एसडीके प्रदान करता है। क्लाउड सेवा द्वारा जारी किए गए JWT टोकन को सत्यापित करने के लिए एपीआई सर्वर कोड में एकीकरण को एक छोटे से चेक की भी आवश्यकता होगी। एपीआई सर्वर के लिए यह जाँच आवश्यक है कि वह यह तय करने में सक्षम हो कि किस सेवा के लिए क्या अनुरोध करना है और किससे इनकार करना है।
निष्कर्ष
अंत में, अपने एपीआई सर्वर की सुरक्षा के लिए उपयोग करने के लिए समाधान को उस प्रकार के डेटा के मूल्य के अनुसार चुना जाना चाहिए जो उस प्रकार के डेटा के लिए और कानूनी आवश्यकताओं के लिए यूरोप में GDPR नियमों की तरह है।
क्या आप एक्स्ट्रा मील जाना चाहते हैं?
OWASP मोबाइल सुरक्षा परियोजना - शीर्ष 10 जोखिम
OWASP मोबाइल सुरक्षा परियोजना एक केंद्रीकृत संसाधन है जो डेवलपर्स और सुरक्षा टीमों को उन संसाधनों को देने के लिए है जो उन्हें सुरक्षित मोबाइल एप्लिकेशन बनाने और बनाए रखने की आवश्यकता है। परियोजना के माध्यम से, हमारा लक्ष्य मोबाइल सुरक्षा जोखिमों को वर्गीकृत करना और उनके प्रभाव या शोषण की संभावना को कम करने के लिए विकासात्मक नियंत्रण प्रदान करना है।
