Dva: نموذج مصادقة oauth2

ألا يتم التحقق من oauth2 عن طريق إعادة توجيه عنوان url؟ لا بأس إذا قمت بتسجيل الدخول من خلال الحكم على ملف تعريف الارتباط.

يتم تنفيذ بعض OAuht2 من خلال access_token ، وليس url ، بتنسيق RESTFul الخالص

سيكون من الأفضل إذا كان هناك مثال على تكامل dva و Spring Boot Oauth2: D

soulmachine أستخدم هذا ،

WhatAKitty يمر access_token ، أين يتم تخزين access_token؟ المخزنة في local / seeionStorage ستتعرض لمخاطر أمان XSS.

يتم تخزين @ u0x01 في localstorage. في الواقع ، لا توجد مخاطرة كبيرة. Access_token له حد زمني. لا يمكنك تسجيل الدخول مرة أخرى بعد انتهاء المهلة ، ولا يوجد إذن تحديث. علاوة على ذلك ، لا توجد طريقة أخرى ، حيث يتم الاستعلام عن المعلومات الأخرى ذات الصلة ، ويتم تخزينها جميعًا في التخزين المحلي.

WhatAKitty Now المتسللين يستخدمون أو يكتبون أدوات آلية للهجوم. فترة صلاحية access_token التي تبلغ ساعتين كافية للقيام بالعديد من الأشياء. كيف توصلت إلى استنتاج مفاده أنه "ليس هناك الكثير من المخاطر"؟
ثانيًا ، لا يتم وضع Refresh_token في localstorage ، فأين تضعه؟
يعتبر access_token أكثر ملاءمة لـ APP. يجب ألا يستخدم جانب JS الخالص مخطط access_token. لا يزال هناك خطر حدوث هجمات عبر المواقع.
الحل الأكثر أمانًا الآن هو إضافة http فقط إلى set-cookie.
عند التحقق من تسجيل الدخول ، قم بإحضار ملف تعريف الارتباط إلى الخادم لسحب حالة العرض ، وإذا فشل ، فسوف ينتقل مباشرة إلى صفحة تسجيل الدخول.
السلامة هي أيضًا الإنتاجية ، وهي أهم من Taishan ، لذلك لا يمكنك أن تكون كسولًا هنا.

@ u0x01 Refresh_token ، لن أعطيها لعميل js. لذلك ، يجب إعادة اعتمادها بمجرد انتهاء صلاحيتها. ربما لم أوضح ذلك من قبل ، لأن تطبيقنا على هذا النحو: access_token هو مجرد مفتاح يسمح لك بالوصول. إذا كنت ترغب في الوصول إلى موارد معينة ، يجب أن تمر عبر مصادقة المستخدم. هذه العملية مؤمنة بواسطة SSL ، لذلك لن تظهر .. قال مخاطر مختلفة.
بالنسبة للحل الأكثر أمانًا الذي قلته ، فقد فكرت أيضًا في استخدام ملفات تعريف الارتباط ، ولكن واحدًا: لم أجعل الخادم متوافقًا مع OAUTH2 و LOGIN PASSWORD في نفس الوقت ، لأنني لا أستطيع إرجاع access_token بعد تسجيل الدخول باستخدام LOGIN PASSWORD.، قد تكون هناك طرق أخرى ، لكنني لم أجدها. ثانيًا: نظرًا لمتطلبات الوقت الخاصة بالمشروع ، لا يمكن تحديد هذا الخيار إلا كحل وسط. لذلك ، يبدو أن هذه الخطة غير ملائمة بعض الشيء ، لكن في الواقع لن تكون هناك مشكلات أمنية.

WhatAKitty لم يسمع من قبل عن SSL "يمكن أن تحمي المواقع من التعرض لهجوم من قبل XSS / CSRF" ، لا توجد علاقة مباشرة بين الاثنين.
إذا كان بإمكانك ضمان خلو نظام موقع الويب الخاص بك بنسبة 100٪ من ثغرات XSS / CSRF ، فيمكنك تخزينه في localStorage والسماح لـ JS بالوصول إلى بيانات الاعتماد مباشرة. (لكنني لم أر أبدًا أي شركة تجرأت على التصويت بأن نظامها لا يحتوي على ثغرات أمنية)

ولا أفهم ما يعنيه الوصول إلى موارد محددة ، والتي يجب أن يصادق عليها المستخدم. في مواصفات OAuth2 ، يعني الحصول على access_token أن المستخدم (أو الموفر) قد وافق على هذا التفويض.

بالإضافة إلى أنك ذكرت:
因为没法在使用 LOGIN PASSWORD 登录后给我返回一个access_token
إنه سوء فهم لمواصفات OAUth2 واستخدام خاطئ.

طريقة كلمة مرور تسجيل الدخول هي في الأساس عملية تطلب فيها UA مباشرة المصادقة من موفر OAUth2 ، انظر RFC6749 . في هذا الوقت ، يجب الحصول على رمز_ التخويل. بعد حصول UA على رمز_التخويل ، سيتم إرساله إلى العميل للتحقق من صحة موفر OAUth2. إذا تم تمرير التحقق ، فسيحصل العميل على access_token من موفر OAUth2. في هذا الوقت ، يمكن للعميل استخدام access_token للوصول إلى الموارد. يقوم العميل بعد ذلك بإصدار SessionID إلى UA.
(يشير العميل هنا إلى الخادم أو التطبيق الخاص بجهة العمل ، وليس المستخدم النهائي ، والمستخدم النهائي هو مالك المورد ، و UA هو المتصفح)

بشكل عام ، يجب استخدام SessionID للمصادقة على المستخدمين ، حتى إذا لم يتم استخدام SessionID ، يجب وضع access_token في 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 / seeion لتحديد ما إذا كنت قد قمت بتسجيل الدخول أم لا. يتم الوصول إلى الموارد الأخرى كالمعتاد. سينتقل الخادم إلى صفحة تسجيل الدخول مباشرةً بعد اكتشاف انتهاء صلاحية access_token :

// 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
دعني أتحدث عما أجبته من قبل. قد لا يكون واضحًا. في عملية الحصول على access_token ، لا يلزم فقط client_id و client_secret (قد لا تكون هناك حاجة) ، ولكن يلزم أيضًا اسم مستخدم وكلمة مرور.

يمكن أن تحمي الموقع من التعرض لهجوم من قبل XSS / CSRF

هناك تم تعطيل CSRF. بالنسبة إلى XSS ، سيتم نقل جميع المحتويات المخزنة في قاعدة البيانات تلقائيًا وستتم تصفية الحقول غير القانونية. على الرغم من أنه قد يكون هناك حذف ، إلا أنه من المستحيل إزالته تمامًا.أمن المعلومات ليس آمنًا تمامًا. وينطبق الشيء نفسه على Microsoft و Apple لا أصدقك النظام يمكن أن يحقق أمان 100٪.

حتى إذا كنت لا تستخدم SessionID ، يجب أن تضع access_token في http فقط ملف تعريف الارتباط

HTTP فقط ليس آمنًا تمامًا أيضًا.

إنه سوء فهم لمواصفات OAUth2 واستخدام خاطئ.

لا أعرف ما إذا كان هذا يعتبر استخدامًا غير صحيح ، ولكن هل من الممكن أن يطلب التطبيق الخاص بي صفحة ترخيص. بعد أن يقوم المستخدم بتسجيل الدخول ، يحصل على صفحة التفويض ثم يوافق على الوصول إليها؟ هل هو الكثير من المتاعب؟ في الوقت الحالي ، لا يوجد موقع ويب يفعل ذلك للتطبيقات الخاصة به ، أليس كذلك؟

بالإضافة إلى ذلك ، قد تختلف طريقة المصادقة المثالية عن ما قلته ، لأن خادمي الخاص يوفر خدمات مصادقة OAuth2. لذلك أعتقد أنه بالنسبة لعميل المتصفح الخاص بي ، يكون الأمر على النحو التالي: طلبات UA AS ، وجد AS أنه غير مصدق عليه ، ويقفز إلى LOGIN ، ثم بعد أن يقوم المستخدم بتسجيل الدخول ، يحصل بنجاح على إذن للوصول إلى الخادم (قد يكون هذا يكون access_token ، أو قد يكون كذلك) يمكنك فتح أذونات الوصول إلى خدمة الموارد مباشرة) ، ومن ثم يمكن للمستخدمين بشكل مباشر / غير مباشر (access_token) طلب الموارد في خادم الموارد على الجانب js.

وبعبارة أخرى ، فإن طريقة المصادقة المثالية الخاصة بي هي لـ UA الخاص بنا. وأعتقد أنه إذا كان طرفًا ثالثًا ، فقد يكون من الضروري استخدام رمز التفويض الذي ذكرته للحصول على صفحة التفويض التي يمكن للمستخدم الوصول إليها.

ما سبق هو طريقة المصادقة المثالية الخاصة بي ، ولكن للأسف مستواي محدود ولا يمكنني الحصول على التأثير الذي أريده من خلال Spring's OAuth2.

لا أعرف مقدار الضرر الذي ستلحقه بصاحب العمل في المستقبل

بادئ ذي بدء ، أود أن أشير إلى أن مشروعنا مُلح للغاية ، وأن الهندسة المعمارية قد استوعبت مؤخرًا فقط ، فإذا كان ذلك ممكنًا ، ألن أكون قادرًا على السعي لتحقيق التميز؟ ومع ذلك ، لا يسمح الوقت ، يسمح لك رئيسك في العمل بسحب مشروع العميل أثناء لعب الأمان الفني؟ غالبًا ما تكون الحقيقة قاسية ، فقد لا يهتم مديرك بسلامة عملائك على الإطلاق ، فهم أكثر اهتمامًا بالمصالح. الشيء الوحيد الذي يمكنني فعله هو ضمان أكبر قدر ممكن من السلامة.

@ u0x01 في الواقع ، بالنسبة لي ، أريد أيضًا أن أجعل الهيكل الذي صممته دون أي مشاكل أمنية ، لكن الحقيقة هي:

1. لا يمكنني تلبية هذا المطلب من خلال مستواي الفني الشخصي. لست خبيرًا تقنيًا بنفسي.
2. عدم وجود خبير تقني حقيقي لإرشادي ، إذا كان هناك من يرغب في إرشادي ، أعتقد أنني سأكون سعيدًا

حتى الآن ، تم استكشاف جميع التقنيات الخاصة بي من قبل شخص واحد دون توجيه ، وبعضها يفتقر إلى الحلول هو بالفعل عيوبي.

تضمين التغريدة
نظرًا لأن مشروعك في عجلة من أمرك ولا يهتم الرئيس ، فقط افعل ذلك وفقًا لأفكارك الآن.

ولكن هل يمكن للتطبيق الخاص بك أن يطلب صفحة ترخيص. بعد أن يقوم المستخدم بتسجيل الدخول ، احصل على صفحة التفويض ثم وافق على الوصول إليها؟ هل هو الكثير من المتاعب؟ في الوقت الحالي ، لا يوجد موقع ويب يفعل ذلك للتطبيقات الخاصة به ، أليس كذلك؟

يرجى الرجوع إلى المواصفات ذات الصلة لـ OAuth2 ، حيث يتضمن OAuth2 مفهوم الإذن الضمني.

وبعبارة أخرى ، فإن طريقة المصادقة المثالية الخاصة بي هي لـ UA الخاص بنا. وأعتقد أنه إذا كان طرفًا ثالثًا ، فقد يكون من الضروري استخدام رمز التفويض الذي ذكرته للحصول على صفحة التفويض التي يمكن للمستخدم الوصول إليها.

لا يبدو أن OAuth2 لديها مفهوم الطرف الثالث.

بالإضافة إلى ذلك ، ماذا تفعل مع تعطيل الحماية CSRF ... أليس هذا هو حفر حفرة لنفسك؟
لم أقل أن http فقط آمن تمامًا. المشكلة الأمنية الرئيسية التي يحلها http فقط هي منع js من قراءة ملفات تعريف الارتباط. يمكن أن يمنع التعاون مع SSL الأطراف الثالثة من مراقبة ملفات تعريف الارتباط (في حالة هجمات non-man-in-the-middle).

تضمين التغريدة
اعتدت أن أقف من وجهة نظر المدير ، لكن في الحقيقة ، من الجيد أن تواجه بعض مشكلات السلامة. من ناحية ، سوف يهتم رئيسك بقضايا الأمن ، ومن ناحية أخرى ، ستترك وجبة لمهندس أمن المعلومات.

يجب أن يشكر مهندسو أمن المعلومات المبرمجين الذين يتركون الأخطاء عمدًا :)

@ u0x01 يبدو أنك تعرف OAuth2 جيدًا؟ هل من الممكن إنشاء مجموعة؟ لم أجد الكثير من معلومات التطبيق في هذا المجال ، ولم يكن لدي الكثير من الوقت لجمعها. يمكنني أن أطرح عليك بعض الأسئلة.

@ u0x01 الواجهة الخلفية عديمة الحالة ولا توجد جلسة على الإطلاق. تحتاج إلى استخدام الرمز المميز لـ redis لتحديد ما إذا كانت صلاحيته قد انتهت أم لا.هل لي أن أسأل أين الرمز المميز آمن؟

لقد ذكرت جلسة

استخدم الرمز المميز إلى redis لتحديد ما إذا كانت صلاحيته قد انتهت أم لا

في الواقع ، يتم استخدام access_token كجلسة. يوصى بالتعرف على تعريف الدورة وطرق عملها.

أين هو الرمز الآمن؟

يمكن أن يؤدي وضعه في ملف تعريف الارتباط http_only إلى منع JS من الحصول مباشرة على ملف تعريف الارتباط ، وبالتالي تقليل قيمة وإمكانية هجمات XSS / CSRF.

@ u0x01 هممم . ذهبت إلى بايدو أمس. سأضع ملفات تعريف الارتباط ، فمن الأفضل أن تكون أكثر أمانًا.

هذه المقالة جيدة حول التحليل الضمني.
اليوم أنهي نموذج SSM + ANTD. بعد قراءة هذه المقالة ، أشعر أن الطريقة الأكثر أمانًا هي استخدام الخادم الضمني لطلب خادم المصادقة والحصول على الرمز المميز ، وطلب ضمنيًا من الخادم الضمني الحصول على موارد خادم الموارد.

نظرًا لأنه كما ورد في هذا المقال ، فإن التفويض الضمني محفوف بالمخاطر ، مثل التصيد الاحتيالي ، فمن السهل على المتسلل التظاهر بأنه عميل آمن لطلب الموارد.

ولكن للقيام بذلك ، يحتاج dva إلى دعم العرض من جانب الخادم. والآن بعد أن دعمه antd ، هل يدعمه dva بالفعل؟ تضمين التغريدة

أنت لا تقلق بشأن الأشياء الصحيحة

حماية المعلومات الموجودة على العميل؟

لا تحتاج إلى القيام بأي شيء بمجرد وصول المعلومات إلى عميلك (على سبيل المثال: متصفحك) من أجل حمايته. يمكنك تخزين رمز الوصول في ملف تعريف ارتباط ، في حقل مخفي على صفحة الويب الخاصة بك ، في ذاكرة التخزين المؤقت المحلية html5 أو مرئيًا بشكل واضح في منتصف الصفحة ولا يغير أي شيء (باستثناء تصفح الكتف ...).

القلق بشأن رمز الوصول بمجرد أن يكون على العميل يشبه فتح المفكرة لكتابة كلمة مرور البريد الإلكتروني الخاصة بك ثم القلق من أن المهاجم قد يكون قادرًا على سرقة هذه المعلومات من موقع بعيد. لا يحدث ذلك. ما لم يكن جهاز الكمبيوتر الخاص بك قد تعرض بالفعل للاختراق ولكن في هذه المرحلة كنت قد خسرت بالفعل.

أين من المنطقي أن تقلق؟

عادةً ما تكون معلوماتك عرضة للخطر عندما تكون قيد النقل. في حالة OAuth2 (التدفق الضمني) ، سيكون رمز الوصول قيد النقل في مكانين:

من خادم التفويض إلى متصفحك
من المستعرض الخاص بك إلى خادم الموارد
تعد حماية المعلومات أثناء نقلها بنفس سهولة استخدام TLS في كل مكان. وهو ما يجب أن تفعله بالفعل لأنك تستخدم OAuth2 وهو مطلوب بموجب البروتوكول.

الآن المشكلة الحقيقية

الطريقة التي تنوي بها استخدام OAuth2 ليست على الأرجح بالطريقة التي يجب أن تستخدمها.

لفهم سبب إساءة استخدام OAuth2 على الأرجح ، عليك معرفة التدفقات. يحدد OAuth2 4 تدفق التفويض

رمز التفويض (جيد فقط ولكن ... استمر في القراءة)
ضمني (شعور زائف بالأمان)
بيانات اعتماد كلمة مرور مالك المورد (فكرة مروعة)
بيانات اعتماد العميل (لا تنطبق على حالتك)
نظرًا لأنك تستخدم عميل جافا سكريبت ، فإن التدفق الوحيد الذي يناسبك هو التدفق الضمني ويبدأ الآن المشكلات.

مشاكل التدفق الضمني

هناك الكثير ولكن دعنا نتحدث فقط عن أكثرها أهمية. رمز الوصول غير مرتبط بعميل معين! من قسم المواصفات 10.16:

بالنسبة للعملاء العموميين الذين يستخدمون التدفقات الضمنية ، لا توفر هذه المواصفات أي طريقة للعميل لتحديد العميل الذي تم إصدار رمز وصول له.
هذا يفتح الأبواب للمهاجمين لانتحال هويتك ، بصفتك مالك المورد ، ثم الوصول إلى خادم المورد. دعنا نواصل قراءة القسم 10.16:

قد يفوض مالك المورد عن طيب خاطر الوصول إلى مورد من خلال منح رمز وصول إلى عميل ضار لمهاجم. قد يكون هذا بسبب التصيد الاحتيالي أو بعض الذرائع الأخرى. وقد يسرق المهاجم أيضًا رمزًا مميزًا عبر آلية أخرى. وقد يحاول المهاجم بعد ذلك انتحال شخصية مالك المورد من خلال توفير رمز الوصول إلى عميل عام شرعي.

في التدفق الضمني (response_type = token) ، يمكن للمهاجم بسهولة تبديل الرمز المميز في الاستجابة من خادم التفويض ، واستبدال رمز الوصول الحقيقي بالرمز الذي تم إصداره مسبقًا للمهاجم.

قد تتعرض الخوادم التي تتواصل مع التطبيقات الأصلية التي تعتمد على تمرير رمز وصول في القناة الخلفية لتحديد مستخدم العميل للخطر بالمثل من قبل مهاجم ينشئ تطبيقًا مخترقًا يمكنه إدخال رموز وصول مسروقة تعسفية.

أي عميل عام يفترض أن مالك المورد فقط يمكنه تقديمه برمز وصول صالح للمورد يكون عرضة لهذا النوع من الهجوم.
هذا الهجوم الأول ليس في الواقع هجومًا بل مجرد "عيب" في التدفق الضمني ...

الهجوم القادم

يبدأ الآن المشكلات الكبيرة. يبدو أنك تحاول استخدام التدفق الضمني لـ OAuth2 كشكل من أشكال مصادقة المستخدم النهائي المفوضة والتي لا يُقصد توفيرها. الرجوع إلى قسم المواصفات 10.16

مصادقة مالكي الموارد للعملاء خارج نطاق هذه المواصفات. يجب ألا تستخدم أي مواصفات تستخدم عملية التفويض كشكل من أشكال مصادقة المستخدم النهائي المفوض للعميل (على سبيل المثال ، خدمة تسجيل الدخول لجهة خارجية) التدفق الضمني بدون آليات أمان إضافية من شأنها أن تمكن العميل من تحديد ما إذا كان قد تم إصدار رمز الوصول لاستخدامه (على سبيل المثال ، تقييد الجمهور لرمز الوصول).
في هذه المرحلة ، تنتهي اللعبة في الغالب بالنسبة لك.

كيف تشن هذا الهجوم؟

الأمر بسيط جدًا. لنفترض أن خدمة REST الخاصة بك تتطلب رمز وصول من facebook. كل ما يحتاجه المهاجم هو استضافة خدمة ، على سبيل المثال stackoverflow ، ويطلب رمز وصول من facebook. عندما تمنح رمز الوصول إلى facebook إلى stackoverflow ، يمكن الآن لـ stackoverflow (مهاجمنا) انتحال شخصيتك من خلال خدمة REST الخاصة بك.

كل ذلك لأن رموز الوصول ليست ملزمة بعميل معين.

حل

لا تستخدم التدفق الضمني وبدلاً من ذلك استخدم تدفق رمز التفويض. مما يعني أن التطبيق الخاص بك من جانب العميل بنسبة 100٪ لن يحتاج بعد الآن إلى أن يكون تطبيقًا من جانب العميل بنسبة 100٪.

لماذا لا تستخدم الخادم الذي يخدم عميل angularjs للمستخدم الخاص بك للتعامل مع تدفق OAuth2؟

المرجع: http://tools.ietf.org/html/rfc6749

WhatAKitty إذا كان معرف معين لمتصفح كل مستخدم فريدًا ، فسيقوم المستخدم تلقائيًا بإحضار هذا المعرف عند إرسال الطلب ، ولا يمكن تغييره.يمكن للواجهة الخلفية ربط الرمز المميز بهذا المعرف عند التقدم للحصول على الرمز المميز لأول مرة. بمجرد أن لا يتوافق الطلب التالي مع معرف المتصفح المخزن في الرمز المميز ، فسيتم اعتباره طلبًا غير قانوني. .
لذلك أريد أن أسأل ، هل يوجد مثل هذا الشعار عندما يطلبه المتصفح؟ ؟

يستخدم longzb بشكل عام JSESSIONID ، أو يمكن تخصيصه. على سبيل المثال ، يستخدم oschina معرفه الخاص

WhatAKittysoulmachinelongzb

عند استخدام وضعي كلمة المرور والعميل في OAuth2.0 في نفس الوقت ، يمكن إضافة وكيل إدخال إلى الخادم الخلفي لتخزين access_token ، ويمكن أيضًا استخدام هذا الوكيل باعتباره CORS للواجهة الأمامية (Spring Boot) يبدو أن Oauth2 يعترض الضوء المبدئي لـ CORS)

يحتاج وضع كلمة مرور الواجهة الأمامية فقط إلى إرسال اسم المستخدم وكلمة المرور إلى الوكيل. ويحصل الوكيل على التفويض ويخزن access_token. ثم يتم إرجاع SESSION_ID الذي تم إنشاؤه بواسطة الوكيل إلى الواجهة الأمامية ، ويحتاج الوكيل إلى إدارة انتهاء الصلاحية وتحديث access_token. الشيء الوحيد الذي يتم عرضه للواجهة الأمامية هو تذكرني وما إلى ذلك ، فهي مختلفة تمامًا في رأس Set-Cookie: Expires=

لا يحتاج وضع العميل الخاص بالعميل فقط إلى الوصول إلى الوكيل ، ما عليك سوى الانتقال مباشرةً إلى واجهة OAuth للحصول على التفويض

بالنسبة لرد @ u0x01 ، قلت الكثير من المعلومات المحيرة وغير المجدية

في الواقع يمكن تلخيصها على النحو التالي:

1. إن إلقاء access_token مباشرة إلى الواجهة الأمامية بدلاً من Session لأنه يحتاج إلى مشاركة الواجهة مع وضع العميل. غالبًا لا يدعم هذا النوع من الواجهة التحقق من الجلسة ، أو أنه من غير المناسب إدارة الجلسة على نظام موزع.

2. يجب تحليل الأمان ضد هجمات XSS و CSRF بشكل منفصل

   2.1 لمنع CSRF ، تضع الواجهة الأمامية access_token في رأس HTTP للإرسال ، بينما تدعم النهاية الخلفية التحقق من الرأس فقط ، وفي نفس الوقت ، يكفي تصميم الواجهة جيدًا. نظرًا لأن موقع ويب الجهة الخارجية لا يمكنه إرسال رؤوس HTTP إضافية فقط من خلال النموذج ، ولا يمكن لـ JS الخاص بموقع الطرف الثالث إرسال البيانات إلى موقع الويب الخاص به (عندما يتم تعيين CORS بشكل صحيح)

   2.2 لمنع XSS ، فإن الواجهة الأمامية لتخزين access_token غير آمنة بالفعل ويمكن قراءتها بواسطة JS في الإرادة وإرسالها عبر المجالات ؛ وملفات تعريف الارتباط مع HttpOnly set هي موارد بيانات الاعتماد. تحتوي المتصفحات الحديثة على قيود محدودة للغاية عبر المجالات على أوراق الاعتماد. لا توجد طريقة تقريبًا للحصول عليها. ولكن في التحليل النهائي ، ألا يعني منع XSS منع إدخال البرنامج النصي + تجنب اقتباس نصوص خارجية غير موثوقة؟لا يمكن القول إن هذا HttpOnly سوى علاج

3. الإجراء الأكثر أمانًا هو العمل كوكيل دخول في النهاية الخلفية ، وتعيين CORS Access-Control-Allow-Origin للسماح فقط بأسماء المجال الأمامية. بعد أن يقوم المستخدم بتسجيل الدخول بنجاح ، يتم إرجاع جلسة HttpOnly ، ويتم إضافة رمز عشوائي مثل X-CSRF-TOKEN إلى حقل الرأس. يوجد هذا الرمز العشوائي مع access_token الذي تم الحصول عليه من واجهة OAuth . تستخدم الواجهة الأمامية Ajax أو الجلب لإرسال البيانات مع ملف تعريف الارتباط وهذا الرأس. بعد أن تتحقق النهاية الخلفية من صحة ملف تعريف الارتباط ، فإنها تحتاج إلى التحقق من صحة رأس X-CSRF .يمكن أن يمنع هذا أساسًا CSRF و XSS العادي من سرقة الأذونات

باختصار ، لا يمكن اعتبار إدارة الواجهة الأمامية لـ access_token غير آمنة بوقاحة

التحديث 1:

تستخدم البرامج الوسيطة أو الخلفية jwt لتشفير access_token ، وفي نفس الوقت ، اكتشاف النموذج و CSP لمنع XSS

mdluo لديه فكرة واضحة ، الثناء 👍

mdluo معذرة ، أنا مبتدئ في الواجهة الأمامية. في الطريقة الثالثة التي ذكرتها ، يمكنني أساسًا تحقيق الجزء الخلفي من خلال التمهيد الربيعي + أمان الربيع ، ولكن كيف يمكنني إحضار ملفات تعريف الارتباط إلى الواجهة الأمامية؟ نظرًا لأنه يتضمن نطاقًا مشتركًا ، فإن بعض الحلول على الإنترنت تستخدم المعامل credentials: "include" لحلها ، ولكن هذه المعلمة يمكنها فقط حل طلبات GET. لأنها المرة الأولى لاستخدامها ، قد يكون من الغباء كتابتها بنفسك. البيئة هي:
الواجهة الأمامية: منفذ DVA 8000
الواجهة الخلفية: التمهيد الربيعي + أمان الربيع ، X-CSRF-TOKEN وملفات تعريف الارتباط

@ yoster0520 قم بتكوين CORS على الواجهة الخلفية. إذا كانت الواجهة الأمامية تحتوي على عناوين متعددة ، فيجب أن تحدد الواجهة الخلفية Access-Control-Allow-Origin وفقًا للقائمة البيضاء ، بحيث يمكنها إحضار ملفات تعريف الارتباط