2015-05-26 6 views
8

परिदृश्य:सर्वश्रेष्ठ अभ्यास ios

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

इसे लागू करते समय (यूआरएल योजना का उपयोग करके), हम सोचते हैं कि यह तरीका कितना सुरक्षित है? सैद्धांतिक रूप से - एक दुर्भावनापूर्ण एप्लिकेशन उसी यूआरएल योजना के लिए साइन अप कर सकता है, और एप्पल के अनुसार:

नोट: एक से अधिक तृतीय-पक्ष एप्लिकेशन उसी यूआरएल योजना को संभालने के लिए पंजीकृत करता है, वहाँ वर्तमान में निर्धारित करने के लिए कोई प्रक्रिया है कौन सा ऐप उस योजना को दिया जाएगा।

Implementing Custom URL Schemes by Apple

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

क्या इस तरह के परिदृश्य को संभालने वाले कोई सर्वोत्तम अभ्यास हैं? मैंने इस मुद्दे के बारे में कई लेख पढ़े हैं, उनमें से सभी का दावा है कि एकमात्र समाधान है कि ऐप्पल इन यूआरएल योजनाओं को अद्वितीय बनाने के लिए इंतजार कर रहा है। example1, example2

मैं पहले से इस मुद्दे के लिए किसी भी समाधान के बारे में सुनने प्यार होता है, तो मौजूद हैं, धन्यवाद! इस तरह

उत्तर

4

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

एक विकल्प हो सकता है:

  1. पंजीकरण के भाग के एक सार्वजनिक/निजी कुंजी युग्म का निर्माण और अपने अनुप्रयोग में संग्रहीत है।
  2. पंजीकरण प्रक्रिया के हिस्से के रूप में अपनी वेब बैकएंड पर सार्वजनिक कुंजी भेजें।
  3. उस सार्वजनिक कुंजी का उपयोग करके वे आपके यूआरएल का पेलोड एन्कोड करें।

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

एन्कोडेड डेटा एक टोकन हो सकता है जिसे हम उपयोगकर्ता को प्रमाणीकृत करने के लिए उपयोग कर सकते हैं और इसलिए उन्हें ऐप के भीतर फिर से प्रमाणीकृत करने की आवश्यकता नहीं होती है। फिर अनुकरण करने के लिए कोई लॉगिन स्क्रीन नहीं है (हालांकि एक चतुर जालसाजी अभी भी उपयोगकर्ताओं को उनके प्रमाण-पत्रों को प्रकट करने के लिए पर्याप्त चाल हो सकती है)।

उपयोगकर्ता के पासवर्ड के साथ गठबंधन करने के लिए ग्राहक पर संग्रहीत एक समान प्रति-उपयोगकर्ता रहस्य का उपयोग करने का एक विकल्प हो सकता है। अकेले उनका पासवर्ड प्रमाणीकृत करने के लिए अपर्याप्त हो सकता है, इसलिए उनके क्रेडेंशियल्स को कैप्चर करने वाला एक दुर्भावनापूर्ण ऐप तुरंत उनके खाते तक पहुंचने में सक्षम नहीं होता है।

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

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

+0

ये विकल्प बहुत ही रोचक हैं, और फिर भी, जैसा आपने बताया है - इसका मतलब केवल एक डिवाइस का समाधान होगा। आईओएस 9 के बारे में अफवाहें हैं कि यह सुरक्षा (स्थिरता और अनुकूलन के साथ) पर ध्यान केंद्रित करने जा रही है - तो हो सकता है कि अनुमानित समाधान (ऐप्पल को ठीक करने के लिए ऐप्पल का) बस कोने के आसपास है। आपका बहुत बहुत धन्यवाद! – goldengil

1

कोशिश कुछ:

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

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

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

+1

एक दुर्भावनापूर्ण ऐप इस टोकन को कैप्चर कर सकता है और जो क्लाइंट साइड एक्शन कर सकता है वह इच्छित प्राप्तकर्ता ऐप सामान्य रूप से करेगा। – Jonah

+1

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

संबंधित मुद्दे