मोबाइल एप्लिकेशन की लोकप्रियता लगातार बढ़ती जा रही है। तो मोबाइल एप्स पर OAuth 2.0 प्रोटोकॉल देता है। यह मानक लागू करने के लिए पर्याप्त नहीं है क्योंकि OAuth 2.0 प्रोटोकॉल को वहां सुरक्षित बनाने के लिए है। मोबाइल एप्लिकेशन की बारीकियों पर विचार करने और कुछ अतिरिक्त सुरक्षा तंत्र लागू करने की आवश्यकता है।

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

OAuth 2.0 प्रकृति और उद्देश्य

OAuth 2.0 एक प्राधिकरण प्रोटोकॉल है जो ग्राहक सेवा के लिए एक सेवा प्रदाता पर उपयोगकर्ता के संसाधनों तक सुरक्षित पहुंच प्राप्त करने का एक तरीका बताता है। OAuth 2.0 के लिए धन्यवाद, उपयोगकर्ता को सेवा प्रदाता के बाहर अपना पासवर्ड दर्ज करने की आवश्यकता नहीं है: पूरी प्रक्रिया "मैं सहमत हूं ..." बटन पर पहुंच प्रदान करने के लिए क्लिक करने पर कम हो जाती है।

एक प्रदाता एक सेवा है जो उपयोगकर्ता डेटा का मालिक है और उपयोगकर्ता की अनुमति से, इस डेटा तक सुरक्षित पहुंच के साथ तृतीय पक्ष सेवाएं (क्लाइंट) प्रदान करता है। एक क्लाइंट एक एप्लिकेशन है जो प्रदाता द्वारा संग्रहीत उपयोगकर्ता डेटा प्राप्त करना चाहता है।

OAuth 2.0 प्रोटोकॉल जारी होने के तुरंत बाद, इसे प्रमाणीकरण के लिए अनुकूलित किया गया था, भले ही इसके लिए इसका मतलब नहीं था। प्रमाणीकरण के लिए OAuth 2.0 का उपयोग सेवा प्रदाता से ग्राहक सेवा उपयोगकर्ता खातों में संग्रहीत डेटा से एक हमले के वेक्टर को स्थानांतरित करता है।

लेकिन प्रमाणीकरण सिर्फ एक शुरुआत थी। मोबाइल एप्लिकेशन और रूपांतरण महिमा के समय में, केवल एक बटन के साथ एक ऐप का उपयोग करना अच्छा लग रहा था। डेवलपर्स ने मोबाइल उपयोग के लिए OAuth 2.0 को अनुकूलित किया। बेशक, मोबाइल एप्लिकेशन सुरक्षा और बारीकियों के बारे में बहुत चिंतित नहीं हैं: झपकी और उत्पादन में वे चले गए! फिर से, OAuth 2.0 वेब अनुप्रयोगों के बाहर अच्छी तरह से काम नहीं करता है: मोबाइल और डेस्कटॉप ऐप दोनों में समान समस्याएं हैं।

तो, आइए जानें कि मोबाइल OAuth 2.0 को सुरक्षित कैसे बनाया जाए।

यह कैसे काम करता है?

दो प्रमुख मोबाइल OAuth 2.0 सुरक्षा मुद्दे हैं:

1. असत्य ग्राहक। कुछ मोबाइल एप्लिकेशन में OAuth 2.0 का बैकएंड नहीं है, इसलिए प्रोटोकॉल प्रवाह का क्लाइंट हिस्सा मोबाइल डिवाइस पर जाता है।
   
2. एक ब्राउज़र से मोबाइल ऐप पर पुनर्निर्देशन सिस्टम सेटिंग्स के आधार पर अलग-अलग व्यवहार करते हैं, जिस क्रम में एप्लिकेशन इंस्टॉल किए जाते हैं और अन्य जादू करते हैं।
   

आइए इन मुद्दों पर गहराई से देखें।

मोबाइल एप्लिकेशन एक सार्वजनिक ग्राहक है

पहले अंक की जड़ों और परिणामों को समझने के लिए, आइए देखें कि सर्वर-टू-सर्वर इंटरैक्शन के मामले में OAuth 2.0 कैसे काम करता है और फिर क्लाइंट-टू-सर्वर इंटरैक्शन के मामले में OAuth 2.0 के साथ तुलना करें।

दोनों मामलों में, यह सब प्रदाता सेवा पर ग्राहक सेवा रजिस्टर के साथ शुरू होता है और client_id प्राप्त करता है और , कुछ मामलों में , client_secret. client_id , client_secret. client_id एक सार्वजनिक मूल्य है, और यह ग्राहक सेवा पहचान के लिए आवश्यक है जैसा कि client_secret मान के विपरीत है, जो निजी है। आप RFC 7591 में पंजीकरण प्रक्रिया के बारे में अधिक पढ़ सकते हैं।

नीचे दी गई योजना OAuth 2.0 को सर्वर-से-सर्वर इंटरैक्शन के मामले में संचालित करती है।


चित्र उत्पत्ति: https://tools.ietf.org/html/rfc6749#section-1.2

OAuth 2.0 प्रोटोकॉल को तीन मुख्य चरणों में विभाजित किया जा सकता है:

1. [चरण AC] एक authorization_code प्राप्त करें (बाद में, code )।
   
2. [चरण DE] access_token को एक्सचेंज code ।
   
3. access_token माध्यम से संसाधन प्राप्त करें।

code मान प्राप्त करने की प्रक्रिया के बारे में विस्तार से बताते हैं:

1. [चरण ए] क्लाइंट सेवा प्रदाता के लिए उपयोगकर्ता को पुनर्निर्देशित करता है।
   
2. [चरण बी] सेवा प्रदाता ग्राहक से डेटा (तीर बी अप) प्रदान करने के लिए उपयोगकर्ता से अनुमति का अनुरोध करता है। उपयोगकर्ता डेटा एक्सेस (दाईं ओर तीर B) प्रदान करता है।
   
3. [चरण C] सेवा प्रदाता उपयोगकर्ता ब्राउज़र में code लौटाता है जो ग्राहक को code पुनर्निर्देशित करता है।
   

चलिए अधिक बात करते हैं access_token प्राप्त करने की प्रक्रिया:

1. [चरण डी] क्लाइंट सर्वर access_token लिए एक अनुरोध भेजता है। अनुरोध में Code , client_secret और redirect_uri शामिल हैं।
   
2. [चरण E] मान्य code मामले में, client_secret और redirect_uri , access_token प्रदान किया जाता है।
   

access_token लिए अनुरोध सर्वर-से-सर्वर योजना के अनुसार किया जाता है: इसलिए, सामान्य रूप से, access_token को चुराने के लिए हमलावर को क्लाइंट सेवा सर्वर या सेवा प्रदाता सर्वर को हैक करना access_token ।

अब बिना बैकएंड (क्लाइंट-टू-सर्वर इंटरैक्शन) के मोबाइल OAuth 2.0 योजना को देखें।


चित्र उत्पत्ति: https://tools.ietf.org/html/rfc8252#section-4.1

मुख्य योजना को मुख्य चरणों में विभाजित किया गया है:

1. [चित्र में 1-4 चरण] code प्राप्त करें।
2. [तस्वीर में 5-6 कदम] access_token code लिए एक्सचेंज code
3. access_token माध्यम से संसाधन पहुँच प्राप्त करें

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

आप पूछ सकते हैं: "हमें तुरंत access_token क्यों नहीं मिलती है?" आप सोच सकते हैं कि यह अतिरिक्त कदम अनावश्यक है। इसके अलावा access_token ग्रांट स्कीम है जो क्लाइंट को तुरंत access_token पाने की अनुमति देता है। हालांकि, यह कुछ मामलों में इस्तेमाल किया जा सकता है, Implicit अनुदान सुरक्षित मोबाइल OAuth 2.0 के लिए काम नहीं करेगा।

मोबाइल उपकरणों पर पुनर्निर्देशन

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

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

यह आसान बनाता है जब एक डिवाइस पर हर योजना एक आवेदन के साथ मेल खाती है। लेकिन क्या होगा अगर दो एप्लिकेशन एक ही डिवाइस पर एक ही स्कीम रजिस्टर करते हैं? कस्टम URI स्कीम के माध्यम से संपर्क करने पर ऑपरेशन सिस्टम कैसे तय करता है कि किस ऐप को खोला जाए? एंड्रॉइड एक ऐप की पसंद और अनुसरण करने के लिए लिंक के साथ एक विंडो दिखाएगा। iOS के पास इसके लिए कोई प्रक्रिया नहीं है और इसलिए, या तो आवेदन खोला जा सकता है। वैसे भी, हमलावर को कोड या access_token को इंटरसेप्ट करने का मौका मिलता है ।

कस्टम URI योजना के विपरीत, AppLink सही एप्लिकेशन को खोलने की गारंटी देती है, लेकिन इस तंत्र में कई खामियां हैं:

1. हर सेवा क्लाइंट को सत्यापन प्रक्रिया से गुजरना होगा।
   
2. Android उपयोगकर्ता सेटिंग्स में किसी विशिष्ट ऐप के लिए AppLink को बंद कर सकते हैं।
   
3. Android संस्करण 6.0 से अधिक पुराने और iOS संस्करण 9.0 से अधिक पुराने AppLink का समर्थन नहीं करते हैं।
   

इन सभी AppLink दोष संभावित सेवा ग्राहकों के लिए सीखने की अवस्था को बढ़ाते हैं और इसके परिणामस्वरूप कुछ परिस्थितियों में उपयोगकर्ता OAuth 2.0 विफलता हो सकती है। यही कारण है कि कई डेवलपर्स OAuth 2.0 प्रोटोकॉल में पुनर्निर्देशित ब्राउज़र के प्रतिस्थापन के रूप में AppLink तंत्र का चयन नहीं करते हैं।

ठीक है, हमला करने के लिए क्या है?

मोबाइल OAuth 2.0 समस्याओं ने कुछ विशिष्ट हमले बनाए हैं। आइए देखें कि वे क्या हैं और कैसे काम करते हैं।

प्राधिकरण कोड अवरोधन हमला

आइए उस स्थिति पर विचार करें जहां उपयोगकर्ता डिवाइस में एक वैध एप्लिकेशन (OAuth 2.0 क्लाइंट) है और एक दुर्भावनापूर्ण एप्लिकेशन है जो एक ही योजना को वैध के रूप में पंजीकृत करता है। नीचे दी गई तस्वीर हमले की योजना को दर्शाती है।


चित्र उत्पत्ति https://tools.ietf.org/html/rfc7636#section-1

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

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


चित्र उत्पत्ति: https://tools.ietf.org/html/rfc7636#section-1.1

क्लाइंट अनुरोध में कई अतिरिक्त पैरामीटर हैं: code_verifier , code_challenge (स्कीम t(code_verifier) ) और code_challenge_method (स्कीम t_m )।

Code_verifier - एक यादृच्छिक संख्या है जिसकी न्यूनतम लंबाई 256 बिट है , जिसका उपयोग केवल एक बार किया जाता है । इसलिए, एक ग्राहक को हर code अनुरोध के लिए एक नया code_verifier जनरेट करना होगा।

Code_challenge_method - यह एक रूपांतरण फ़ंक्शन का नाम है, जिसमें ज्यादातर SHA-256 है।

Code_challenge - code_verifier है जिसके लिए code_challenge_method रूपांतरण लागू किया गया था और जिसे URL Safe Base64 में कोडित किया गया था।

कोड का code_verifier करते code_challenge code_verifier में code_challenge का रूपांतरण code_verifier code_verifier इंटरसेप्शन (उदाहरण के लिए, डिवाइस सिस्टम लॉग से) के आधार पर अटैक वेक्टर्स को code_challenge से करने के लिए आवश्यक है।

मामले में जब उपयोगकर्ता डिवाइस SHA-256 का समर्थन नहीं करता है , तो client is allowed to use plain conversion of code_verifier । अन्य सभी मामलों में, SHA-256 का उपयोग किया जाना चाहिए।

इस तरह से यह योजना काम करती है:

1. क्लाइंट code_verifier और उसे याद करता है।
   
2. ग्राहक code_challenge_method चयन करता है और code_challenge से code_verifier प्राप्त करता है।
   
3. [चरण A] क्लाइंट अनुरोध code , code_challenge और code_challenge_method साथ अनुरोध में जोड़ा गया।
   
4. [चरण बी] प्रदाता सर्वर पर code_challenge और code_challenge_method संग्रहीत code_challenge और एक ग्राहक को code देता है।
   
5. [चरण C] क्लाइंट अनुरोध access_token के साथ, code_verifier को इसमें जोड़ा जाता है।
   
6. प्रदाता आने वाले code_challenge से code_challenge प्राप्त करता है, और फिर इसे code_challenge से तुलना करता है, जिससे यह बच गया।
   
7. [चरण डी] यदि मान मेल खाते हैं, तो प्रदाता क्लाइंट को access_token देता है।
   

यह समझने के लिए कि code_challenge कोड अवरोधन को क्यों code_challenge आइए देखें कि हमलावर के दृष्टिकोण से प्रोटोकॉल प्रवाह कैसा दिखता है।

1. सबसे पहले, वैध एप्लिकेशन अनुरोध code ( code_challenge और code_challenge_method अनुरोध के साथ भेजे जाते हैं )।
   
2. दुर्भावनापूर्ण एप्लिकेशन कोड को _challenge है (लेकिन code_challenge नहीं, क्योंकि कोड _challenge प्रतिक्रिया में नहीं है)।
   
3. दुर्भावनापूर्ण ऐप access_token (मान्य code साथ, लेकिन मान्य code_verifier बिना ) का अनुरोध करता है।
   
4. सर्वर code_challenge बेमेल नोटिस code_challenge और एक त्रुटि संदेश उठाता है।
   

ध्यान दें कि हमलावर code_verifier (यादृच्छिक 256 बिट मान!) का अनुमान नहीं लगा सकता है या उसे लॉग में कहीं मिल सकता है (क्योंकि पहले अनुरोध वास्तव में code_challenge प्रसारित code_challenge )।

तो, code_challenge सेवा प्रदाता के प्रश्न का उत्तर देता है: "क्या access_token उसी एप्लिकेशन क्लाइंट द्वारा अनुरोध किया गया है जो code या एक अलग अनुरोध करता है?"।

OAuth 2.0 CSRF

OAuth 2.0 CSRF अपेक्षाकृत हानिरहित है जब OAuth 2.0 का उपयोग प्राधिकरण के लिए किया जाता है। यह पूरी तरह से अलग कहानी है जब OAuth 2.0 प्रमाणीकरण के लिए उपयोग किया जाता है। इस मामले में OAuth 2.0 CSRF अक्सर खाता अधिग्रहण की ओर जाता है।

सीएसआरएफ हमले के बारे में अधिक बात करते हैं जो टैक्सी ऐप क्लाइंट और प्रदाता.कॉम प्रदाता के उदाहरण के माध्यम से OAuth 2.0 के अनुरूप है। सबसे पहले, अपने डिवाइस पर एक हमलावर हमलावर @ attacker@provider.com खाते में प्रवेश करता है और टैक्सी code लिए code प्राप्त करता है। फिर वह OAuth 2.0 प्रक्रिया को बाधित करता है और एक लिंक बनाता है:

 com.taxi.app://oauth? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4 

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

अब हमलावर किसी भी समय पीड़ित के टैक्सी खाते में प्रवेश कर सकता है, क्योंकि यह attacker@provider.com से जुड़ा हुआ है। CSRF लॉगिन हमले ने उल्लंघनकर्ता को एक खाता चोरी करने की अनुमति दी।

CSRF के हमलों को आमतौर पर CSRF टोकन (इसे state भी कहा जाता state ) के साथ फिर से जोड़ दिया जाता state , और OAuth 2.0 कोई अपवाद नहीं है। CSRF टोकन का उपयोग कैसे करें:

1. क्लाइंट एप्लिकेशन जेनरेट करता है और ग्राहक के मोबाइल डिवाइस पर CSRF टोकन बचाता है।
   
2. क्लाइंट एप्लिकेशन में code पहुंच अनुरोध में CSRF टोकन शामिल है।
   
3. सर्वर अपनी प्रतिक्रिया में code साथ समान CSRF टोकन लौटाता है।
   
4. क्लाइंट एप्लिकेशन आने वाले और सहेजे गए CSRF टोकन की तुलना करता है। यदि उनका मान मेल खाता है, तो प्रक्रिया आगे बढ़ती है।
   

CSRF टोकन आवश्यकताएं: गैर- कम से कम 256 बिट होना चाहिए और छद्म यादृच्छिक अनुक्रम के अच्छे स्रोत से प्राप्त किया जाना चाहिए।

संक्षेप में, CSRF टोकन एक एप्लिकेशन क्लाइंट को निम्नलिखित प्रश्न का उत्तर देने की अनुमति देता है: "क्या वह था जिसने मुझे access_token अनुरोध शुरू किया था या कोई मुझे धोखा देने की कोशिश कर रहा है?"।

हार्डकोड ग्राहक रहस्य

बैकएंड के बिना मोबाइल एप्लिकेशन कभी-कभी हार्डकोडेड client_secret और client_secret मानों को client_secret करते हैं। बेशक वे रिवर्स इंजीनियरिंग ऐप द्वारा आसानी से निकाले जा सकते हैं।

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

क्यों OAuth एपीआई कुंजी और राज मोबाइल ऐप्स में सुरक्षित नहीं हैं लेख इस विषय पर अधिक विस्तृत है।

एक वैध ग्राहक के रूप में काम करने वाला दुर्भावनापूर्ण ऐप

कुछ दुर्भावनापूर्ण ऐप्स वैध ऐप्स की नकल कर सकते हैं और उनकी ओर से एक सहमति स्क्रीन प्रदर्शित कर सकते हैं (एक सहमति स्क्रीन एक स्क्रीन है जहां एक उपयोगकर्ता देखता है: "मैं ... को एक्सेस प्रदान करने के लिए सहमत हूं")। उपयोगकर्ता "अनुमति" पर क्लिक कर सकता है और अपने डेटा के साथ दुर्भावनापूर्ण एप्लिकेशन प्रदान कर सकता है।

एंड्रॉइड और आईओएस अनुप्रयोगों के तंत्र को क्रॉस-चेक प्रदान करते हैं। एक अनुप्रयोग प्रदाता यह सुनिश्चित कर सकता है कि एक ग्राहक आवेदन वैध है और इसके विपरीत।

दुर्भाग्य से, अगर OAuth 2.0 तंत्र ब्राउज़र के माध्यम से एक थ्रेड का उपयोग करता है, तो इस हमले से बचाव करना असंभव है।

अन्य हमले

हमने मोबाइल OAuth 2.0 के लिए किए गए हमलों पर बारीकी से ध्यान दिया। हालाँकि, हम मूल OAuth 2.0 के बारे में नहीं भूलना चाहिए: redirect_uri प्रतिस्थापन, असुरक्षित कनेक्शन के माध्यम से यातायात अवरोधन, आदि। आप इसके बारे में और अधिक यहाँ पढ़ सकते हैं।

इसे सुरक्षित रूप से कैसे करें?

हमने सीखा है कि OAuth 2.0 प्रोटोकॉल कैसे काम करता है और मोबाइल उपकरणों पर इसकी क्या कमजोरियां हैं। अब एक अलग मोबाइल OAuth 2.0 योजना रखने के लिए अलग-अलग टुकड़े रखें।

अच्छा, बुरा OAuth 2.0

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



पहला तरीका ब्राउज़र कस्टम टैब (चित्र में बाईं ओर) के माध्यम से है। नोट : Android के लिए ब्राउज़र कस्टम टैब को क्रोम कस्टम टैब कहा जाता है, और iOS के लिए - SafariViewController। यह सिर्फ ऐप में प्रदर्शित एक ब्राउज़र टैब है: अनुप्रयोगों के बीच कोई दृश्य स्विचिंग नहीं है।

दूसरा तरीका WebView (चित्र में दाईं ओर) के माध्यम से है और मैं इसे मोबाइल OAuth 2.0 के संबंध में बुरा मानता हूं।

WebView एक मोबाइल ऐप के लिए एक एम्बेडेड ब्राउज़र है।

" एंबेडेड ब्राउजर " का अर्थ है कि कुकीज़, स्टोरेज, कैश, हिस्ट्री और अन्य सफारी और क्रोम डेटा तक पहुंच वेब व्यू के लिए मना है। रिवर्स भी सही है: सफारी और क्रोम वेब व्यू डेटा तक पहुंच प्राप्त नहीं कर सकते हैं।

" मोबाइल ऐप ब्राउज़र " का अर्थ है कि वेबव्यू चलाने वाला मोबाइल ऐप कुकीज, स्टोरेज, कैश, हिस्ट्री और अन्य वेबव्यू डेटा तक पूरी पहुंच रखता है।

अब, कल्पना करें: एक उपयोगकर्ता क्लिक करता है "के साथ दर्ज करें ..." और एक दुर्भावनापूर्ण एप्लिकेशन का एक WebView सेवा प्रदाता से उसके लॉगिन और पासवर्ड का अनुरोध करता है।

महाकाव्य असफल:

1. उपयोगकर्ता ऐप में सेवा प्रदाता खाते के लिए अपना लॉगिन और पासवर्ड दर्ज करता है, जो आसानी से इस डेटा को चुरा सकता है।
   
2. OAuth 2.0 को शुरू में सेवा प्रदाता लॉगिन और पासवर्ड दर्ज नहीं करने के लिए विकसित किया गया था ।
   
   उपयोगकर्ता को कहीं भी मछली पकड़ने की संभावना बढ़ाने के लिए अपने लॉगिन और पासवर्ड दर्ज करने की आदत होती है।
   

WebView के सभी विपक्ष को ध्यान में रखते हुए, एक स्पष्ट निष्कर्ष स्वयं प्रदान करता है: सहमति स्क्रीन के लिए ब्राउज़र कस्टम टैब का उपयोग करें।

यदि किसी के पास ब्राउज़र कस्टम टैब के बजाय WebView के पक्ष में तर्क हैं, तो आप इसकी सराहना करेंगे यदि आप टिप्पणियों में इसके बारे में लिखते हैं।

सुरक्षित मोबाइल OAuth 2.0 योजना

हम प्राधिकरण कोड अनुदान योजना का उपयोग करने जा रहे हैं, क्योंकि यह हमें code_challenge साथ-साथ state को जोड़ने और एक कोड अवरोधन हमले और OAuth 2.0 CSRF के खिलाफ बचाव करने की अनुमति देता है।


चित्र उत्पत्ति: https://tools.ietf.org/html/rfc8252#section-4.1

कोड एक्सेस अनुरोध (चरण 1-2) निम्नानुसार होंगे:

 https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 3 डी% 3 डी और https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 

चरण 3 पर, ब्राउज़र को पुनर्निर्देशित के साथ प्रतिक्रिया मिलती है:

 com.mail.cloud.app://outh? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24 

चरण 4 पर, ब्राउज़र कस्टम यूआरआई योजना खोलता है और ग्राहक ऐप पर सीएसआरएफ टोकन पास करता है।
access_token अनुरोध (चरण 5):

 https://o2.mail.ru/token? code_verifier=e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc& code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& client_id=984a644ec3b56d32b0404777e1eb73390c 

अंतिम चरण access_token साथ प्रतिक्रिया लाता है।

यह योजना आम तौर पर सुरक्षित है, लेकिन कुछ विशेष मामले हैं जब OAuth 2.0 सरल और अधिक सुरक्षित हो सकता है।

Android IPC

एंड्रॉइड में प्रक्रियाओं के बीच द्विदिश डेटा संचार का एक तंत्र है: IPC (अंतर-प्रक्रिया संचार)। IPC दो कारणों से कस्टम URI स्कीम से बेहतर है:

1. एक ऐप जो IPC चैनल को खोलता है, वह एक ऐप की प्रमाणिकता की पुष्टि कर सकता है जिसे वह अपने प्रमाणपत्र द्वारा खोल रहा है। रिवर्स भी सच है: खोला गया ऐप उस ऐप की प्रामाणिकता की पुष्टि कर सकता है जिसने इसे खोला था।
   
2. यदि कोई प्रेषक IPC चैनल के माध्यम से अनुरोध भेजता है, तो वह उसी चैनल के माध्यम से उत्तर प्राप्त कर सकता है। क्रॉस-चेक (आइटम 1) के साथ मिलकर, इसका मतलब है कि कोई भी विदेशी प्रक्रिया access_token को बाधित नहीं कर access_token ।
   

इसलिए, हम मोबाइल OAuth 2.0 योजना को सरल बनाने के लिए Implicit Grant का उपयोग कर सकते हैं। कोई भी code_challenge और state का मतलब कम हमले की सतह नहीं है। उपयोगकर्ता खातों को चुराने के लिए वैध ग्राहक की तरह काम करने वाले दुर्भावनापूर्ण ऐप्स के जोखिमों को भी कम कर सकते हैं।

ग्राहकों के लिए एस.डी.के.

इस सुरक्षित मोबाइल OAuth 2.0 योजना को लागू करने के अलावा, एक प्रदाता को अपने ग्राहकों के लिए एसडीके विकसित करना चाहिए। यह OAuth 2.0 कार्यान्वयन को क्लाइंट की ओर सरल करेगा और साथ ही त्रुटियों और कमजोरियों की संख्या को कम करेगा।

निष्कर्ष

मैं इसे आपके लिए संक्षेप में बताता हूं। यहाँ OAuth 2.0 प्रदाताओं के लिए सुरक्षित OAuth 2.0 के लिए बुनियादी (मूल) चेकलिस्ट है:

1. मजबूत नींव महत्वपूर्ण है। मोबाइल OAuth 2.0 के मामले में, नींव एक योजना या कार्यान्वयन के लिए उठाया गया एक प्रोटोकॉल है। अपनी OAuth 2.0 योजना को लागू करते समय गलतियाँ करना आसान है। दूसरों ने पहले ही दस्तक दे दी है और अपना सबक सीखा है; उनकी गलतियों से सीखने में कुछ भी गलत नहीं है और एक ही बार में सुरक्षित कार्यान्वयन करें। सबसे सुरक्षित मोबाइल OAuth 2.0 योजना यह वर्णित है कि इसे सुरक्षित रूप से कैसे किया जाए ?
   
2. Access_token और अन्य संवेदनशील डेटा iOS के लिए और Android के लिए आंतरिक संग्रहण में किचेन में संग्रहीत किए जाने चाहिए। ये भंडारण विशेष रूप से सिर्फ उसी के लिए विकसित किए गए थे। सामग्री प्रदाता का उपयोग एंड्रॉइड में किया जा सकता है, लेकिन इसे सुरक्षित रूप से कॉन्फ़िगर किया जाना चाहिए।
   
3. जब तक यह बैकएंड में संग्रहीत नहीं किया जाता है तब तक Client_secret बेकार है । इसे सार्वजनिक ग्राहकों को न दें।
   
4. सहमति स्क्रीन के लिए WebView का उपयोग न करें; ब्राउज़र कस्टम टैब का उपयोग करें।
   
5. कोड अवरोधन हमले से बचाव के लिए, code_challenge उपयोग code_challenge ।
   
6. OAuth 2.0 CSRF से बचाव के लिए, state उपयोग करें।
   
7. HTTP पर निषिद्ध के साथ, हर जगह HTTPS का उपयोग करें। यहां 3-मिनट का डेमो बताया गया है कि (उदाहरण के लिए बग बाउंटी से) क्यों।
   
8. क्रिप्टोग्राफी मानकों (एल्गोरिथ्म की पसंद, टोकन की लंबाई, आदि) का पालन करें। आप डेटा की प्रतिलिपि बना सकते हैं और यह पता लगा सकते हैं कि ऐसा क्यों किया गया है, लेकिन अपना स्वयं का क्रिप्टो रोल न करें।
   
9. Code का उपयोग केवल एक बार किया जाना चाहिए, एक छोटी उम्र के साथ।
   
10. एक ऐप क्लाइंट की ओर से, OAuth 2.0 के लिए आप जो भी खोलते हैं, उसे देखें; और ऐप प्रदाता की ओर से, जांचें कि OAuth 2.0 के लिए आपको कौन खोलता है।
    
11. आम OAuth 2.0 कमजोरियों को ध्यान में रखें। मोबाइल OAuth 2.0 का विस्तार करता है और मूल को पूरा करता है, इसलिए, एक सटीक मिलान के लिए redirect_uri करें और मूल OAuth 2.0 के लिए अन्य अनुशंसाएँ अभी भी लागू हैं।
    
12. आपको अपने ग्राहकों को एसडीके के साथ प्रदान करना चाहिए। उनके पास कम बग और भेद्यताएँ होंगी और आपके लिए अपने OAuth 2.0 को लागू करना आसान होगा।
    

आगे पढ़ रहे हैं

1. "मोबाइल OAuth 2.0 की कमजोरियाँ" https://www.youtube.com/watch?v=vjCF_O6aZIg
   
2. OAuth 2.0 जाति स्थिति अनुसंधान https://hackerone.com/reports/55140
   
3. OAuth 2.0 के बारे में लगभग सब कुछ एक ही जगह पर है https://oauth.net/2/
   
4. OAuth API कीज़ और सीक्रेट्स मोबाइल ऐप्स में सुरक्षित क्यों नहीं हैं https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
   
5. [RFC] OAuth 2.0 नेटिव एप्स के लिए https://tools.ietf.org/html/rfc8252
   
6. [RFC] OAuth सार्वजनिक ग्राहकों द्वारा कोड एक्सचेंज के लिए सबूत https://tools.ietf.org/html/rfc7636
   
7. [RFC] OAuth 2.0 खतरा मॉडल और सुरक्षा संबंधी विचार https://tools.ietf.org/html/rfcF6819
   
8. [RFC] OAuth 2.0 डायनेमिक क्लाइंट पंजीकरण प्रोटोकॉल https://tools.ietf.org/html/rfc7591
   
9. मोबाइल और डेस्कटॉप ऐप्स के लिए Google OAuth 2.0 https://developers.google.com/identity/protocols/OAuth2EInallerApps
   

क्रेडिट

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