REST प्रमाणीकरण योजनाओं की सुरक्षा


228

पृष्ठभूमि:

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

ये SO प्रश्न मुझे शुरू करने के लिए विशेष रूप से उपयोगी थे:

मैं अमेज़ॅन S3 के प्रमाणीकरण के एक सरलीकृत संस्करण का उपयोग करने के बारे में सोच रहा हूं (मुझे OAuth पसंद है लेकिन यह मेरी आवश्यकताओं के लिए बहुत जटिल लगता है)। मैं फिर से खेलना हमलों को रोकने के लिए, सर्वर द्वारा आपूर्ति की गई एक बेतरतीब ढंग से उत्पन्न गैर- जोड़ रहा हूं ।

प्रश्न करने के लिए:

S3 और OAuth दोनों ही कुछ चयनित हेडर के साथ अनुरोध URL पर हस्ताक्षर करने पर निर्भर हैं। उनमें से कोई भी POST या PUT अनुरोधों के लिए अनुरोध निकाय पर हस्ताक्षर नहीं करता है। क्या यह एक मध्य-आक्रमण के लिए संवेदनशील नहीं है, जो url और हेडर रखता है और हमलावर शरीर को किसी भी डेटा के साथ अनुरोध बॉडी को बदलना चाहता है?

ऐसा लगता है कि मैं हस्ताक्षर किए गए स्ट्रिंग में अनुरोध निकाय के एक हैश को शामिल करके इसके खिलाफ रख सकता हूं। क्या यह सुरक्षित है?


6
अमेज़न S3 आपके द्वारा वर्णित MITM हमले को रोकने के लिए हेडर स्ट्रिंग के भाग के रूप में एक सामग्री-एमडी 5 शामिल कर सकता है।
लाज

8
MD5 एक बहुत कमजोर हैश फ़ंक्शन है और इसका उपयोग कई वर्षों से हतोत्साहित किया जाता है: en.wikipedia.org/wiki/MD5 । आजकल SHA2 का उपयोग करें। MD5 एक पहचान संकट के साथ एक सुअर पर लिपस्टिक है।
हेनरिक

6
स्टार्टकॉम मुफ्त एसएसएल प्रमाणपत्र प्रदान करता है जो प्रमुख ब्राउज़रों में प्रमाणपत्र चेतावनी नहीं फेंकते हैं
प्लेटो

5
@ सीनएकेंडरसन (शेख़ी: मुझे यह बेतुका लगता है कि कैसे लोग 99.99999% के बारे में बात करते हैं, जब इंटरनेट पर जासूसी करने वाली एजेंसियां ​​घेरे रहती हैं, जिन्होंने 2008 में पहले से ही बहुत सारे हमले किए हैं - यह एक वास्तविक मुद्दे से निपटने का एक ऐसा अजीब तरीका है - "नाहा, कोई समस्या नहीं होगी; क्योंकि मेरी दादी इसे हैक नहीं कर पाएगी"
हेनरिक

2
@Plato मैं इन दिनों फ्री एसएसएल
सीरियल्स के

जवाबों:


168

पिछले उत्तर में केवल डेटा ट्रांसफर के संदर्भ में एसएसएल का उल्लेख किया गया था और वास्तव में प्रमाणीकरण को कवर नहीं किया था।

आप वास्तव में सुरक्षित रूप से REST API क्लाइंट को प्रमाणित करने के बारे में पूछ रहे हैं। जब तक आप टीएलएस क्लाइंट प्रमाणीकरण का उपयोग कर रहे हैं, अकेले एसएसएल एक एपीआई के लिए व्यवहार्य प्रमाणीकरण तंत्र नहीं है। SSL बिना क्लाइंट ऑर्कुट केवल सर्वर को प्रमाणित करता है , जो अधिकांश REST API के लिए अप्रासंगिक है क्योंकि आप वास्तव में क्लाइंट को प्रमाणित करना चाहते हैं ।

यदि आप टीएलएस ग्राहक प्रमाणीकरण का उपयोग नहीं करते हैं, तो आपको एक डाइजेस्ट-आधारित प्रमाणीकरण योजना (जैसे अमेज़ॅन वेब सेवा की कस्टम योजना) या OAuth 1.0a या यहां तक ​​कि HTTP मूल प्रमाणीकरण (लेकिन केवल SSL पर) का उपयोग करने की आवश्यकता होगी।

ये योजनाएँ प्रमाणित करती हैं कि अनुरोध किसी ने अपेक्षित रूप से भेजा था। टीएलएस (एसएसएल) (क्लाइंट ऑथेंटिकेशन के बिना) यह सुनिश्चित करता है कि तार पर भेजा गया डेटा अपरिवर्तित रहे। वे अलग हैं - लेकिन पूरक - चिंताओं।

रुचि रखने वालों के लिए, मैंने HTTP प्रमाणीकरण योजनाओं के बारे में SO प्रश्न पर विस्तार किया है और वे कैसे काम करते हैं


16
बिल्कुल सही। जब तक आपके API का संबंध है SSL केवल एक चीज की पुष्टि करता है कि यह जिस कॉल के साथ काम कर रहा है वह एन मार्ग के साथ गड़बड़ नहीं हुई है। एपीआई को अभी भी पता नहीं है कि यह किससे बात कर रहा है या नहीं, उन्हें इसका उपयोग करना चाहिए या नहीं।
Ga में टिम गॉटियर

1
अच्छा उत्तर। मैं इन उत्कृष्ट संसाधनों पर एक नज़र डालने की भी सिफारिश करूँगा .. owasp.org/index.php/Web_Service_Security_Cheat_Sheet और owasp.org/index.php/REST_Security_heat_Sheet (DRAFT)
dodgy_coder

2
बस एक मामूली बात है, लेकिन एसएसएल का उपयोग करने से भी ईव्सड्रॉपिंग और मध्य हमलों में आदमी को रोकने का अतिरिक्त लाभ होता है।
dodgy_coder

@Les Hazlewood क्या आप बता सकते हैं कि Https पर HTTP बेसिक ऑथेंटिकेशन यह जानने में मदद कर सकता है कि सर्वर किससे बात कर रहा है?
वसंत

@Les Hazlewood यहाँ मैंने एक सवाल में यह पूछा; tnx stackoverflow.com/questions/14043397/…
स्प्रिंग

60

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

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

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

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

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

(कनेक्शन एसएसएल-केवल बनाने के निहितार्थ को कवर करने के लिए अद्यतन।)


3
मुझे लगता है कि एक वर्ष में $ 30 के लिए आपको GoDaddy ssl प्रमाणपत्र मिल सकता है। मुझे यह देखकर झटका लगा कि वेरिसाइन एसएसएल सेर्ट्स ($ 600 एक वर्ष या कुछ और अगर मुझे सही याद है?) के लिए जाना है, लेकिन GoDaddy विकल्प पूरी तरह से संभव है।
ब्रायन आर्मस्ट्रांग

19
जब तक आप एसएसएल / टीएलएस आपसी प्रमाणीकरण का उपयोग नहीं कर रहे हैं, और उपयोगकर्ता / ग्राहक द्वारा उपयोग किए जाने वाले प्रमाण सर्वर द्वारा भरोसा किया जाता है, तो आपने उपयोगकर्ता को सर्वर / एप्लिकेशन को प्रमाणित नहीं किया है। आपको सर्वर / एप्लिकेशन को उपयोगकर्ता को प्रमाणित करने के लिए कुछ और करने की आवश्यकता होगी।
पॉलड

5
रेयान: इन दिनों एसएसएल एन्क्रिप्शन एक बहुत छोटी मात्रा में प्रसंस्करण शक्ति लेता है, जिसकी तुलना में आप वेब ऐप फ्रेमवर्क जैसे कि जिंजो या रेल्स आदि के साथ प्रतिक्रिया उत्पन्न करने के लिए उपयोग करेंगे
कैमरन वाल्श

4
Startcom से certs स्वतंत्र और व्यापक रूप से मान्यता प्राप्त हैं। cacert.org कम मान्यता वाला एक खुला विकल्प है
दीमा टिस्नेक

17
यह प्रश्न को संबोधित नहीं करता है, जो प्रमाणीकरण के बारे में है।
सैम स्टेन्स्बी

8

या आप इस समस्या के ज्ञात समाधान का उपयोग कर सकते हैं और एसएसएल का उपयोग कर सकते हैं। स्व-हस्ताक्षरित सेरेक्ट स्वतंत्र हैं और इसकी एक व्यक्तिगत परियोजना सही है?


2
स्व-हस्ताक्षरित सेर स्वतंत्र हैं, लेकिन AFAIK आपको अभी भी एक स्थिर आईपी की आवश्यकता है।
डीएफ।

8
@dF को प्रमाणपत्रों के लिए वाणिज्यिक भुगतान की कुछ लाइसेंसिंग आवश्यकताओं को छोड़कर एक स्थिर आईपी होने की कोई आवश्यकता नहीं है।
क्रिस मैरिसिक

यदि आपके पास दोनों सिरों (क्लाइंट और सर्वर) पर सर्टिफिकेट स्टोर का नियंत्रण है, तो यह एक व्यवहार्य विकल्प हो सकता है लेकिन ... प्रमाणपत्र प्रबंधन और वितरण शायद एक विकास परिवेश की तुलना में उत्पादन में बहुत अधिक जटिल है। आने से पहले इस विकल्प की जटिलताओं को समझना सुनिश्चित करें।
Aled

5

यदि आपको URL में किसी एक पैरामीटर के रूप में शरीर के हैश की आवश्यकता है और उस URL पर एक निजी कुंजी के माध्यम से हस्ताक्षर किए गए हैं, तो एक मानव-मध्य हमला केवल उस सामग्री के साथ शरीर को बदलने में सक्षम होगा जो सामग्री उत्पन्न करेगा वही हैश। MD5 हैश मान के साथ कम से कम अब करना आसान है और जब SHA-1 टूट जाता है, तो ठीक है, आपको चित्र मिल जाएगा।

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


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

3

वास्तव में, मूल S3 प्रमाणन करता है सामग्री के लिए अनुमति देते हैं, पर हस्ताक्षर किया जाना एक कमजोर MD5 हस्ताक्षर के साथ यद्यपि। आप एचएमएसी में एक सामग्री-एमडी 5 हेडर (हस्ताक्षर किए जाने वाले स्ट्रिंग) सहित उनके वैकल्पिक अभ्यास को लागू कर सकते हैं।

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

उनकी नई v4 प्रमाणीकरण योजना अधिक सुरक्षित है।

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html


1

याद रखें कि आपके सुझाव क्लाइंट के लिए सर्वर के साथ संवाद करना कठिन बना देते हैं। उन्हें आपके अभिनव समाधान को समझने और तदनुसार डेटा को एन्क्रिप्ट करने की आवश्यकता है, यह मॉडल सार्वजनिक API के लिए इतना अच्छा नहीं है (जब तक कि आप amazon \ yahoo \ google .. नहीं हैं)।

वैसे भी, यदि आपको शरीर की सामग्री को एन्क्रिप्ट करना होगा तो मैं आपको मौजूदा मानकों और समाधानों की जांच करने का सुझाव दूंगा:

XML एन्क्रिप्शन (W3C मानक)

XML सुरक्षा

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.