दो अनुप्रयोगों के बीच सुरक्षित डेटा अंतरण

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

कार्य

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

विकल्प # 1: QUERY DEEPLINK

सबसे स्पष्ट विकल्प टोकन डीपलिंक को टोकन स्थानांतरित करना है। यह कुछ इस तरह दिखेगा:
slave://main?sessionId=686A885A4FB644053C584B9BE2A70C7D
इस मामले में, प्राप्तकर्ता सेशनआईड निकालने और उपयोगकर्ता से प्राधिकरण का अनुरोध किए बिना इसका उपयोग करने में सक्षम होगा। डेवलपर की ओर से, ऐसा लगता है कि कार्य पूरा हो गया है, लेकिन चलो थोड़ा गहरा खुदाई करते हैं।

डीपलिंक हाइजैकिंग

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

वैचारिक रूप से, प्रक्रिया इस तरह दिखती है:



इस समस्या के 2 समाधान हैं। सबसे पहले, AppLinks तकनीक अब डेवलपर्स को योजना को अनुकूलित करने की अनुमति नहीं देती है, इसके बजाय, http / https का उपयोग किया जाता है। इस स्थिति में, OS slave.com/profile लिंक लेता है और सत्यापन के लिए slave.com होस्ट से संपर्क करता है। दूसरा - इंटेंट URL - कॉल स्लेव के बजाय: //, आशय: // कहा जाता है, जहां लॉन्च किए जाने वाले एप्लिकेशन का विशिष्ट पहचानकर्ता पारित किया जाता है। यह इस तरह दिखता है:

 intent://main/#Intent;scheme=slave;package=com.example.slave.client.android;end" 

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

सत्र निर्धारण

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


यह हमारे मामले में कैसा दिखता है:

1. हमलावर को आवेदन से गुमनाम सत्र मिलता है
2. बैंक की ओर से पीड़ित को एक पत्र खूबसूरती से फेंकता है, जिसमें उसे अपने व्यक्तिगत खाते में जाने के लिए आमंत्रित किया जाता है
3. जब लिंक पर क्लिक करते हैं, तो हम हमलावर सत्र दास के साथ डीपलिंक करते हैं: // मुख्य? sessionId = 686A885A4FB644053C584B9BE2A70C7D
4. मोबाइल एप्लिकेशन एक सत्र लेता है, समझता है कि उसके पास पर्याप्त अधिकार नहीं हैं और उपयोगकर्ता को प्रमाणित करने के लिए कहता है
5. उपयोगकर्ता इसे पास करता है, सत्र ने अधिकारों में वृद्धि की है
6. आवेदन में उपयोगकर्ता, एक विशेषाधिकार प्राप्त सत्र के साथ एक हमलावर, लाभ

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

3 पार्टी रिसाव

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

विकल्प # 2: संपर्क प्रदाता

हम इसे कैसे करेंगे? हम मास्टर कंटेंट-प्रोवाइडर को परिभाषित करते हैं और गुलाम को इस कॉन्टेंट-प्रोवाइडर को टोकन के लिए जाते हैं।



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

संरक्षण स्तर

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

 <permission android:name="com.example.contentprovider.access" android:protectionLevel="signature"/> <application> <provider ... android:readPermission="com.example.contentprovider.access"> </application> 

योजना पिछले आंकड़े से शायद ही बदल जाएगी, केवल एक गारंटी दिखाई देगी कि केवल एक ही लेखक के हस्ताक्षर वाले आवेदन टोकन तक पहुंच प्राप्त करेंगे।

अनुमति दौड़ की स्थिति

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

अलग-अलग हस्ताक्षर

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

 String pkg = this.getCallingPackage(); PackageInfo pkgInfo = pkgmgr.getPackageInfo(pkg, GET_SIGNATURES); Signatures[] signatures = pkgInfo.signatures; for (Signature sig: signatures) { if (sig.equals(TRUSTED_SIGNATURE)) { // trusted signature found, trust the application } } 

ऐसा लगता है कि हमने सब कुछ पूरी तरह से किया, लेकिन नहीं।

नकली आईडी भेद्यता

समस्या यह है कि जब एंड्रॉइड चेन-ऑफ-ट्रस्ट बनाता है, तो सत्यापन प्रक्रिया केवल विषय की तुलना करती है, और प्रमाणपत्र के हस्ताक्षरकर्ता क्षेत्र में हस्ताक्षर का सत्यापन नहीं करती है। नतीजतन, एक हमलावर वास्तविक हस्ताक्षर के बिना चेन-ऑफ-ट्रस्ट का निर्माण कर सकता है।

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

निष्कर्ष

आज हमने जांच की कि विकास के दौरान सुविधाओं का विश्लेषण कैसे किया जाना चाहिए।
हमने दो अनुप्रयोगों के बीच रहस्य को स्थानांतरित करने के विकल्पों की भी जांच की, जिसके दौरान हमने प्रत्येक विकल्प की समस्याओं का विश्लेषण किया और उनसे बचने के तरीकों के साथ आए।

सभी सुरक्षित अनुप्रयोग!

संदर्भ

• नकली आईडी भेद्यता ठीक करें
• नकली आईडी भेद्यता प्रस्तुति
• CWE: सेशन फिक्सेशन