2013-01-12 17 views
7

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

उत्तर

2
@ Vlatko की प्रतिक्रिया पर विस्तार से चर्चा करते

...

(या किसी अन्य OAuth2 अनुदान के माध्यम से) टुकड़ा में टोकन भेजने के जोखिम को कम करने के लिए:

  • सुनिश्चित करना है कि OAuth endpoint और कॉलबैक अंत बिंदु हैं टीएलएस (https)
  • (countermeasures देखें) एक state parameter भेज क्रॉस साइट जालसाजी रोकने के लिए (यह भी देखें: http://tools.ietf.org/html/rfc6749#section-4.2.1)

अल्पकालिक पहुंच टोकन जारी करना (जैसा कि @vlatko ने कहा) एक लीक टोकन के प्रभाव को कम करेगा, लेकिन एक निवारक उपाय नहीं है।

+1

सूंघना यहां तक ​​कि जब पहुँच टोकन https के माध्यम से भेजा जाता है, क्योंकि यह एक टुकड़ा है, नेटवर्क में इंटरमीडिएट हॉप सर्वर के लिए इसे स्नीफ करना संभव नहीं होगा। – Karthik

+0

क्या आपका मतलब है कि यह http के माध्यम से भेजा गया हो? – codeprogression

+0

यदि हम ओथ सर्वर को एक्स के रूप में मानते हैं, और क्लाइंट वाई के रूप में पहुंच का अनुरोध करता है। फिर भी जब टोकन तक पहुंच को https में विभाजित किया जाता है, एक्स से वाई तक, www नेटवर्क में इंटरमीडिएट मशीन एक्स से वाई तक इस एक्सेस टोकन को पढ़ सकते हैं (यानी: https क्वेरी पैरा/खंडों पर सहेजना, http क्वेरी पैरा/खंडों को सहेजना जितना आसान है)। Https के मामले में केवल HTTP निकाय में डेटा एन्क्रिप्ट किया गया है। – Karthik

2

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

अतिरिक्त सुरक्षा उपायों भी हैं, जैसे कि निहित अनुदान प्रवाह में केवल अल्पकालिक पहुंच टोकन जारी करना।

OAuth2 threat models document में अधिक जानकारी।

+0

यहां तक ​​कि जब पहुँच टोकन https के माध्यम से भेजा जाता है, इसकी एक टुकड़ा के बाद से, यह नेटवर्क में मध्यवर्ती हॉप सर्वर के लिए संभव नहीं होगा यह – Karthik

5

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

http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/

+0

vlatko - आप यह कहने के लिए सही हैं कि यूआरआई टुकड़े में कुछ विशेष गुण हैं और इसलिए मेरी उपरोक्त टिप्पणियों को सख्ती से बोलना लागू नहीं होता है। हालांकि, यह संदेश एक्सचेंज का एक बहुत नाजुक पहलू है - आप सचमुच प्रवाह की रक्षा के लिए ब्राउज़र के एक विशिष्ट व्यवहार के आधार पर हैं (यह एक यूआरआई के खंडन घटक को फिर से छोड़ देता है)।यदि यूआरआई टुकड़ा कुछ जगह उठाया जाता है तो यह हमलावर के लिए बहु-प्रयोग टोकन उत्पन्न करता है। – user3101375

+0

आप पूरी तरह से सही हैं। परिभाषा के अनुसार इस प्रकार का प्रमाणीकरण असुरक्षित है। –

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