Dva: oauth2 प्रमाणीकरण नमूना

क्या oauth2 सत्यापन url पुनर्निर्देशन द्वारा नहीं किया गया है? यदि आप कुकी को देखते हुए लॉग इन करते हैं तो यह ठीक है।

OAuht2 में से कुछ access_token के माध्यम से किया जाता है, url नहीं, शुद्ध RESTFul प्रारूप

यह बेहतर होगा यदि dva और स्प्रिंग बूट Oauth2 एकीकरण का एक उदाहरण है: D

@soulmachine मैं इसका उपयोग जब मेरे पास समय होगा

@WhatAKitty access_token पास करता है, access_token कहाँ संग्रहीत किया जाता है? स्थानीय/सीज़न में संग्रहीत स्टोरेज में XSS सुरक्षा जोखिम होंगे।

@ u0x01 लोकलस्टोरेज में संग्रहीत है। वास्तव में, अधिक जोखिम नहीं है। Access_token की एक समय सीमा है। आप टाइमआउट के बाद फिर से लॉग इन नहीं कर सकते हैं, और कोई रिफ्रेश_टोकन अनुमति नहीं है। इसके अलावा, कोई दूसरा रास्ता नहीं है। अन्य संबंधित जानकारी पूछी जाती है, और वे सभी स्थानीय भंडारण में संग्रहीत होती हैं।

@WhatAKitty Now हैकर हमला करने के लिए स्वचालित टूल का उपयोग करते हैं या लिखते हैं। access_token की दो घंटे की वैधता अवधि बहुत कुछ करने के लिए पर्याप्त है। आप इस निष्कर्ष पर कैसे पहुंचे कि "बहुत अधिक जोखिम नहीं है"?
दूसरा, रीफ्रेश_टोकन स्थानीय स्टोरेज में नहीं रखा जाता है, आप इसे कहां रखते हैं?
एक्सेस_टोकन एपीपी के लिए अधिक उपयुक्त है। शुद्ध जेएस पक्ष को एक्सेस_टोकन योजना का उपयोग नहीं करना चाहिए। क्रॉस-साइट हमलों का जोखिम अभी भी है।
अब सबसे सुरक्षित समाधान http-only को set-cookie में जोड़ना है।
लॉगिन की जाँच करते समय, कुकी को सर्वर पर लाएँ ताकि सीज़न स्थिति खींच सके। यदि यह विफल हो जाता है, तो यह सीधे लॉगिन पृष्ठ पर चला जाएगा।
सुरक्षा भी उत्पादकता है, जो कि Taishan से अधिक महत्वपूर्ण है, इसलिए आप यहाँ आलसी नहीं हो सकते।

@ u0x01 रीफ्रेश_टोकन, मैं इसे जेएस क्लाइंट को नहीं दूंगा। इसलिए, इसे समाप्त होने के बाद इसे फिर से प्रमाणित किया जाना चाहिए। मैंने इसे पहले स्पष्ट नहीं किया होगा, क्योंकि हमारा आवेदन इस तरह है: access_token केवल एक कुंजी है जो आपको एक्सेस करने की अनुमति देती है। यदि आप विशिष्ट संसाधनों तक पहुंच बनाना चाहते हैं, तो आपको उपयोगकर्ता प्रमाणीकरण के माध्यम से जाना होगा। यह प्रक्रिया एसएसएल द्वारा सुरक्षित है, इसलिए आप प्रकट नहीं होंगे। विभिन्न जोखिमों को कहा।
जहाँ तक आपके द्वारा बताए गए सबसे सुरक्षित समाधान की बात है, मैंने भी कुकीज़ का उपयोग करने पर विचार किया, लेकिन एक: मैंने सर्वर को OAUTH2 और LOGIN PASSWORD के साथ एक ही समय में संगत नहीं बनाया, क्योंकि मैं LOGIN PASSWORD के साथ लॉग इन करने के बाद एक access_token वापस नहीं कर सकता। , अन्य तरीके भी हो सकते हैं, लेकिन मुझे यह नहीं मिला। दूसरा: परियोजना की समय की आवश्यकता के कारण, इस विकल्प को केवल एक समझौता के रूप में चुना जा सकता है। इसलिए, यह योजना थोड़ी अनुचित लगती है, लेकिन वास्तव में कोई सुरक्षा समस्या नहीं होगी।

@WhatAKitty ने एसएसएल के बारे
यदि आप गारंटी दे सकते हैं कि आपकी वेबसाइट प्रणाली XSS/CSRF कमजोरियों से 100% मुक्त है, तो आप इसे स्थानीय स्टोरेज में स्टोर कर सकते हैं और जेएस को सीधे क्रेडेंशियल्स तक पहुंचने दे सकते हैं। (लेकिन मैंने कभी किसी ऐसी कंपनी को नहीं देखा जिसने वोट देने की हिम्मत की हो कि उसके सिस्टम में कोई सुरक्षा खामियां नहीं हैं)

और मुझे समझ में नहीं आता कि विशिष्ट संसाधनों तक पहुँचने का क्या अर्थ है, जिन्हें उपयोगकर्ता द्वारा प्रमाणित किया जाना चाहिए। OAuth2 विनिर्देश में, access_token प्राप्त करने का अर्थ है कि उपयोगकर्ता (या प्रदाता) ने इस प्राधिकरण को मंजूरी दे दी है।

इसके अलावा आपने उल्लेख किया है:
因为没法在使用 LOGIN PASSWORD 登录后给我返回一个access_token
यह OAUth2 विनिर्देश की गलतफहमी और गलत उपयोग है।

लॉगिन पासवर्ड विधि अनिवार्य रूप से एक प्रक्रिया है जिसमें UA सीधे OAUth2 प्रदाता से प्रमाणीकरण का अनुरोध करता है, RFC6749 देखें । इस समय, प्राधिकरण_कोड प्राप्त किया जाना चाहिए। UA द्वारा प्राधिकरण_कोड प्राप्त करने के बाद, इसे OAUth2 प्रदाता की वैधता को सत्यापित करने के लिए क्लाइंट को भेजा जाएगा। यदि सत्यापन पास हो जाता है, तो क्लाइंट को OAUth2 प्रदाता से access_token प्राप्त होगा। इस समय, क्लाइंट संसाधनों तक पहुँचने के लिए access_token का उपयोग कर सकता है। क्लाइंट तब UA को एक सत्र आईडी जारी करता है।
(यहां क्लाइंट बिजनेस पार्टी के सर्वर या एपीपी को संदर्भित करता है, अंतिम उपयोगकर्ता नहीं, अंतिम उपयोगकर्ता संसाधन स्वामी है, और यूए ब्राउज़र है)

कुल मिलाकर, सत्र आईडी का उपयोग उपयोगकर्ताओं को प्रमाणित करने के लिए किया जाना चाहिए, भले ही सत्र आईडी का उपयोग न किया गया हो, एक्सेस_टोकन को केवल http कुकी में रखा जाना चाहिए:

1. Don't use local storage for session identifiers. Stick with cookies and use the HTTPOnly and Secure flags.
2. If cookies won't work for some reason, then use session storage which will be cleared when the user closes the browser window.
3. Be cautious with storing sensitive data in local storage. Just like any other client side storage options this data can be viewed and modified by the user. 

यदि आप वास्तव में क्लाइंट को access_token का पर्दाफाश करना चाहते हैं, तो समझौता विधि है:

// GET /seesion
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" {
        ctx.JSON(200, {"signed": true, "access_token": access_token})
    } else {
        ctx.Redirect("//yoursite.com/login")
    }

लेकिन मैं अभी भी इसे केवल कुकी में डालने की सलाह देता हूं। JS यह निर्धारित करने के लिए GET /seesion विधि का उपयोग करता है कि आपने लॉग इन किया है या नहीं। अन्य संसाधनों को हमेशा की तरह एक्सेस किया जाता है। यह पता लगाने के बाद कि एक्सेस_टोकन की समय सीमा समाप्त हो गई है, सर्वर सीधे लॉगिन पेज पर पहुंच जाएगा :

// GET /seesion
    access_token := ctx.Session().GetString("access_token")
    if signed != "" {
        ctx.JSON(200, {"signed": true})
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

// GET /posts/:postid
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" && isValidAccessToken(access_token) {
        ctx.JSON(200, getPostWithAccessToken(access_token, postid))
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

बेशक, अगर आपको लगता है कि आपकी वेबसाइट प्रणाली का कोई आक्रमण मूल्य नहीं है, तो मैंने कुछ नहीं कहा है।

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

सूचना सुरक्षा को अभी लंबा सफर तय करना है।

@u0x01
मुझे उस बारे में बात करने दें जो मैंने पहले उत्तर दिया था। यह स्पष्ट नहीं हो सकता है। एक्सेस_टोकन प्राप्त करने की प्रक्रिया में, न केवल क्लाइंट_आईडी और क्लाइंट_सेक्रेट (इसकी आवश्यकता नहीं हो सकती है) की आवश्यकता होती है, बल्कि उपयोगकर्ता नाम और पासवर्ड की भी आवश्यकता होती है।

वेबसाइट को XSS/CSRF के आक्रमण से बचा सकता है

वहाँ CSRF अक्षम कर दिया गया है। XSS के लिए, डेटाबेस में संग्रहीत सभी सामग्री स्वचालित रूप से स्थानांतरित हो जाएगी और अवैध क्षेत्रों को फ़िल्टर किया जाएगा। हालांकि इसमें चूक हो सकती है, इसे पूरी तरह से समाप्त करना असंभव है। सूचना सुरक्षा बिल्कुल सुरक्षित नहीं है। Microsoft और Apple के लिए भी यही सच है मुझे आप पर विश्वास नहीं है। सिस्टम 100% सुरक्षा प्राप्त कर सकता है।

यहां तक ​​​​कि अगर आप सत्र आईडी का उपयोग नहीं करते हैं, तो आपको एक्सेस_टोकन को केवल http कुकी में रखना चाहिए

केवल एचटीपी ही बिल्कुल सुरक्षित नहीं है।

यह OAUth2 विनिर्देश की गलतफहमी और गलत उपयोग है।

मुझे नहीं पता कि इसे गलत उपयोग माना जाता है, लेकिन क्या मेरे अपने आवेदन के लिए प्राधिकरण पृष्ठ का अनुरोध करना संभव है। उपयोगकर्ता के लॉग इन करने के बाद, वह प्राधिकरण पृष्ठ प्राप्त करता है और फिर उस तक पहुंचने के लिए सहमत होता है? बहुत ज्यादा परेशानी है? अभी के लिए, कोई भी वेबसाइट अपने स्वयं के अनुप्रयोगों के लिए ऐसा नहीं करती है, है ना?

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

दूसरे शब्दों में, मेरी आदर्श प्रमाणीकरण विधि हमारे अपने UA के लिए है। मुझे लगता है कि यदि यह कोई तृतीय पक्ष है, तो उपयोगकर्ता द्वारा उपयोग किए जा सकने वाले प्राधिकरण पृष्ठ को प्राप्त करने के लिए आपके द्वारा उल्लिखित Authorize_code का उपयोग करना आवश्यक हो सकता है।

उपरोक्त मेरी आदर्श प्रमाणीकरण विधि है, लेकिन दुर्भाग्य से मेरा स्तर सीमित है और मुझे स्प्रिंग के OAuth2 के माध्यम से वह प्रभाव नहीं मिल सकता है जो मैं चाहता हूं।

मुझे नहीं पता कि यह भविष्य में आपके नियोक्ता को कितना नुकसान पहुंचाएगा

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

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

1. मैं इस आवश्यकता को अपने व्यक्तिगत तकनीकी स्तर से पूरा नहीं कर सकता। मैं स्वयं तकनीकी विशेषज्ञ नहीं हूं।
2. मेरा मार्गदर्शन करने के लिए एक वास्तविक तकनीकी विशेषज्ञ की कमी, अगर कोई मेरा मार्गदर्शन करने को तैयार है, तो मुझे लगता है कि मुझे खुशी होगी

अब तक, मेरी सभी तकनीकों को बिना किसी मार्गदर्शन के एक व्यक्ति द्वारा खोजा गया है। कुछ कम समाधान वास्तव में मेरी कमियां हैं।

@WhatAKitty
चूँकि आपका प्रोजेक्ट जल्दी में है और बॉस को कोई फ़र्क नहीं पड़ता, बस इसे अभी अपने विचारों के अनुसार करें।

लेकिन क्या आपके स्वयं के आवेदन के लिए प्राधिकरण पृष्ठ का अनुरोध करना संभव है। उपयोगकर्ता के लॉग इन करने के बाद, प्राधिकरण पृष्ठ प्राप्त करें और फिर उस तक पहुंचने के लिए सहमत हों? बहुत ज्यादा परेशानी है? अभी के लिए, कोई भी वेबसाइट अपने स्वयं के अनुप्रयोगों के लिए ऐसा नहीं करती है, है ना?

कृपया OAuth2 के प्रासंगिक विनिर्देशों को देखें, OAuth2 में निहित अनुमति की अवधारणा है।

दूसरे शब्दों में, मेरी आदर्श प्रमाणीकरण विधि हमारे अपने UA के लिए है। मुझे लगता है कि यदि यह कोई तृतीय पक्ष है, तो उपयोगकर्ता द्वारा उपयोग किए जा सकने वाले प्राधिकरण पृष्ठ को प्राप्त करने के लिए आपके द्वारा उल्लिखित Authorize_code का उपयोग करना आवश्यक हो सकता है।

ऐसा लगता है कि OAuth2 में किसी तीसरे पक्ष की अवधारणा नहीं है।

इसके अलावा, आप सीएसआरएफ सुरक्षा अक्षम के साथ क्या कर रहे हैं... क्या यह अपने लिए एक गड्ढा खोदना नहीं है?
मैंने यह नहीं कहा कि केवल http ही बिल्कुल सुरक्षित है। मुख्य सुरक्षा समस्या जो http केवल हल करती है, वह है js को कुकीज़ पढ़ने से रोकना। एसएसएल के साथ सहयोग करने से तीसरे पक्ष को कुकीज़ की निगरानी करने से रोका जा सकता है (गैर-मैन-इन-द-मिडिल हमलों के मामले में)।

@WhatAKitty
मैं बॉस के नजरिए से खड़ा था, लेकिन वास्तव में, कुछ सुरक्षा मुद्दों का होना अच्छा है। एक तरफ आपका बॉस सुरक्षा मुद्दों पर ध्यान देगा और दूसरी तरफ आप सूचना सुरक्षा इंजीनियर के लिए खाना छोड़ देंगे।

सूचना सुरक्षा इंजीनियरों को प्रोग्रामर को धन्यवाद देना चाहिए जो जानबूझकर बग छोड़ देते हैं :)

@ u0x01 ऐसा लगता है कि आप OAuth2 को अच्छी तरह जानते हैं? क्या समूह बनाना संभव है? मुझे इस क्षेत्र में आवेदन संबंधी बहुत सारी जानकारी नहीं मिली, और मेरे पास इसे एकत्र करने के लिए बहुत अधिक समय नहीं था। मैं आपसे कुछ प्रश्न पूछ सकता हूं।

@ u0x01 बैकएंड स्टेटलेस है और कोई सत्र बिल्कुल नहीं है। आपको यह निर्धारित करने के लिए टोकन का उपयोग करने की आवश्यकता है कि यह समाप्त हो गया है या नहीं।क्या मैं पूछ सकता हूँ कि टोकन कहाँ सुरक्षित है?

@longzb स्टेटलेस ≠ सत्र कोई नहीं, आपने उल्लेख किया है

रेडिस के लिए टोकन का उपयोग यह निर्धारित करने के लिए करें कि क्या यह समाप्त हो गया है

वास्तव में, access_token का उपयोग सत्र के रूप में किया जाता है। सत्र की परिभाषा और काम करने के तरीकों के बारे में जानने की सिफारिश की जाती है।

टोकन कहाँ सुरक्षित है?

इसे http_only कुकी में डालने से JS को सीधे कुकी प्राप्त करने से रोका जा सकता है, जिससे XSS/CSRF हमलों के मूल्य और संभावना को कम किया जा सकता है।

@ u0x01 हम्म। मैं कल Baidu गया था। मैं कुकीज़ डालने जा रहा हूँ, सुरक्षित रहना बेहतर है।

यह लेख निहित विश्लेषण के बारे में अच्छा है।
आज मैं SSM+ANTD नमूना समाप्त कर रहा हूँ। इस लेख को पढ़ने के बाद, मुझे लगता है कि सबसे सुरक्षित तरीका है कि निहित सर्वर का उपयोग प्रमाणीकरण सर्वर का अनुरोध करने और टोकन प्राप्त करने के लिए किया जाए, और निहित सर्वर से संसाधनों को प्राप्त करने का अनुरोध किया जाए। संसाधन सर्वर।

क्योंकि जैसा कि इस लेख में कहा गया है, निहित प्राधिकरण जोखिम भरा है, जैसे कि फ़िशिंग, हैकर के लिए संसाधनों का अनुरोध करने के लिए एक सुरक्षित क्लाइंट होने का दिखावा करना आसान है।

लेकिन ऐसा करने के लिए, dva को सर्वर-साइड रेंडरिंग का समर्थन करने की आवश्यकता है। अब जब antd इसका समर्थन करता है, तो क्या dva पहले से ही इसका समर्थन करता है? @sorrycc

आप सही चीजों की चिंता नहीं कर रहे हैं

क्लाइंट पर स्थित जानकारी की सुरक्षा करना?

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

एक बार क्लाइंट पर पहुंच टोकन के बारे में चिंता करना आपके ईमेल पासवर्ड को लिखने के लिए नोटपैड खोलने जैसा है और फिर चिंता करें कि कोई हमलावर उस जानकारी को दूरस्थ स्थान से चोरी करने में सक्षम हो सकता है। ऐसा नहीं होता है। जब तक आपके कंप्यूटर से पहले से समझौता नहीं किया जाता है लेकिन इस बिंदु पर आप पहले ही हार चुके हैं।

चिंता करना कहाँ समझ में आता है?

आम तौर पर, जब आपकी जानकारी ट्रांज़िट में होती है तो असुरक्षित होती है। OAuth2 (अंतर्निहित प्रवाह) के मामले में, एक्सेस टोकन दो स्थानों पर ट्रांज़िट में होगा:

प्राधिकरण सर्वर से आपके ब्राउज़र पर
आपके ब्राउज़र से संसाधन सर्वर तक
जानकारी को ट्रांज़िट के दौरान सुरक्षित रखना उतना ही आसान है जितना कि हर जगह TLS का उपयोग करना। जो आपको पहले से ही करना चाहिए क्योंकि आप OAuth2 का उपयोग कर रहे हैं और यह प्रोटोकॉल द्वारा आवश्यक है।

अब असली समस्या

जिस तरह से आप OAuth2 का उपयोग करने का इरादा रखते हैं, वह संभवतः उस तरह से नहीं है जैसा आपको इसका उपयोग करना चाहिए।

यह समझने के लिए कि आप संभवतः OAuth2 का दुरुपयोग क्यों करेंगे, आपको प्रवाहों के बारे में जानना होगा। OAuth2 4 प्राधिकरण प्रवाह को परिभाषित करता है

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

निहित प्रवाह की समस्या

कई हैं, लेकिन सबसे महत्वपूर्ण के बारे में बात करते हैं। एक्सेस टोकन किसी विशिष्ट क्लाइंट के लिए बाध्य नहीं हैं! विनिर्देश अनुभाग 10.16 से:

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

एक संसाधन स्वामी स्वेच्छा से किसी हमलावर के दुर्भावनापूर्ण क्लाइंट को एक्सेस टोकन देकर संसाधन तक पहुंच सौंप सकता है। यह फ़िशिंग या किसी अन्य बहाने के कारण हो सकता है। एक हमलावर किसी अन्य तंत्र के माध्यम से एक टोकन भी चुरा सकता है। एक हमलावर तब प्रयास कर सकता है एक वैध सार्वजनिक क्लाइंट को एक्सेस टोकन प्रदान करके संसाधन स्वामी का प्रतिरूपण करें।

निहित प्रवाह (response_type=token) में, हमलावर आसानी से प्राधिकरण सर्वर से प्रतिक्रिया में टोकन को स्विच कर सकता है, वास्तविक एक्सेस टोकन को हमलावर को पहले जारी किए गए टोकन के साथ बदल सकता है।

मूल अनुप्रयोगों के साथ संचार करने वाले सर्वर जो क्लाइंट के उपयोगकर्ता की पहचान करने के लिए बैक चैनल में एक एक्सेस टोकन पारित होने पर भरोसा करते हैं, उसी तरह एक हमलावर द्वारा समझौता किया जा सकता है जो एक समझौता किया गया एप्लिकेशन बनाता है जो मनमाने ढंग से चोरी किए गए एक्सेस टोकन को इंजेक्ट कर सकता है।

कोई भी सार्वजनिक क्लाइंट जो यह धारणा बनाता है कि केवल संसाधन स्वामी ही इसे संसाधन के लिए वैध एक्सेस टोकन के साथ प्रस्तुत कर सकता है, इस प्रकार के हमले के लिए असुरक्षित है।
वह पहला हमला वास्तव में एक हमला भी नहीं है, बल्कि निहित प्रवाह में सिर्फ एक "दोष" है ...

अगला हमला

अब बड़ी मुसीबतें शुरू होती हैं। ऐसा लगता है कि आप OAuth2 निहित प्रवाह को प्रत्यायोजित अंतिम-उपयोगकर्ता प्रमाणीकरण के रूप में उपयोग करने का प्रयास कर रहे हैं, जो इसे प्रदान करने के लिए नहीं है। विनिर्देश अनुभाग 10.16 पर वापस जाएं।

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

उस हमले को कैसे माउंट करें?

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

वह सब क्योंकि एक्सेस टोकन किसी विशिष्ट क्लाइंट के लिए बाध्य नहीं हैं।

एक तरकीब

निहित प्रवाह का उपयोग न करें और इसके बजाय प्राधिकरण कोड प्रवाह का उपयोग करें। जिसका अर्थ है कि आपके 100% क्लाइंट साइड ऐप को अब 100% क्लाइंट साइड ऐप नहीं होना चाहिए।

आप उस सर्वर का उपयोग क्यों नहीं कर रहे हैं जो OAuth2 प्रवाह को संभालने के लिए आपके उपयोगकर्ता को angularjs क्लाइंट की सेवा कर रहा है?

संदर्भ: http://tools.ietf.org/html/rfc6749

@WhatAKitty यदि प्रत्येक उपयोगकर्ता के ब्राउज़र का एक निश्चित पहचानकर्ता अद्वितीय है, तो उपयोगकर्ता अनुरोध भेजते समय स्वचालित रूप से इस पहचानकर्ता को लाएगा, और इसे बदला नहीं जा सकता है। पहली बार टोकन के लिए आवेदन करते समय बैकएंड इस पहचानकर्ता को टोकन बांध सकता है। एक बार जब अगला अनुरोध टोकन में संग्रहीत ब्राउज़र आईडी के अनुरूप नहीं होता है, तो इसे एक अवैध अनुरोध माना जाएगा। .
तो मैं पूछना चाहता हूं, क्या ऐसा कोई लोगो है जब ब्राउज़र अनुरोध करता है? ?

@longzb आम तौर पर

@WhatAKitty @soulmachine @longzb

जब OAuth2.0 के पासवर्ड और क्लाइंट मोड एक ही समय में उपयोग किए जाते हैं, तो एक्सेस_टोकन को स्टोर करने के लिए बैक-एंड सर्वर में एक एंट्री प्रॉक्सी जोड़ा जा सकता है, और इस प्रॉक्सी को फ्रंट-एंड CORS (स्प्रिंग बूट) के रूप में भी इस्तेमाल किया जा सकता है। Oauth2 CORS की पूर्व-उड़ान को रोकना प्रतीत होता है)

फ़्रंट-एंड पासवर्ड मोड को केवल एजेंट को उपयोगकर्ता नाम और पासवर्ड भेजने की आवश्यकता होती है। एजेंट प्राधिकरण प्राप्त करता है और access_token को संग्रहीत करता है। फिर एजेंट द्वारा उत्पन्न SESSION_ID को फ्रंट-एंड पर वापस कर दिया जाता है, और एजेंट को प्रबंधन की आवश्यकता होती है एक्सेस_टोकन की समाप्ति और रीफ्रेश। फ्रंट-एंड के संपर्क में आने वाली एकमात्र चीज याद रखें- मुझे इत्यादि Set-Cookie: Expires=

क्लाइंट के क्लाइंट मोड को केवल प्रॉक्सी तक पहुंचने की आवश्यकता नहीं है, प्राधिकरण प्राप्त करने के लिए सीधे OAuth इंटरफ़ेस पर जाएं

जहाँ तक @u0x01 के उत्तर की बात है, मैंने बहुत सारी भ्रामक और बेकार जानकारी कही

वास्तव में, इसे संक्षेप में निम्नानुसार किया जा सकता है:

1. एक्सेस_टोकन को सीधे सत्र के बजाय सामने के छोर पर फेंकना है क्योंकि इसे क्लाइंट मोड के साथ इंटरफ़ेस साझा करने की आवश्यकता है। इस प्रकार का इंटरफ़ेस अक्सर सत्र सत्यापन का समर्थन नहीं करता है, या यह एक वितरित सिस्टम पर सत्र का प्रबंधन करने के लिए असुविधाजनक है।

2. XSS और CSRF हमलों के खिलाफ सुरक्षा का अलग से विश्लेषण किया जाना चाहिए

   2.1 सीएसआरएफ को रोकने के लिए, फ्रंट-एंड एक्सेस_टोकन को भेजने के लिए HTTP हेडर में रखता है, और बैक-एंड केवल हेडर सत्यापन का समर्थन करता है। साथ ही, इंटरफ़ेस को अच्छी तरह से डिज़ाइन करने के लिए पर्याप्त है। क्योंकि तृतीय-पक्ष वेबसाइट केवल प्रपत्र के माध्यम से अतिरिक्त HTTP शीर्षलेख नहीं भेज सकती है, और तृतीय-पक्ष वेबसाइट का JS अपनी वेबसाइट पर डेटा नहीं भेज सकता (जब CORS सही ढंग से सेट हो)

   2.2 एक्सएसएस को रोकने के लिए, एक्सेस_टोकन का फ्रंट-एंड भंडारण वास्तव में असुरक्षित है और जेएस द्वारा इच्छानुसार पढ़ा जा सकता है और डोमेन पर भेजा जा सकता है; और HttpOnly सेट के साथ कुकीज़ क्रेडेंशियल संसाधन हैं। आधुनिक ब्राउज़रों में बहुत सीमित क्रॉस-डोमेन प्रतिबंध हैं क्रेडेंशियल्स पर सख्ती से इसे प्राप्त करने का लगभग कोई तरीका नहीं है। लेकिन अंतिम विश्लेषण में, XSS को रोकने का मतलब स्क्रिप्ट इंजेक्शन को रोकना + अविश्वसनीय बाहरी स्क्रिप्ट को उद्धृत करने से बचना नहीं चाहिए?यह HttpOnly केवल एक उपाय कहा जा सकता है

3. सबसे सुरक्षित उपाय बैक एंड पर एक प्रवेश प्रॉक्सी के रूप में कार्य करना है, और CORS के Access-Control-Allow-Origin को केवल फ्रंट-एंड डोमेन नामों की अनुमति देने के लिए सेट करना है। उपयोगकर्ता सफलतापूर्वक लॉग इन करने के बाद, HttpOnly का सत्र वापस आ जाता है, और एक यादृच्छिक कोड जैसे X-CSRF-TOKEN हेडर फ़ील्ड में जोड़ा जाता है। यह यादृच्छिक कोड OAuth इंटरफ़ेस से प्राप्त access_token के साथ मौजूद है . कुकी और इस हेडर के साथ डेटा भेजने के लिए फ्रंट-एंड अजाक्स या फ़ेच का उपयोग करता है। बैक-एंड कुकी की वैधता की पुष्टि करने के बाद, उसे X-CSRF हेडर की वैधता को सत्यापित करने की आवश्यकता होती है।यह मूल रूप से CSRF और साधारण XSS को अनुमतियाँ चुराने से रोक सकता है

संक्षेप में, access_token के फ्रंट-एंड प्रबंधन को असभ्य रूप से असुरक्षित नहीं माना जा सकता है

अद्यतन 1:

मिडलवेयर या बैकएंड एक्सेस_टोकन को एन्क्रिप्ट करने के लिए jwt का उपयोग करता है, और साथ ही, XSS को रोकने के लिए इंजेक्शन डिटेक्शन और CSP बनाता है।

@mdluo का एक स्पष्ट विचार है, प्रशंसा करें

@mdluo क्षमा करें, मैं सामने के छोर पर एक नौसिखिया हूं। आपके द्वारा बताई गई तीसरी विधि में, मैं मूल रूप से स्प्रिंग बूट + स्प्रिंग सुरक्षा के साथ बैक-एंड भाग प्राप्त कर सकता हूं, लेकिन मैं कुकीज़ को फ्रंट-एंड फ़ेच में कैसे लाऊं? क्योंकि इसमें क्रॉस-डोमेन शामिल है, इंटरनेट पर कुछ समाधान इसे हल करने के लिए पैरामीटर credentials: "include" करते हैं, लेकिन यह पैरामीटर केवल GET अनुरोधों को हल कर सकता है। POST और अन्य समस्याओं में समस्याएं हैं। क्योंकि यह पहली बार इसका उपयोग कर रहा है, इसे स्वयं लिखना बेवकूफी हो सकती है। पर्यावरण है:
फ्रंट एंड: डीवीए पोर्ट 8000
बैकएंड: स्प्रिंग बूट + स्प्रिंग सुरक्षा, एक्स-सीएसआरएफ-टोकन और कुकी

@ yoster0520 बैकएंड पर CORS कॉन्फ़िगर करें। यदि फ्रंटएंड में कई पते हैं, तो बैकएंड को गतिशील रूप से निर्धारित करना चाहिए और श्वेतसूची के अनुसार केवल Access-Control-Allow-Origin वापस करना चाहिए, ताकि यह कुकीज़ ला सके