सभी को नमस्कार! मैं निकिता स्टुपिन, सूचना सुरक्षा विशेषज्ञ, Mail.Ru मेल हूँ। इतना समय पहले नहीं, मैंने मोबाइल OAuth 2.0 पर भेद्यता अनुसंधान किया। एक सुरक्षित मोबाइल OAuth 2.0 योजना बनाने के लिए, अपने शुद्ध रूप में मानक को लागू करना और रीडायरेक्ट_यूरी की जांच करना पर्याप्त नहीं है। मोबाइल एप्लिकेशन की बारीकियों को ध्यान में रखना और अतिरिक्त सुरक्षा तंत्र लागू करना आवश्यक है।

इस लेख में मैं आपके साथ मोबाइल OAuth 2.0 पर हमलों, सुरक्षा विधियों और इस प्रोटोकॉल के सुरक्षित कार्यान्वयन के बारे में ज्ञान साझा करना चाहता हूं। सभी आवश्यक सुरक्षा घटक, जिनके बारे में मैं नीचे चर्चा करूंगा, Mail.Ru मेल मोबाइल क्लाइंट के लिए नवीनतम SDK में कार्यान्वित किए जाते हैं।

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. ग्राहक पर भरोसा नहीं है।
2. एक ब्राउज़र से मोबाइल एप्लिकेशन तक रीडायरेक्ट का व्यवहार उपयोगकर्ता द्वारा स्थापित सेटिंग्स और अनुप्रयोगों पर निर्भर करता है।

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

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

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

नीचे दिए गए आरेख में सर्वर-से-सर्वर संचार में OAuth 2.0 का संचालन दिखाया गया है।


Https://tools.ietf.org/html/rfc6749#section-1.2 से ली गई छवि

OAuth 2.0 प्रोटोकॉल के 3 मुख्य चरण हैं:

1. [एसी कदम] प्राधिकरण कोड प्राप्त करें (बाद में बस code )।
2. [DE चरण] access_token code लिए एक्सचेंज code ।
3. access_token का उपयोग करके संसाधन तक access_token ।

आइए हम और अधिक विस्तार से कोड की प्राप्ति की जांच करें:

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

अधिक विस्तार से access_token प्राप्त करने access_token दें:

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

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

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


छवि https://tools.ietf.org/html/rfc8252#section-4.1 से ली गई है

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

1. [चित्र में 1-4 चरण] code प्राप्त करें।
2. [चित्र में 5-6 चरण] access_token code लिए एक्सचेंज code ।
3. access_token का उपयोग करके संसाधन तक access_token ।

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

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

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

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

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

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

1. प्रत्येक सेवा क्लाइंट को स्वतंत्र रूप से सत्यापन प्रक्रिया को पास करना होगा।
2. एंड्रॉइड उपयोगकर्ता सेटिंग्स में एक विशिष्ट एप्लिकेशन के लिए ऐपलिंक को बंद कर सकते हैं।
3. एंड्रॉइड 6.0 से नीचे और iOS 9.0 से नीचे ऐप्पलिंक का समर्थन नहीं करता है।

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

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

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

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

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


चित्र https://tools.ietf.org/html/rfc7636#section-1 से लिया गया है

यहां समस्या है: चरण 4 में, ब्राउज़र कस्टम यूआरआई योजना के माध्यम से आवेदन पर code लौटाता है, इसलिए code को मैलवेयर द्वारा इंटरसेप्ट किया जा सकता है (क्योंकि यह उसी योजना को वैध अनुप्रयोग के रूप में पंजीकृत करता है)। उसके बाद, मैलवेयर 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 ग्राहक को एक नया code_verifier उत्पन्न करना होगा।

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

Code_challenge एक code_verifier है, जिसके लिए code_challenge_method रूपांतरण code_challenge_method किया गया code_challenge_method और सुरक्षित Base64 URL में एन्कोड किया गया code_challenge_method ।

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

यदि उपयोगकर्ता का डिवाइस SHA-256 का समर्थन नहीं करता है , तो एक डाउनग्रेड की अनुमति दी जाती है जब तक कि code_verifier रूपांतरण गायब न हो । अन्य सभी मामलों में, आपको SHA-256 का उपयोग करना चाहिए।

योजना निम्नानुसार काम करती है:

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

आइए code_challenge कि क्यों code_challenge एक कोड अवरोधन हमले से खुद को बचाने की अनुमति देता है। ऐसा करने के लिए, हम access_token को प्राप्त करने के चरणों से access_token ।

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

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

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

OAuth 2.0 CSRF

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

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

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

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

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

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

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

CSRF टोकन आवश्यकताओं: कम से कम 256 बिट लंबी, छद्म आयामी दृश्यों के एक अच्छे स्रोत से प्राप्त की।

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

एक वैध ग्राहक होने का नाटक करने वाला मैलवेयर

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

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

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

अन्य हमले

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

क्या करें?

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

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

चलिए शुरुआत करते हैं कि कैसे सहमति स्क्रीन को ठीक से बढ़ाएं। मोबाइल उपकरणों पर, मूल एप्लिकेशन से एक वेब पेज खोलने के दो तरीके हैं (देशी अनुप्रयोगों के उदाहरण: Mail.Ru मेल, वीके, फेसबुक)।



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

मोबाइल OAuth 2.0 के संबंध में दूसरी विधि को "बढ़ाएँ WebView" (दाईं ओर की तस्वीर में) कहा जाता है, मैं इसे बहुत बुरा मानता हूं।

WebView एक देशी एप्लिकेशन के लिए एक स्टैंडअलोन ब्राउज़र है।

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

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

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

सभी मोर्चों पर एक बार विफलता:

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

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

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

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

हम प्राधिकरण कोड अनुदान योजना का उपयोग करेंगे क्योंकि यह हमें एक code_challenge जोड़ने और एक कोड अवरोधन हमले से code_challenge को बचाने की अनुमति देता है।


छवि 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&
anti_csrf=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&
anti_csrf=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24

चरण 4 में, ब्राउज़र कस्टम यूआरआई योजना खोलता है और code और सीएसआरएफ टोकन को क्लाइंट एप्लिकेशन को पास करता है।

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

इस प्रकार, हम Implicit Grant का उपयोग कर सकते हैं और मोबाइल OAuth 2.0 योजना को सरल बना सकते हैं। कोई code_challenge और CSRF टोकन नहीं। इसके अलावा, हम स्वयं को मैलवेयर से बचाने में सक्षम होंगे जो उपयोगकर्ता खातों को चोरी करने के लिए वैध ग्राहकों की नकल करते हैं।

ग्राहक एसडीके

ऊपर वर्णित सुरक्षित मोबाइल 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 के तहत - किचेन में, एंड्रॉइड के तहत - इंटरनल स्टोरेज में। ये रिपॉजिटरी विशेष रूप से ऐसे उद्देश्यों के लिए डिज़ाइन किए गए हैं। यदि आवश्यक हो, तो आप एंड्रॉइड में सामग्री प्रदाता का उपयोग कर सकते हैं, लेकिन इसे सुरक्षित रूप से कॉन्फ़िगर किया जाना चाहिए।
3. Code एक समय का होना चाहिए, एक छोटे जीवन समय के साथ।
4. कोड अवरोधन से बचाने के लिए, code_challenge उपयोग code_challenge ।
5. लॉगिन पर एक सीएसआरएफ हमले से बचाने के लिए, सीएसआरएफ टोकन का उपयोग करें।
6. सहमति स्क्रीन के लिए WebView का उपयोग न करें, ब्राउज़र कस्टम टैब का उपयोग करें।
7. अगर यह बैकएंड पर संग्रहीत नहीं है तो Client_secret बेकार है। इसे सार्वजनिक ग्राहकों को न दें।
8. HTTP पर डाउनग्रेड के निषेध के साथ, हर जगह HTTPS का उपयोग करें।
9. मानकों से क्रिप्टोग्राफी सिफारिशों (सिफर चयन, टोकन लंबाई, आदि) का पालन करें। आप डेटा की प्रतिलिपि बना सकते हैं और पता लगा सकते हैं कि ऐसा क्यों किया गया था, लेकिन आप अपनी क्रिप्टोग्राफी नहीं कर सकते ।
10. क्लाइंट एप्लिकेशन से, सत्यापित करें कि आप OAuth 2.0 के लिए कौन खोलते हैं, और प्रदाता एप्लिकेशन से, जाँच करें कि OAuth 2.0 के लिए आपको कौन खोलता है।
11. सामान्य OAuth 2.0 कमजोरियों से अवगत रहें। मोबाइल OAuth 2.0 नियमित रूप से विस्तारित होता है और नियमित रूप से पूरक होता है, इसलिए किसी ने नियमित OAuth 2.0 के लिए सटीक मैचों और अन्य सिफारिशों के लिए redirect_uri चेक को रद्द नहीं किया।
12. एसडीके ग्राहकों को प्रदान करना सुनिश्चित करें। क्लाइंट के पास कोड में कम बग और कमजोरियां होंगी, और आपके लिए आपके OAuth 2.0 को लागू करना आसान होगा।

क्या पढ़ना है?

1. [RFC] OAuth 2.0 नेटिव एप्स के लिए https://tools.ietf.org/html/rfc8252
2. मोबाइल और डेस्कटॉप ऐप्स के लिए Google OAuth 2.0 https://developers.google.com/identity/protocols/OAuth2EInallerApps
3. [RFC] OAuth सार्वजनिक ग्राहकों द्वारा कोड एक्सचेंज के लिए सबूत https://tools.ietf.org/html/rfc7636
4. OAuth 2.0 रेस कंडीशन https://hackerone.com/reports/55140
5. [RFC] OAuth 2.0 खतरा मॉडल और सुरक्षा संबंधी विचार https://tools.ietf.org/html/rfcF6819
6. नियमित OAuth 2.0 पर हमलों https://sakurity.com/oauth
7. [RFC] OAuth 2.0 डायनेमिक क्लाइंट पंजीकरण प्रोटोकॉल https://tools.ietf.org/html/rfc7591

धन्यवाद

हर किसी के लिए धन्यवाद जिन्होंने इस लेख को लिखने में मदद की, विशेष रूप से सर्गेई बेलोव, एंड्री स्यूमिन, एंड्री लैबंट्स ( @isciurus ) और डारिया याकोवलेवा।