🚮 👨🏿‍🚒 🥑 IOS प्लेटफ़ॉर्म पर नेटवर्क अनुरोधों को कैशिंग करते समय गोपनीय डेटा लीक ❤️ 👨🏽‍⚖️ ⛱️

उपयोगकर्ता डेटा की सूचना सुरक्षा के संदर्भ में एक महत्वपूर्ण पहलू वेब सेवाओं के साथ संरक्षित एप्लिकेशन के इंटरैक्शन के दौरान प्रेषित डेटा की गोपनीयता है। उदाहरण के लिए, बैंक कार्ड नंबर और CVV2 / CVC2 प्रमाणीकरण कोड में हेरफेर करने वाले अनुप्रयोगों में गोपनीयता की हानि एक महत्वपूर्ण भेद्यता लगती है। IOS मोबाइल प्लेटफ़ॉर्म के लिए सुरक्षित एप्लिकेशन विकसित करते समय, सामान्य गलतियों में से एक, संचारित डेटा की गोपनीयता का आंशिक या पूर्ण नुकसान के लिए अग्रणी, इंटरनेट अनुरोधों की अत्यधिक कैशिंग है।

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

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

लड़ाई की परीक्षा

इंटरनेट अनुरोध कैश के दुरुपयोग के एक उदाहरण पर विचार करें। सुरक्षा विश्लेषण के संदर्भ में परिशिष्ट बी के अध्ययन के परिणामस्वरूप, यह पाया गया कि एप्लिकेशन कैश HTTP अनुरोधों को मुख्य वेब सेवा के साथ बातचीत के हिस्से के रूप में किया जाता है। इंटरनेट अनुरोध स्थानीय SQLite डेटाबेस में अनुप्रयोग के घर निर्देशिका में रिश्तेदार पते लाइब्रेरी / कैश / <application.c> / Cache.db में संग्रहीत किए जाते हैं। डेटाबेस स्कीमा नीचे दिया गया है।

डेटाबेस स्कीमा

CREATE TABLE cfurl_cache_schema_version(schema_version INTEGER); CREATE TABLE cfurl_cache_response(entry_ID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE, version INTEGER, hash_value INTEGER, storage_policy INTEGER, request_key TEXT UNIQUE, time_stamp NOT NULL DEFAULT CURRENT_TIMESTAMP); CREATE TABLE cfurl_cache_blob_data(entry_ID INTEGER PRIMARY KEY, response_object BLOB, request_object BLOB, proto_props BLOB, user_info BLOB); CREATE TABLE cfurl_cache_receiver_data(entry_ID INTEGER PRIMARY KEY, receiver_data BLOB); CREATE INDEX request_key_index ON cfurl_cache_response(request_key); CREATE INDEX time_stamp_index ON cfurl_cache_response(time_stamp); CREATE INDEX proto_props_index ON cfurl_cache_blob_data(entry_ID); CREATE INDEX receiver_data_index ON cfurl_cache_receiver_data(entry_ID);

Cfurl_cache_response डेटाबेस तालिका का request_key कॉलम यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) को संग्रहीत करता है, जो कि HTTPS अनुरोधों सहित एक्सेस का अनुरोध करता है। इस तरह के अनुरोधों में उपयोगकर्ता प्रमाणीकरण डेटा सहित उपयोगकर्ता गोपनीय डेटा शामिल हो सकते हैं। उदाहरण के लिए, एप्लिकेशन B एक वेब सेवा के साथ बातचीत करने के लिए एक अर्ध-प्रतिष्ठित इंटरफ़ेस का उपयोग करता है और उपयोगकर्ता को अधिकृत करने के लिए एक GET अनुरोध करता है।

 sqlite> select request_key from cfurl_cache_response; ... https://example.com/api/1.0/auth?login=Selma_Nagel&password=qwerty ...

Cfurl_cache_receiver_data डेटाबेस टेबल का रिसीवर_डेटा सर्वर HTTPS प्रोटोकॉल पर अनुरोध सहित एप्लिकेशन द्वारा प्राप्त सर्वर प्रतिक्रियाओं को संग्रहीत करता है। तो, परिशिष्ट B में, बैंक कार्ड का उपयोग करने वाली सेवाओं के लिए भुगतान का एक वेब रूप उपयोग किया जाता है।

 sqlite> select receiver_data from cfurl_cache_receiver_data; ... <input data-val="true" ...="" id="CardNumber" name="CardNumber" type="hidden" value="1231 1231 1231 1234"> <input data-val="true" ...="" id="CardCode" name="CardCode" type="hidden" value="321"> ...

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

यह कैसे संभव हुआ?

NSURLCache वर्ग की एक वस्तु, + SHARURLCache विधि के माध्यम से सुलभ, NSURLConnection वर्ग की वस्तुओं द्वारा किए गए मोबाइल एप्लिकेशन के ढांचे के भीतर इंटरनेटवर्क अनुरोधों को कैशिंग करने के लिए जिम्मेदार है। NSURLCache वर्ग की वस्तुओं में दो पैरामीटर होते हैं जो गतिशील मेमोरी (इन-मेमोरी कैश) और स्टोरेज डिवाइस (ऑन-डिस्क कैश) में कंटेनर की मात्रा को नियंत्रित करते हैं। आधिकारिक प्रलेखन में NSURLCache वर्ग के बारे में अधिक पढ़ें।

IOS v4.x और लोअर ऑपरेटिंग सिस्टम पर, स्टोरेज डिवाइस पर इंटरनेट रिक्वेस्ट का कोई कैशिंग नहीं था, और डिस्क कैपासिटी क्लास के पैरामीटर को नजरअंदाज कर दिया गया था। 5 और ऊपर के iOS संस्करणों के साथ शुरू, डिफ़ॉल्ट रूप से एप्लिकेशन 20 एमबी की क्षमता तक सीमित मोबाइल डिवाइस की हार्ड ड्राइव पर एक HTTP अनुरोध कैश बनाता है। और iOS के 6 वें संस्करण के बाद से, HTTPS प्रोटोकॉल के माध्यम से कैशिंग अनुरोधों का समर्थन लागू किया गया है।

यह उल्लेख करने के लिए सार्थक है कि आईओएस प्लेटफॉर्म के लिए सभी मोबाइल एप्लिकेशन जो स्पष्ट रूप से या अंतर्निहित रूप से NSURLConnection का उपयोग करते हुए अंतर-कार्यकारी अनुरोध करते हैं, असुरक्षित हैं। विशेष रूप से, लोकप्रिय AFNetworking पुस्तकालय के फ़ायरवॉल कक्षाएं NSURLConnection पर आवरण हैं। इसलिए, AFNetworking का उपयोग करने वाले मोबाइल एप्लिकेशन भी संभावित रूप से असुरक्षित हैं।

कैसे करें आवेदन की सुरक्षा?

अनुरोधों के कैशिंग से बचाने के लिए सबसे आसान तरीका जिसमें संवेदनशील जानकारी शामिल है, साझाकरण विधि को 0 पर साझा करना है।

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { ... [[NSURLCache sharedURLCache] setDiskCapacity:0]; ... }

प्रतिनिधियों का उपयोग करना इस तरह किया जा सकता है।

 - (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse { /* Implement cacheing logic here. */ return nil; // HACK: just do not cache }

कैश-कंट्रोल के साथ बढ़िया धुन

ऊपर वर्णित समाधानों को सुरुचिपूर्ण (सबसे अधिक संभावना है कि दूसरे तरीके से) कहा जाता है। वे एप्लिकेशन के तर्क को जल्दी से ठीक करने के लिए उपयुक्त हैं, हालांकि, वेब सेवा के साथ क्लाइंट एप्लिकेशन के इंटरैक्शन को ठीक करने के लिए, हम सर्वर साइड पर कैशिंग अनुरोधों के लिए नीति में बदलाव का सहारा ले सकते हैं। कैशिंग-नियंत्रण HTTP हेडर ( RFC 2616 ) में कैशिंग नीति सेट की गई है।

वेब संसाधनों की कैशिंग की नीति के आधार पर NSURLCache के व्यवहार को प्रदर्शित करने के लिए, हमने iOS मोबाइल प्लेटफॉर्म के लिए एक सरल एप्लिकेशन संकलित किया है। IOS SDK v7.0 पैकेज का उपयोग किया गया था, और एप्लिकेशन को डिवाइस सिम्युलेटर पर लॉन्च किया गया था।

अंजीर। 1. परीक्षण आवेदन का काम

हमारे छोटे अनुसंधान के परिणाम तालिका 1 में दिए गए हैं। ध्यान दें कि लोकप्रिय विश्वास के विपरीत, एप्लिकेशन कैश-कंट्रोल हेडर वैल्यू सेट के बिना भी इंटरनेट अनुरोधों को कैश करता है।

संसाधन	कैश कंट्रोल	कैश की गई
/ htbin / श्री	आवश्यक पुनः सत्यापित	हां
/ htbin / nocache	कोई कैश	हां
/ एचटीबीएन / नॉस्टोर	कोई दुकान	नहीं
/ htbin / निजी	निजी	हां
/ htbin / सार्वजनिक	सार्वजनिक	हां
/ htbin / woheader	निर्दिष्ट नहीं है	हां
/ htbin / निहित	अधिकतम आयु = 604800	हां

टेबल। 1. कैशे-नियंत्रण के आधार पर डिस्क पर कैशिंग अनुरोध

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

आरएफसी 2616, खंड 14.9.2

14.9.2 क्या कैश द्वारा संग्रहीत किया जा सकता है

कोई दुकान

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

यहां तक कि जब यह निर्देश एक प्रतिक्रिया के साथ जुड़ा हुआ है, तो उपयोगकर्ता कैशिंग सिस्टम के बाहर ऐसी प्रतिक्रिया को स्पष्ट रूप से संग्रहीत कर सकते हैं (उदाहरण के लिए, "सेव अस" संवाद के साथ)। इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं।

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

निष्कर्ष

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

निजी कंप्यूटर पर चलने वाले दुर्भावनापूर्ण एप्लिकेशन डिस्क कैश से डेटा निकाल सकते हैं जब आप iOS को व्यक्तिगत कंप्यूटर से चलाने वाले डिवाइस को कनेक्ट करते हैं। यह पीड़ित के कंप्यूटर पर एक ट्रोजन हो सकता है, या हमलावर के कंप्यूटर पर एक विशेष कार्यक्रम हो सकता है, बशर्ते कि बाद वाले को थोड़े समय के लिए डिवाइस तक भौतिक पहुंच प्राप्त हो।

आवेदन स्तर पर, यह संभावित भेद्यता NSURLConnection बनाते समय स्थानीय कैशिंग को स्पष्ट रूप से प्रतिबंधित करके बंद कर दिया जाता है। सर्वर स्तर पर, गोपनीय डेटा वाले सभी अनुरोधों के लिए सर्वर प्रतिक्रियाओं के HTTP हेडर में कैशिंग के निषेध को इंगित करके इस संभावित भेद्यता को बंद किया जाना चाहिए।

IOS प्लेटफ़ॉर्म पर नेटवर्क अनुरोधों को कैशिंग करते समय गोपनीय डेटा लीक

लड़ाई की परीक्षा

यह कैसे संभव हुआ?

कैसे करें आवेदन की सुरक्षा?

कैश-कंट्रोल के साथ बढ़िया धुन

निष्कर्ष

More articles: