OAuth2 सुरक्षा

हब्र पर यह ब्लॉग प्रविष्टि मुख्य रूप से "कीमास्टर" की उपस्थिति के कारण है - संचित को जोड़ने और स्थानांतरित करने का एक अच्छा कारण।


हम अपने कार्यक्रम में हैं: OAuth2 कल्पना, कमजोरियों और धमकी मॉडल की नि: शुल्क पुनर्प्राप्ति, प्रमाणीकरण के साथ हब चाल पर 0day ।

OAuth2 बस है

इसे सीखने का एक लंबा लेकिन सही तरीका है।
आलसी के लिए, मैं अपने स्वयं के शब्दों में वर्णन करूंगा प्राधिकरण कोड फ्लो सबसे आम और सुरक्षित, उर्फ सर्वर-साइड ।

मुख्य अवधारणाएँ क्लाइंट (वेबसाइट / ऑनलाइन गेम / ऐप), उपयोगकर्ता (आप), प्रदाता (फेसबुक / vkontakte / google), कोड (कोड) और टोकन (access_token) हैं।

क्लाइंट उपयोगकर्ता को भेजता है - "मुझे अपने संसाधनों तक पहुंचने के लिए अधिकृत करें।" उपयोगकर्ता प्रदाता के लिंक का अनुसरण करता है, यह देखता है कि उसके लिए क्या आवश्यक है - गुंजाइश पैरामीटर - क्लिक करें अनुमति दें। इसके अलावा, प्रदाता इसे निम्नलिखित मानकों के साथ क्लाइंट के डोमेन पर निर्दिष्ट पुनर्निर्देशन पर वापस भेज देता है:
कोड - प्रदाता पर उपयोगकर्ता की पहचानकर्ता, जिसे ग्राहक को टोकन प्राप्त करने की आवश्यकता है
स्थिति - वही मान जो स्टार्ट URL में दिया गया है। सीएसआरएफ के खिलाफ सुरक्षा के लिए और सुविधा के लिए उपयोग किया जाता है।

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

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

धमकी मॉडल या मुझे पता है कि आप के बारे में क्या सोचते हैं

OAuth को सुरक्षित रूप से उपयोग करने का एक लंबा लेकिन सही तरीका है।
यहाँ मैं ध्यान दें:

1. और क्या होगा यदि मैं एक रीडायरेक्ट_यूरी को प्रतिस्थापित करता हूं जो मेरी साइट तक ले जाएगा और फिर प्रमाणीकरण के लिए खुद इस कोड का उपयोग करेगा?

सभी रीडायरेक्ट_यूरी क्लाइंट के डोमेन पर होने चाहिए। अक्सर, एक अन्य प्रदाता डोमेन की अनुमति है। आपका लिंक redirect_uri_mismatch वापस आ जाएगा।

2. ठीक है। लेकिन क्या होगा अगर मुझे क्लाइंट की वेबसाइट पर एक जगह मिल जाए जो मेरा कोड मर्ज कर दे? हो सकता है कि फॉर्म site.com की एक पुनर्निर्देशित।

प्रत्येक कोड को रीडायरेक्ट_यूरी से जोड़ा जाता है, जिसके लिए इसे जारी किया गया था, और टोकन प्राप्त करने के लिए, क्लाइंट "सही" रीडायरेक्ट_यूरी भेजता है। यदि आपका कोड clientite.com/leak_referer के लिए जारी किया गया था और ग्राहक Token की रसीद पर clientsite.com/facebook_callback भेजता है , तो प्रदाता टोकन नहीं देगा।

3. क्या किसी तरह सही रीडायरेक्ट_यूरी पास करके कोड को मर्ज करना संभव है?

नहीं, क्योंकि कोड प्राप्त करने के बाद क्लाइंट के किसी भी सही कार्यान्वयन को तुरंत दूसरे पृष्ठ पर भेजना चाहिए - इसलिए कोड ब्राउज़र इतिहास में भी दिखाई नहीं देता है।
यहां तक ​​कि अगर आप सही redirect_uri के लिए कोड प्राप्त करने में कामयाब रहे तो भी एक बार सक्रिय होने के बाद इसका उपयोग पहले ही किया जा चुका है।

मान लीजिए कि मेरे पास सही रीडायरेक्ट_यूरी के लिए जारी किए गए सोशल नेटवर्क पर मेरे खाते के लिए एक कोड है। अगर मैं वासिया को इस लिंक पर जाऊं तो क्या होगा?

इस मामले में, क्लाइंट की वेबसाइट यह सोचेगी कि सोशल नेटवर्क में आपका खाता वस्या का है। और इसे कनेक्ट करें। एक सामान्य CSRF को होने से रोकने के लिए, क्लाइंट को सत्र / कुकी में यादृच्छिक राज्य मान को बचाने और रिटर्न कॉलबैक के अनुपालन की जांच करने की आवश्यकता होती है। हालांकि, लगभग कोई भी ऐसा नहीं करता है (या बल्कि नहीं)।

वास्तविकता

एफबी जवाब हमला

फेसबुक कनेक्ट क्लासिक रिप्ले हमले के लिए असुरक्षित है ।
प्वाइंट 3 दर्शाता है - कोड के एक उपयोग के बाद, यह अभी भी 60-80 मिनट के भीतर प्रमाणीकरण के लिए इस्तेमाल किया जा सकता है - टोकन का मानक एक्सपायर_इन। फिर से खेलना अपने शुद्धतम रूप में हमला।
मान लें कि हमने XSS को साइट पर पाया है - इस इंजेक्शन की तरह कुछ डॉक्यूमेंट के साथ सही रीडायरेक्ट_यूरी के लिए कोड प्राप्त करने में मदद करेगा।


रिपोर्ट हो गई है, वे जल्द ही इसे ठीक कर लेंगे। खैर, जल्द ही, लगभग तीन महीने, उद्यम

अपहरण का खाता

सबसे आम भेद्यता, उदाहरण के लिए, हब पर मौजूद है - उस पर अधिक। बिंदु 4 का उल्लंघन किया जाता है।
यदि आप अनुरोध में राज्य देखते हैं, तो देने के लिए जल्दी मत करो। क्या हब्र कि digg.com ने a12b6467c3fb385e237109502277ab26 और heyman0day123123 के बीच अंतर नहीं देखा

वीके रिडायरेक्ट_यूरी

कार्यान्वयन कुछ प्राचीन पांडुलिपियों के अनुसार किया गया था - सत्यापन की कमी जिसके लिए कोड को पुनर्निर्देशित किया गया था, अनुच्छेद 3 का घोर उल्लंघन है।
देखो, यहाँ लिंक है। प्रेस, डरो मत, और नेटवर्क पैनल खोलें। अनुरोध देखें?

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

विविध

यदि आप Implicit Flow का उपयोग कर रहे हैं - अर्थात यदि आपको सीधे उपयोगकर्ता से access_token मिलता है, तो इस बात की कोई गारंटी नहीं है कि यह टोकन वर्तमान उपयोगकर्ता का है। वह केवल एक दुर्भावनापूर्ण क्लाइंट के माध्यम से इसे चुरा सकता है, और इसे आपकी साइट पर कुछ उपयोगकर्ता के खाते में लाने के लिए उपयोग कर सकता है।
यह जांचना सुनिश्चित करें कि क्या यह टोकन आपके client_id के लिए जारी किया गया है।

इसके अलावा, OAuth2 इस बात की कोई गारंटी नहीं देता है कि उपयोगकर्ता ने आपको अनुमति दी थी जो आपने स्कोप पैरामीटर में प्राधिकरण चरण में अनुरोध किया था। वह बस उन्हें हटा सकता है - अंत में, आपको कॉलबैक पर जांच करनी चाहिए कि क्या उसने आपके द्वारा अनुरोध की गई अनुमति दी है।

यदि XSS साइट पर पाया जाता है, तो access_token-s का एक गुच्छा चोरी करने का एक आसान तरीका है। साइट को फेसबुक के लिए उपयोग करने वाले अधिकृत URL को लें और टोकन के साथ response_type = कोड बदलें। यह इस URL को फ्रेम में सम्मिलित करने के लिए बना हुआ है, टोकन के लिंक के लिए प्रतीक्षा करने के लिए फॉर्म कॉलबैक # access_token = 123 के लिंक पर लौटें, टोकन को काटें और इसे मर्ज करें। स्वास्थ्य पर स्पैम!

0 एक प्रभामंडल पर

वही शोषण फेसबुक / गूगल के लिए काम करता है; इसका उपयोग किए बिना कोड के साथ रीडायरेक्ट_यूरी प्राप्त करना केवल कठिन है - आपको NoRedirect + FF की आवश्यकता है
इसलिए, वीके पर डेमो। चाचा ने स्नान नहीं किया UPD: भेद्यता तय हो गई थी ।

1. आपके पास संलग्न वीके नहीं होना चाहिए। लॉग इन करें oauth.vk.com/authorize?response_type=code&client_id=3110645&redirect_uri=http%3A%2F%2Fhabrahabr.ru&scope-offline&display=page
2. आपको habrahabr.ru/?code=CODE पर लौटा दिया गया
3. एक और habruiser विजिट करें habrahabr.ru/social/callback/vkontakte/?code=CODE&state=whogivesafuckaboutstate आप लिंक को खुद ही फेंक सकते हैं, लेकिन इसे img या iframe, आदि में छुपाना बेहतर है। यदि यह हब में लॉग इन है, तो आपका VK उसके हब खाते से जुड़ा हुआ है।
4. अपने वीके के माध्यम से अपने हेबरेकाउंट में प्रवेश करें, अपने अवतार को नयनत में बदलें।

नैतिकता

Vkontakte : समर्थन में पत्रों को अनदेखा करना बंद करें, या अपने डेवलपर्स को एक मात्र नश्वर के साथ बात करने के लिए नीचे आने के लिए कहें। बाउंटी प्रोग्राम भी दर्ज करें (व्यंग्य: इस पर टूटने का खतरा है)।
Habr : मैं कुछ समय के लिए कीमास्टर को बंद करने और कुकी / सत्र से मान के साथ 'राज्य' की सही जाँच करके भेद्यता को ठीक करने की सलाह देता हूं।

रोड टू हेल कम है। आप बोरिंग टोकन - OAuth2.a ( चार्म - प्रोवाइडर ) के साथ एक मौलिक नए मानक के विकास में शामिल हो सकते हैं। सच है, कोई कुकीज़ नहीं।

Egor Homakov ( @homakov ) और isciurus #RT pls


UPD2:
Habr ने भेद्यता को बंद कर दिया, vkontakte ने सभी नए अनुप्रयोगों और पुराने लोगों के लिए अधिसूचना के लिए redirect_uri चेक जोड़ा, facebook "हम केवल एक बार पहुंच टोकन के लिए प्राधिकरण कोडों का आदान-प्रदान करने की अनुमति देंगे और उन्हें उनके निर्माण के 10 मिनट के भीतर एक्सेस टोकन के लिए एक्सचेंज किया जाएगा" और "आपके द्वारा प्रदान किए गए बग विवरणों की समीक्षा करने के बाद, हमारी सुरक्षा टीम ने निर्धारित किया है कि आप $ 2,000 USD का बाउंटी भुगतान प्राप्त करने के योग्य हैं", मैंने फिर से FAQ उठाया, लोग बाउंटी वीके की संभावनाओं के बारे में धारणा बनाते हैं ।