यूनिवर्सल इन-ऐप खरीदारी हैक के खिलाफ सुरक्षा

नीचे वर्णित सुरक्षा पद्धति को हैक किया गया था, इस पोस्ट की निरंतरता पढ़ें: हैकिंग इन-ऐप खरीदारी के खिलाफ सुरक्षा। भाग २

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

इन-ऐप खरीदारी कैसे काम करती है

दो संभावित परिदृश्य हैं। सरल:

डेवलपर सर्वर के अतिरिक्त सत्यापन और भागीदारी के बिना डिवाइस ऐप्पल सर्वर के माध्यम से खरीद को सक्रिय करता है।

परिष्कृत:

डेवलपर सर्वर खरीद प्रक्रिया में इस प्रकार भाग ले सकता है:

• संभावित खरीद की सूची भेजता है (चरण 2),
• पोके चेक को सत्यापित करता है (चरण 10-11),
• कुछ अतिरिक्त सामग्री (चरण 13-14) तक पहुँच प्रदान करता है।

हम 10-11 चरणों में रुचि रखते हैं, क्योंकि यह उन पर है कि हम डिवाइस को यह निर्धारित करने में मदद कर सकते हैं कि चेक ऐप्पल सर्वर द्वारा लिखा गया था या यह नकली है।

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

मान्यता

हम केवल Apple सर्वर पर खरीद रसीद को मान्य कर सकते हैं। ऐसा करने के लिए, JSON को HTTP POST अनुरोध के अंदर बेस 64 में एनकोडेड चेक के साथ भेजें:
{
"receipt-data" : "(receipt bytes here)"
}

Apple सर्वरों में से एक:

• sandbox.itunes.apple.com/verifyReceipt - सैंडबॉक्स से परीक्षण खरीद के लिए
• buy.itunes.apple.com/verifyReceipt - AppStore से खरीदारी के लिए।

प्रतिक्रिया में, सर्वर सत्यापन स्थिति लौटाएगा, और यदि सत्यापन सफल होता है, तो चेक के डीकोड किए गए फ़ील्ड:
{
"status" : 0,
"receipt" : { (receipt here) }
}


सिद्धांत से अभ्यास तक

ऊपर वर्णित यांत्रिकी को समझना, रूबी में एक प्रॉक्सी एप्लिकेशन लिखना मुश्किल नहीं था, जो कि ऐप्पल सर्वरों में से एक के लिए सत्यापन अनुरोधों को आगे बढ़ाता है। मैंने GitHub पर रेडी-टू- यूज़ एप्लिकेशन कोड पोस्ट किया। मुझे सुधार करने और अनुरोध करने में खुशी होगी। आप इसे heroku पर भी छू सकते हैं: https://receiptValidator.heroku.com/validate , रिपॉजिटरी से टेस्ट चेक का उपयोग करते हुए। चेकबॉक्स सैंडबॉक्स के साथ आप सही उत्तर देख सकते हैं, और इसके बिना, त्रुटि कोड।

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

सूखा परिणाम

• अपने सर्वर के माध्यम से खरीद की वैधता आवेदन "विशेष" बनाता है और सार्वभौमिक पटाखे काम करना बंद कर देते हैं।
• एप्लिकेशन हैक करना अभी भी संभव है, लेकिन इसके लिए हमारे आवेदन को तोड़ना आवश्यक है।
• यदि कोई समय व्यतीत करता है और खरीदारी करता है - तो आप हमारे सर्वर के साथ संचार में अतिरिक्त एन्क्रिप्शन जोड़ सकते हैं।
• हरको पर मुफ्त में हमें सुविधाजनक रूबी होस्टिंग और https एन्क्रिप्शन मिलता है।

PS बेईमान स्व-पीआर का एक सा: यह बचाव विशेष रूप से गैलीलियो ऑफ़लाइन मैप्स के लिए लिखा गया था और संस्करण 2.2 में सफलतापूर्वक परीक्षण किया गया था, जो कल सुबह AppStore में दिखाई दिया।