2009-09-09 22 views
7

मैं एक ऐप विकसित कर रहा हूं जो एक्सएमएल आधारित एपीआई से जुड़ता है। मेरे पास सर्वर और ऐप दोनों पर नियंत्रण है - क्या कोई तरीका है कि मैं यह सुनिश्चित कर सकता हूं कि केवल मेरा ऐप एपीआई एक्सेस कर सके?आईफोन और सर्वर के बीच सुरक्षित संचार?

कोई उपयोगकर्ता प्रमाणीकरण नहीं है।

संपादित करें:

मुख्य चिंता यह है कि बॉट एक्सएमएल को स्कैन करके डेटा चोरी है।

कैसे इस बारे में:

मैं डिवाइस UDID के साथ एक सत्र का अनुरोध और मैं एक हाथ मिलाना कुंजी मिलता है।

<handshake>23354</handshake> 
इस स्ट्रिंग एक पासवर्ड दोनों सर्वर और एक सहमति एल्गोरिथ्म के अनुसार ग्राहक पर गणना की जाती है से

है कि मैं में 1 जोड़

के अब के लिए मान लीजिए (यह सिर्फ फिर से संगठित करने के लिए कठिन हो गया है) हैंडशेक कुंजी

password = 23354 

सभी एपीआई कॉल पर मैं यूडीआईडी ​​के साथ इस पासवर्ड को पास करता हूं। यह सर्वर को प्रत्येक सत्र को कॉल की एक निश्चित संख्या तक सीमित करने की अनुमति देगा, नहीं?

आपको क्या लगता है?

उत्तर

2

आप एक त्वरित चुनौती प्रतिक्रिया तंत्र प्रदान कर सकते हैं, मानते हैं कि आपके पास XML एपीआई पर नियंत्रण है।

एक संख्या उत्पन्न करें और इसे अपने ऐप में और सर्वर की तरफ शामिल करें। क्लाइंट और सर्वर दोनों पर srand() के लिए बीज के रूप में उपयोग करें।

<handshake id="123">12312931</handshake> 

वहाँ आईडी का मतलब 123'rd यादृच्छिक संख्या उत्पन्न और 12,312,931 रैंड बुला() 123 बार के बाद मूल्य है:

ग्राहक से अनुरोध की तरह कुछ शामिल है। मूल्य 123 एक यादृच्छिक रूप से जेनरेट किया गया नंबर होना चाहिए (एक अलग बीज के साथ उत्पन्न!) भी।

यह मूर्ख प्रमाण चुनौती प्रतिक्रिया नहीं है, लेकिन यह सरल और कुशल है, और मूल एएनएसआई सी लाइब्रेरी सेट से अधिक कुछ भी भरोसा नहीं करता है।

ध्यान दें कि यह बहुत सुरक्षित नहीं है, या तो सभी को यह करना होगा कि आपका ग्राहक अपने सर्वर को चुनौती दे, तो इस बीज में प्रत्येक बीज मूल्य के लिए यादृच्छिक संख्या (उदाहरण के लिए) 123'rd यादृच्छिक संख्या उत्पन्न करें। इसलिए मैं इसे क्रिप्टोग्राफिक स्तर प्रमाणीकरण या अभिगम नियंत्रण प्रदान करने की अपेक्षा नहीं करता। यह सिर्फ एक सरल गैर-तुच्छ चुनौती प्रतिक्रिया प्रदान करता है जो कार्यान्वित करने के लिए कुशल और सरल है।

+0

मुझे विश्वास नहीं है कि रैंड() द्वारा अनुक्रमित अनुक्रम प्लेटफ़ॉर्म से प्लेटफ़ॉर्म तक समान होता है। POSIX वास्तविक एल्गोरिदम को परिभाषित नहीं करता है, केवल न्यूनतम आवश्यकताओं। मैं उपरोक्त में मानता हूं कि सर्वर "123" चुनता है। यदि ग्राहक इसे चुनता है, तो यह बिल्कुल भी सुरक्षा प्रदान नहीं करता है (यहां तक ​​कि छोटी सुरक्षा भी नहीं)। यदि सर्वर आईडी भेजता है, तो 64k बीज के लिए सभी मानों की गणना करने से तेज़ ब्रेक होते हैं। सत्र के एमआईएम के लिए सबसे स्पष्ट है। मैं कुछ टकरावों के लिए आईडी = 1 के साथ क्लाइंट को चुनौती देकर बीज को और अधिक तेज़ी से पा सकता हूं। –

0

प्रमाणीकरण के साथ https के माध्यम से अपनी वेब सेवा तक पहुंचें।

+0

हाँ, लेकिन कैसे? आईफोन पर इसे समझने की कोशिश कर रहा है। इसके लिए आप किस कक्षा का उपयोग कर रहे हैं? – Spanky

3

नहीं, वास्तव में यह सुनिश्चित करना संभव नहीं है कि केवल आपका ऐप आपके सर्वर से संपर्क कर सके। हमलावरों पर कुछ हद तक बार बढ़ाने के लिए obfuscation तकनीकें हैं, और वे अधिकतर हमलावरों के लिए काम करेंगे। आपकी अंतर्निहित समस्या एक समर्पित हमलावर के लिए हल करने योग्य नहीं है। आप iPhone: How to encrypt a string पर इस विषय पर अन्य पोस्ट की एक सूची पा सकते हैं। ऐसी कई तकनीकें हैं जिनका आप उन पदों में उपयोग कर सकते हैं, और कुछ चर्चाएं कि कैसे अंतर्निहित मुद्दों पर हमला करना चाहिए या नहीं।

1

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

+0

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

-2

मुझे लगता है कि वास्तविक प्रश्न पूछने की आवश्यकता है कि हमले के जोखिम पर आपका डेटा कितना है। मैं कहूंगा कि 99% समय आप ठीक से एक obfuscated यूआरएल के साथ ठीक हो जाएगा, अनुमान लगाना मुश्किल होगा, क्योंकि औसत ऐप आपके ऐप के बाहर कुछ भी करने की कोशिश कर रहा है। यदि आप प्रतिस्पर्धा करने वाले प्रतियोगियों के बारे में चिंतित हैं, तो मैं कुछ और अधिक घृणास्पद सुझाव दूंगा:

अपने ऐप में, इसे सेट अप करें ताकि आपका ऐप और सर्वर हर दो सप्ताह में हर बार यूआरएल बदल सके। फिर यदि कोई आपके एक्सएमएल एपीआई तक पहुंचने का प्रयास करता है, तो वे आपके यूआरएल को समझने की निरंतर लड़ाई लड़ेंगे। और केक पर टुकड़े करने के रूप में, पुराने यूआरएल सक्रिय रखें लेकिन उन्हें खराब डेटा वापस कर दें। मुझे लगता है कि आप अपनी कल्पना को चलाने और यहां से बाकी को समझने दे सकते हैं।

+0

ऐप कैसे निर्धारित करता है कि सही यूआरएल क्या होगा? जो भी तकनीक इसका उपयोग करती है उसे किसी भी व्यक्ति द्वारा डुप्लिकेट किया जा सकता है जो ऐप को इंजीनियरों को उलट देता है। इसी तरह, वैध ऐप के ट्रैफ़िक को आसानी से छीनने से दुष्ट एप्लिकेशन को कनेक्ट किया जाएगा। यह समाधान वैध उपयोगकर्ताओं को प्रभावित किए बिना कार्यान्वित करने के लिए जटिल है (जो प्रत्येक संक्रमण के दौरान परेशानी हो सकती है), लेकिन साझा रहस्य का एक और संस्करण है, सिवाय इसके कि यह गुप्त तार पर भी एन्क्रिप्ट नहीं किया गया है (क्योंकि यूआरएल नहीं हो सकता है) । –

+0

यह एक सहायक उत्तर नहीं है क्योंकि यह उनके प्रश्न का उत्तर नहीं देता है। साथ ही, आप जो भी सुझाव देते हैं उसके लिए आप कोई वास्तविक तंत्र प्रदान नहीं करते हैं। – Ryan

संबंधित मुद्दे