2012-02-21 14 views
6

सुरक्षित करने के लिए पर्याप्त हैं I API को सुरक्षित करने का सबसे अच्छा तरीका जानने का प्रयास कर रहा हूं। मैं केवल एसएसएल की अनुमति देता हूं और मैं प्रमाणीकरण के लिए OAuth2 का उपयोग कर रहा हूं, लेकिन यह पर्याप्त प्रतीत नहीं होता है।ओएथ 2 और एसएसएल एपीआई

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

क्या इसे रोकने के लिए कोई तरीका है? मैंने लोगों को केवल क्लाइंट और सर्वर के लिए जाने वाली एक गुप्त कुंजी का उपयोग करके पैरामीटर के एचएमएसी हैश का उपयोग किया है, लेकिन मुझे इसके साथ 2 समस्याएं दिखाई देती हैं।

  1. दुर्भावनापूर्ण उपयोगकर्ता को आपके ग्राहक को अपनाने और गुप्त कुंजी को समझने से रोकने के लिए यह बहुत मुश्किल (असंभव?) है।
  2. कुछ पैरामीटर एचएमएसी हैश बनाने के लिए अजीब लगते हैं। उदाहरण के लिए यदि कोई पैरामीटर फ़ाइल के बाइट्स था, तो क्या आप अपनी एचएमएसी हैश में पूरी चीज शामिल करते हैं?

उत्तर

4

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

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

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

1

क्या आप एसएसएल पर ओएथ प्रमाणीकरण चरण चला रहे हैं? इससे सभी प्रकार के स्नूपिंग को रोक दिया जाता है, हालांकि इसका मतलब यह है कि आपको अपने ओथ सर्वर के प्रमाणपत्र को अद्यतित रखने के लिए सावधान रहना होगा। (ध्यान दें, OAuth सर्वर एक सार्वजनिक एसएसएल पहचान हो सकता है, यह अभी भी प्रयास का भी थोड़ा-उचित मात्रा के साथ बनाने के लिए असंभव है यह केवल निजी कुंजी गुप्त रखा होने की जरूरत है है।।)

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

+0

ओएथ चरण एसएसएल से अधिक है। मैं एक एपीआई की रक्षा करने की कोशिश कर रहा हूं जिसे उपयोगकर्ता मशीन पर चल रहे कई अलग-अलग ग्राहकों द्वारा बुलाया जाएगा। OAuth प्रवाह से प्राप्त ऑथ कोड अनुरोध के प्राधिकरण शीर्षलेख में सभी API कॉलों को पास किया जाता है। कोड को तब सर्वर पर सत्यापित किया जाता है। – Evan

+1

यह ओएथ 2 है, इसे एसएसएल से अधिक होना चाहिए। –

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