عزيزي habrozhitel! أعزائي الخبراء! أقدم لتقييمك مفهومًا جديدًا لتعريف المستخدم على مواقع الويب ، والذي آمل أن يصبح بمساعدتك معيارًا مفتوحًا للإنترنت ، مما يجعل عالم الإنترنت هذا أفضل قليلاً. هذا إصدار مسودة لبروتوكول المصادقة بدون كلمة مرور ، تم تصميمه كمقالة مجانية. وإذا كانت الفكرة الكامنة وراء حصولها على تقييم إيجابي منك ، أيها القارئ العزيز ، فسأواصل نشرها على موقع reddit.com و rfc-editor.org. وآمل أن أكون قادرًا على الاهتمام بمطوري المتصفحات الرائدة في تنفيذه. لذلك ، أتوقع النقد البناء منك.

انتباه: الكثير من النص.

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

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

يبدو الأمر وكأنه مهمة للتأكد من أن الذئاب ممتلئة وأن الأغنام آمنة. هل هذا حقيقي؟

أنا ، إلى حد ما ، أعتقد - حقا.

جدول المحتويات

1 مفهوم المصادقة بدون كلمة مرور
1.1 المفاتيح والرموز بدلاً من عمليات تسجيل الدخول وكلمات المرور
1.2 هيكل الرمز
1.3 رؤوس بروتوكول HTTP
1.4 كيف يحدد العملاء المواقع؟
1.4.2 كيف أعرف ما إذا كان الموقع يدعم هذا البروتوكول؟
1.5 كيف يصرح العملاء بالمواقع؟
1.6 كيفية تنفيذ تحديد موثوق للعملاء؟
1.7 إذن على الموقع من خلال عيون المستخدم
1.8 كيف يتغير مفتاح الموقع؟
1.9 كيف يتم تنفيذ ترخيص المجال المشترك؟
1.10 كيفية تنفيذ المصادقة عبر المجال؟
1.11 تنقل الحساب

2 الوصف الفني للبروتوكول
2.0 خوارزمية إنشاء مفتاح المجال
2.1 الخوارزمية لحساب الرمز المميز المصدر
2.2 خوارزمية حماية الرمز أثناء النقل
2.3 إجراء تبادل الملح بين المتصفح والخادم
2.4 قواعد تكوين حقل السياق
2.5 قواعد لتحديد حقول المرسل والمستلم
2.6 تفاصيل حول جداول تعريف السياق
2.7 سيناريوهات البروتوكول
2.8 معالجة الرموز على الخادم
2.9 المصادقة عبر المجال

3 توصيات السلامة
3.1 حماية المعلومات الأساسية من الوصول غير المصرح به
3.2 حول كلمات المرور كمفاتيح المجال
3.3 مخاطر فقدان / المساس بالمفاتيح وتقليلها

4 هجمات على مخطط الترخيص
4.1 تتبع المستخدم
4.2 هجوم XSS
4.3 هجوم CSRF
4.4 تتبع باستخدام SSO
4.5 التسوية الرئيسية ل SSO
4.6 حل وسط رمزي أثناء النقل
4.7 القرصنة موقع على شبكة الإنترنت وتسوية الرموز

استنتاج

ما الخطأ في كلمات المرور؟

نعم ، ليس كذلك. يمكن أن تضيع. يمكن سرقتها. يجب أن نتذكرها. على أي حال ، لماذا أنا ملزم بملء بعض أشكال التسجيل والتوصل إلى كلمة مرور أخرى لمشاهدة الطقس أو تنزيل هذا الملف؟ أخيرًا ، كلمات المرور أقل قليلاً من كثير. كم عدد المواقع التي تحبها ، وكلمات المرور. وبالتالي ، يستخدم الكثير منها فعليًا كلمة مرور واحدة على جميع المواقع. شخص ما يستخدم خوارزمية صعبة لتذكرها. أو مدير كلمة المرور. أو ، بغباء ، دفتر ملاحظات. أو تفضل المصادقة عبر النطاق: يمكنك تسجيل الدخول مرة واحدة على موقع واحد ، وهذا كل شيء! نعم ، ليس كل شيء. هذا إذا كان الموقع يدعمه.
كل هذه الأساليب لها عيوب.
استخدام كلمة مرور واحدة على مواقع مختلفة - Moveton. ما يعرفه شخصان ، يعرف الخنزير أيضًا. لا تتوافق جميع المواقع (حتى الكبيرة منها وذات السمعة الطيبة) بصدق مع قواعد الأمان لتخزين كلمات المرور الخاصة بك. تقوم بعض المواقع بتخزين كلمات المرور في شكل مفتوح ، بينما يعتقد البعض الآخر أن تخزين تجزئة كلمة المرور يحميها بالفعل بشكل كافٍ. نتيجة لذلك ، تحدث تسريبات لكلمات المرور والبيانات الشخصية الأخرى للعملاء بشكل منتظم.
مع مدير كلمة السر هو بالفعل أفضل. صحيح ، لا أحد يضمن لك أنه لا يدمج كلمات المرور الخاصة بك في مكان ما. وابحث عن مدير يمكنه مزامنة حساباتك على جميع الأجهزة (كمبيوتر نتبووك منزلي ، هاتف ، كمبيوتر عمل). أنا لا أستبعد وجود هذا.
ولكن على أي حال ، الفكرة نفسها: قم أولاً بالتسجيل على موقعنا (في الوقت نفسه ، إرسال بريد إلكتروني ، جوال ، التبرع بالدم للتحليل) ، ثم اخترع / تذكر اسم المستخدم وكلمة المرور وكن لطيفًا بما يكفي لتذكرها ، لكن أبقِها سرية - النهج ، وأنا أقول لك ، ما إلى ذلك. وليس مدير كلمة مرور واحد سوف يحلها. لكنه يحل SSO .
هذا مجرد سوء حظ: إذا فقدت كلمة المرور من موقع SSO ونسيتها ، أو سُرق منك ... فقد فقدت الوصول من جميع مواقعك في وقت واحد أو منحته طوعًا لأي شخص ولا يتضح بأي نوايا. لا تخزن كل البيض في سلة واحدة!
وليس حقيقة أن موقع SSO موثوق به. أو لا تخزن كلمات المرور الخاصة بك في نص واضح. أو لا تدمجها طوعًا على الإطلاق ، بالإضافة إلى أنها توفر فرصة للآخرين لتعقبك بين المواقع. حسنا ، أنت تحصل على هذه النقطة.
لذلك: تسجيل الدخول + كلمة المرور = الشر. وكل شر في العالم يجب أن يكون في حالة سكر على محمل الجد ولفترة طويلة. وملف تعريف الارتباط أيضا. جنبا إلى جنب مع التماسيح الجلسة PHPSESSIONID ، JSESSIONID ، ونظيرها.

وماذا تفعل؟

أولاً ، عليك أن تفكر في المواقف المعتادة ، والتي سيكون واضحًا منها: لماذا تريد المواقع أن تتذكر عملائها وهل هي ضرورية لهم حقًا؟

مدونة شخصية "Vasya Pupkina" ، والتي يُسمح فيها ، على سبيل المثال ، بالتعليقات. التسجيل ضروري فقط لحماية نفسه من السير ، وإجراء تصويت مجاني ، وإحصاء "الإعجابات" وغيرها من "مواء مواء" ، وتعيين تقييم للمعلقين. أي هنا ، هناك حاجة إلى وظيفة التعقب حصريًا من قِبل الموقع ، وفقط بواسطة المستخدم (إذا كان يقدّر تقييمه "المعلق" على هذا الموقع) فقط.
مواقع الشبكات الاجتماعية وغيرها من المتحدثين على الإنترنت (ICQ ، سكايب - هناك أيضًا). يلزم التسجيل لتنفيذ محتوى (مؤلف) مسمى ، للتعرف على زوار بعضهم البعض. أي هنا ، هناك حاجة إلى وظيفة تحديد الهوية إلى حد كبير من قبل المستخدمين أنفسهم . على الرغم من أن مواقع الشبكات الاجتماعية هي الأولى في قائمة "الخطاة" ، إلا أنها تجمع المعلومات الأكثر اكتمالا عن الزوار وتذكركم بجدية ولوقت طويل. لذلك ليس معروفًا بعد من الذي يحتاج إلى مزيد من التعريف.
موقع الشركة مع محتوى مغلق. هناك حاجة للتسجيل أو الترخيص هنا بشكل أساسي لتقييد الوصول إلى المحتوى. جميع أنواع: المدارس عبر الإنترنت والمكتبات والمواقع الخاصة غير العامة ، وهلم جرا. هنا ، هناك حاجة إلى وظيفة إذن إلى حد كبير من قبل الموقع . كقاعدة عامة ، لا توجد نماذج تسجيل مفتوحة. تتم مشاركة بيانات الاعتماد من خلال قنوات أخرى.
متجر على شبكة الإنترنت وغيرها من المواد المماثلة التي تبيع المنتجات أو الخدمات أو المحتوى. سأشمل أيضًا مواقع الإعلانات المبوبة المدفوعة / المجانية. هناك حاجة أساسية للتسجيل لتخزين تاريخ طلبات العملاء ، وحتى يتمكن من تتبع وضعهم الحالي ، وتخزين تفضيلاتهم (المفضلة) ؛ من أجل صياغة العروض الشخصية للعميل على أساس تاريخ الشراء والتفضيلات. هنا ، وظيفة تحديد الهوية ضرورية بنفس القدر لكل من العميل والمتجر . ولكن أكثر ، بطبيعة الحال ، إلى المتجر. إلى البخار والبخار والبخار.
أي حسابات شخصية لمستخدمي خدمات الإنترنت: البريد الإلكتروني ، الخدمات العامة ، سبيربنك عبر الإنترنت ، مكبرات الصوت عبر الإنترنت ، مكاتب مقدمي الخدمات ، CMS من المضيفين ، إلخ. هنا ، يهتم المستخدم نفسه في المقام الأول بالتعريف الصحيح والموثوق . بعد كل شيء ، فهو يدير المعلومات المهمة بالنسبة له ، والتي في بعض الحالات لها عواقب قانونية ومالية. لا رائحة مثل عدم الكشف عن هويته. هي ضارة هنا.
أجهزة التوجيه وأجهزة التحكم في الإدارة وإصدارات الويب لإدارة شيء ما على شبكة منزلك أو شركتك.

من الواضح أنه في مواقف مختلفة ، قد تكون هناك مخاطر مختلفة. في بعض الحالات ، لن يؤدي التحديد غير الصحيح أو فقدان بيانات المصادقة أو حتى سرقة / تزويرها إلى أي عواقب مهمة على الموقع أو للمستخدم. في حالات أخرى ، سيكون الأمر غير سارٍ (لقد فقدت الكرمة على حبري - "إنها كارثة ...") أو سيؤدي إلى إزعاج (لا يمكنني أن أتحرك في Yula ، انظر إعلاناتي ؛ لقد تمكنت من الوصول إلى مشاريعي على github ، - حسنًا حساب جديد ، مشاريع شوكة). ثالثا ، يمكن أن تنطوي على عواقب قانونية ومالية. لذلك ، يجب افتراض أن مخطط الترخيص المقترح ليس "رصاصة فضية" لجميع الحالات ، وخاصة "العارية". عند إدارة المعلومات الحساسة ، فإن الأمر يستحق استخدام طرق أخرى لتحديد الهوية والمصادقة أو دمجها (المصادقة ثنائية العامل ، تشفير المفتاح غير المتماثل ، تأمين ثلاثي الأبعاد ، eToken ، رمز OTP ، إلخ).

حسنا ما هي المعارف التقليدية الخاصة بك؟

ماذا يقدم البروتوكول الجديد؟

من منظور المستخدم النهائي:

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

انا ارى وما هي المكافآت التي يجب أن يحصل عليها مطورو المواقع من هذا؟

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

أخيرا:

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

بناءً على هذه المتطلبات ، ننتقل إلى الأكثر إثارة للاهتمام: تصميم بروتوكول جديد.

1 مفهوم المصادقة بدون كلمة مرور

1.1 المفاتيح والرموز بدلاً من عمليات تسجيل الدخول وكلمات المرور

لكل مجال ، بما في ذلك المجالات الفرعية ، يقوم متصفح العميل بشكل عشوائي بإنشاء مفتاح فريد من نوعه 256 بت

$inline$ . لا ينتقل هذا المفتاح أبدًا. لا تزال ثابتة داخل جلسة المستخدم. كل جلسة جديدة تخلق مفتاح جديد.
مفتاح القائمة

$inline$ ينشئ المستعرض الرمز المميز 256 بت باستخدام خوارزمية خاصة

$inline$ لتحديد المستخدم مع مجال معين. رمز الهوية

$inline$ المستخدم (المشار إليه فيما يلي باسم "الرمز المميز") يعمل كبديل لملفات تعريف ارتباط الجلسة مثل PHPSESSIONID و JSESSIONID.
مفتاح

$inline$ يمكن أن تكون " ثابتة " من قبل المستخدم. سيسمح إصلاح المفتاح للمستخدم بالبقاء مرخصًا به على الموقع لفترة غير محدودة في جلسات متصفح مختلفة وإعادة الترخيص الموجود مسبقًا. هذا هو التناظرية لوظيفة "تذكرني" .
عندما يتم إلغاء الالتزام ، فإن المتصفح "ينسى" هذا المفتاح وسيبدأ مرة أخرى في إنشاء مفتاح عشوائي لهذا المجال لكل جلسة جديدة (تبدأ من الجلسة الحالية) ، وهو مماثل لـ "خروج" المستخدم من الموقع. الإخراج فوري ، لا يتطلب إعادة تحميل الصفحة.
يمكن للمستخدم إنشاء مفتاح دائم للمجال . سيسمح المفتاح الدائم ، وكذلك المفتاح الثابت ، للمستخدم بإرجاع الترخيص السابق. في الواقع ، يصبح هذا المفتاح بديلاً لاتصال كلمة مرور تسجيل الدخول.
يحصل المستخدم على الفرصة للتحكم في وقت استخدام متصفح المجال لمفتاح ثابت ، ومتى - عشوائي. هذا هو تناظرية وظيفة تسجيل الدخول / الخروج . يتم تقديم المفهوم في لقطات أدناه .
توفر طرق إنشاء مفاتيح المجال الثابتة إمكانية تنقل حسابات المستخدمين بين الأجهزة المختلفة. يحدد البروتوكول ما يلي:

توليد مفتاح المجال على أساس مفتاح المستخدم الرئيسي
بشكل فردي تشكيل مفتاح المجال على أساس استشعار عدد عشوائي البيولوجي
استيراد المفاتيح الموجودة من ملف مفتاح من جهاز آخر

1.2 هيكل الرمز

الرمز المميز هو بنية 256 بت ، ممثلة كسلسلة سداسية عشرية:

84bc3da1b3e33a18e8d5e1bdd7a18d7a	166d77ac1b46a1ec38aa35ab7e628ab5
جزء تحديد الهوية	جزء المصادقة

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

1.3 رؤوس بروتوكول HTTP

الرؤوس المستخدمة من قبل العميل:

CSI-Token : يستخدم <Token> لإرسال رمز مميز إلى الخادم
CSI-Token : <Token1>؛ يستخدم التغيير إلى <Token2> لتغيير الرمز المميز الحالي:

عند التفويض على مفتاح دائم ،
عند تسجيل مفتاح دائم ،
عند تغيير المفتاح الدائم.

CSI-Token : <Token> دائم يُستخدم عند إصلاح المفتاح العشوائي الحالي من قبل المستخدم.
CSI-Token : <Token> يتم استخدام تسجيل الخروج لإنهاء الجلسة الحالية قبل الأوان.

الرؤوس المستخدمة من قبل الخادم:
دعم CSI: نعم يخبر العميل بأن الخادم يدعم بروتوكول المصادقة على CSI.
CSI-Token-Action: يستخدم النجاح لإخطار المستعرض بقبول رمز مميز جديد للمستخدم (مفتاح التغيير إلى).
CSI-Token-Action: إحباط يلغي الإجراء الخاص بتغيير الرموز المميزة (التراجع إلى الرمز المميز السابق).
CSI-Token-Action: يخبر التسجيل المستعرض أن رمز المستخدم الجديد لا يزال قيد التسجيل.
CSI-Token-Action: خطأ في التحقق من الرمز المميز من جانب الخادم غير صالح .

أخيرا،
يتم إرسال CSI-Salt بواسطة كل من المتصفح والخادم عند تبادل "الملح" المستخدم لحماية الرمز المميز (جزء المصادقة). انظر أدناه لمزيد من التفاصيل.

1.4 كيف يحدد العملاء المواقع؟

يمكن للموقع استخدام رمز مميز لتعريف زائر الموقع. في الوقت نفسه ، يضمن نظام إنشاء الرمز المميز وسعتهما 256 بت رموزًا فريدة لكل زوج: مجال المستخدم. سيرى مجال آخر رمز مستخدم آخر. حتى لو تم تنفيذها في سياق الموقع المستهدف (عبر IFRAME ، IMG ، LINK ، SCRIPT). بالإضافة إلى ذلك ، تقوم خوارزمية الجيل المميز الخاصة بحماية المستخدمين من هجمات XSS و SRF وتجعل من المستحيل تتبع مستخدم دون علمه. ولكن في الوقت نفسه ، تظل تقنية الدخول الموحّد (SSO) ممكنة بفضل إذنها وتحديد النطاقات المشتركة.
يتم إرسال الرمز المميز في رأس HTTP CSI-Token مع كل طلب إلى أي مورد مجال (الصفحة ، المستند ، الصورة ، البرنامج النصي ، النمط ، الخط ، الملف ، طلب ajax ، ...):

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

1.4.2 , ?

http- CSI-Support: yes Response Headers :

, , . , :

, , www.youtube.com :

.

1.5 ?

, , – . , , – «».
, , , . .

: . . - .

« » . . « »:

, , . .
, , . .
, HTTP- CSI-Token-Action , . II .

1.6 ?

( , , ) , : , , . (, . , ).

1.7

, CSI, . , . :

, . , , , . , . . . , , , . . .

, . :

. . . .
, « ». .

, :

. , . , «». , .

, -. . . , - / :

. -. . ( ).

- «» :

. . . ; . .

. «» :

( ) HEAD, CSI-Token <>; Logout.

, , Logout. , ( ). , .
: , ajax-, .. – , .

: , , . «» . .

1.8 ?

, . II .
, , CSI-Token Changed-To :

. , , . . (Response Headers) : CSI-Token-Action: success , .
(, ) CSI-Token-Action: aborted.
, CSI-Token-Action, CSI-Token Changed-To.
« » .

1.9 - ?

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

ألقِ نظرة على الموقع S ، الذي يدعم خدمة الدخول الموحّد من Google. افترض أن لديك حساب Google. لتسجيل الدخول ، انقر فوق الرابط "تسجيل الدخول باستخدام Google" ، والذي سيفتح علامة تبويب ترخيص Google. سيخبرك المتصفح أن لديك مفتاحًا لـ Google. وستخبرك Google بالحقوق التي تطلبها S.
إذا وافقت ، انقر فوق "تسجيل الدخول" في مدير المفاتيح. سيتم إعادة تحميل الصفحة. ستتلقى Google بالفعل رمزها الصحيح ، وتتعرف عليه وتفوضه. ومع طلب inter-server ، سيُبلغ الموقع S بمعلومات حسابك وفقًا للحقول المطلوبة.
ستحتوي الصفحة التي أعيد تحميلها على زر "التالي" الذي يعيدك إلى الموقع المستهدف.

في التوضيح

وسيقدم مثالًا على هذه الخوارزمية عند التسجيل على www.youtube.com باستخدام تفويض عبر المجال من خلال accounts.google.com.

قد يقرر الموقع S حفظ البيانات الخاصة بك في قاعدة البيانات الخاصة به أم لا. هذه المشكلة خارج نطاق مخطط الترخيص المقترح. ولكن علاوة على ذلك ، حيث سننظر في مخاطر فقدان مفتاح SSO ، يوصى الموقع بإبقاء الرمز المميز للمستخدم ومعرف SSO من جانبه ، وينصح المستخدم بإنشاء مفتاح دائم لـ S.

نقاط الضعف: بعد هذا الترخيص ، ستتمكن المواقع S1 و S2 و S3 و ... (حيث قمت بتسجيل الدخول عبر Google) من التعرف عليك (بواسطة المعرف الذي حددته لك Google) ونتيجة لذلك ، تتبع نشاطك.

خيار الحماية: لا تعمل في وقت واحد على المواقع إذا قمت بالتسجيل من خلال SSO للمزود نفسه. إذا كان ذلك ممكنًا ، فقم بتسجيل الخروج من خادم التخويل فور اكتمال التفويض ("الخروج التلقائي" للمجال).

1.10 كيفية تنفيذ المصادقة عبر المجال؟

كل هذا ، بالطبع ، جيد. بينما يتم تنفيذ العمل على متصفح واحد - كل شيء على ما يرام. ولكن ماذا عن الحقائق الحديثة عندما يكون لدى شخص ما هاتفان محمولان ، أحدهما يعمل على الكمبيوتر وعدة متصفحات عليه ، وجهاز كمبيوتر منزلي وجهاز كمبيوتر محمول آخر؟ بالإضافة إلى قرص مشترك للزوجة / الأطفال.
سيتعين علينا حل مشكلة نقل مفاتيح النطاق بين المتصفحات والأجهزة بطريقة أو بأخرى. وأيضا حل مسألة التزامن الصحيح.
تتمثل إحدى آليات حل هذه المشكلة في حساب مفاتيح المجال المختلفة استنادًا إلى مفتاح رئيسي مشترك دون إمكانية الاسترداد العكسي للمفتاح الرئيسي من مفتاح مجال معروف.
من خلال إنشاء مفتاح شخصي K للمجال D باستخدام المفتاح الرئيسي M على جهاز واحد ، سيكون المستخدم قادرًا على إنشاء نفس المفتاح K للمجال D وعلى أي مفتاح آخر باستخدام نفس المفتاح الرئيسي M وخوارزمية واحدة. بتعبير أدق ، لن يتم ذلك من قبل المستخدم ، ولكن بواسطة متصفحه. مع هذا النهج ، يكفي للمستخدم أن يوزع مفتاحه الرئيسي بين جميع المتصفحات المستخدمة من قبله وأنه "ينقل جميع مفاتيحه" من المجالات في وقت واحد. في الوقت نفسه يجعل النسخ الاحتياطي بهذه الطريقة.
راحة المستخدم القصوى. ولكن أيضا الحد الأقصى للمخاطر في حالة وجود حل وسط للمفتاح الرئيسي. لذلك ، يجب حماية الأخير وفقًا لذلك. يتم وصف مخاطر فقد أو اختراق المفتاح الرئيسي وطرق تقليل هذه المخاطر في الفصل "3 توصيات السلامة" .
إن استخدام مفتاح رئيسي واحد فقط لإنشاء جميع المفاتيح لجميع المجالات ليس دائمًا خيارًا مناسبًا. أولاً ، ما الذي يجب فعله إذا تم اختراق مفتاح المجال فجأة وتحتاج إلى تغيير؟ ثانياً ، ماذا لو كنت بحاجة إلى مشاركة مفتاح مجال مع شخص آخر؟ على سبيل المثال ، بين أفراد الأسرة. أم هو حساب وصول البريد العام للشركة. كيف ثم "التقاط" مفتاحك (لأنه في الواقع قد تم اختراقه)؟
لذلك ، يجب أن تدعم المتصفحات توليد مفاتيح النطاق الفردية باستخدام مستشعر الأرقام العشوائي البيولوجي. ولكن بعد ذلك ، نعود مرة أخرى إلى مسألة تنقلنا ومسائل المزامنة ووظائف تصدير المفاتيح واستيرادها في المتصفح وإنشاء نسخ احتياطية.

نقل من خلال جهاز alienable المادية

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

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

المزامنة عبر الخدمة عبر الإنترنت

"التكنولوجيا السحابية" يتم تحريكها الآن كلما كان ذلك ممكنًا. يبدو أنهم ، مع blockchain ، أصبحوا بديلاً عن "تقنية الموز". بطبيعة الحال ، هناك رغبة في استخدام منصة إنترنت معينة لتبادل المعلومات الأساسية. وهناك نوع من البطاقة الذكية "عبر الإنترنت".
ماذا؟ قمت بتسجيل الدخول باستخدام مخططنا مجهول الهوية على هذا الموقع ؛ إرسال مفاتيحك مشفرة بكلمة مرور هناك ؛ تذهب من جهاز آخر إلى نفس الموقع بنفس المفتاح / كلمة المرور ؛ تحصل على المفاتيح من هناك ؛ يمكنك مزامنة التغييرات بحلول تاريخ التحرير. على غرار مدير كلمات المرور ، هذا فقط متصل.
هذا فقط ، لا يضمن أي شخص أن الخدمة عبر الإنترنت لن يتم اختراقها أو لن تقوم بدمج المفاتيح الخاصة بك ، وإن كانت مشفرة ، عند الضرورة. من سينفذ هذه الخدمة مجانًا. هذا كل شيء.
على الرغم من أن كلمة المرور ، بالطبع ، تحمي المفاتيح من الاستخدام المباشر. ولكن هل كلمة المرور مقاومة للقوة الغاشمة "غير متصل"؟ هذا سؤال آخر.

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

يمكنك بالطبع استخدام مفتاح رئيسي لتشفير المفاتيح الأخرى. الذي تحسب به مفاتيح المجال الأخرى. كخيار.

2 الوصف الفني للبروتوكول

2.0 خوارزمية إنشاء مفتاح المجال

يحدد هذا البروتوكول طريقتين فقط لإنشاء مفاتيح المجال.

يعتمد على مولد رقم عشوائي (يفضل بيولوجي)
يعتمد على مفتاح رئيسي 256 بت

في الحالة الأخيرة ، يتم حساب مفتاح المجال على النحو التالي:

$K = HMAC_ {M_ {key}} (المجال)$

حيث

$M_ {مفتاح}$ - المفتاح الرئيسي 256 بت ، المجال - اسم المجال الذي تم صنع المفتاح من أجله.
فيما يلي ، HMAC عبارة عن خوارزمية تشفير تجزئة تستند إلى تطبيق 256 بت لوظيفة تجزئة SHA-2 .

التسوية أو الكشف الطوعي عن مفتاح المجال لا يعرض المفتاح الرئيسي الأصلي للخطر.

يوفر المفتاح الرئيسي آلية لتنقل بيانات اعتماد المستخدم.

مذكرة

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

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

$K = HMAC_ {Mkey} (إصدار المجال \ الكأس)$

فيما بعد ، الرمز

$\ كوب$ سيتم استخدامه لعملية تسلسل السلسلة (صفائف البايت).

2.1 الخوارزمية لحساب الرمز المميز المصدر

يتم حساب رمز مصادقة المستخدم مع كل طلب من أي مورد المجال. لحساب الرمز المميز للطلب ، يتم أخذ البيانات التالية:

المرسل - اسم مجال بادئ الطلب (يمكن أن يكون صفحة ذات إطار iframe أو برنامج نصي من مجال شخص آخر يقوم بالبحث) ،
المستلم - اسم مجال المستلم (حيث يتم إرسال الطلب) ،
السياق - طلب تنفيذ السياق ،
الحماية - تسلسل عشوائي من 32 بايت (256 بت) ، إذا كان السياق فارغًا ؛ فارغة خلاف ذلك

هذه البيانات متسلسلة ومقسمة بـ 256 بت SHA-2 على المفتاح K الخاص بالمجال الذي يبدأ الطلب :

$display$

يتم الحصول على رمز مميز صالح عندما لا يكون السياق فارغًا. من أجل التحديد الصحيح على الموقع المستهدف ، يجب أن يتحقق الشرط المرسل = المستلم = السياق.

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

2.2 خوارزمية حماية الرمز أثناء النقل

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

$T = Hi (T_s) \ cup HMAC_ {salt} (Lo (T_s))$

حيث

$inline$ - ارتفاع 128 بت ،

$inline$ - أقل من 128 بت من الرمز الأصلي ،

$\ كوب$ - سلسلة السلسلة. في هذه الحالة ، الرمز المميز الأولي

$inline$ يجب أن تكون معروفة بالفعل إلى الخادم.

من الناحية المثالية ، يجب أن يتغير CSI-Salt في كل مرة يطلب فيها المتصفح خادمًا. ومع ذلك ، يمكن أن يكون هذا متطلبًا مكلفًا من حيث موارد الحوسبة. بالإضافة إلى ذلك ، يمكن أن "يقتل" القدرة على إرسال طلبات متوازية إلى الخادم.
لذلك ، من أجل تحسين العمليات الحسابية ، يُسمح بالاحتفاظ بقيم CSI-Salt دون تغيير في طلبات مختلفة ، ولكن لا تزيد عن جلسة واحدة . يمكن أن يكون هذا الحد الزمني (تغيير CSI-Salt كل 5 دقائق) ، أو رد فعل على كثافة الطلبات (تغيير CSI-Salt كل 100 طلب) ، أو بعد كل سلسلة من الطلبات (في وقت الإيقاف المؤقت ، خادم العميل) ، أو إصدار مختلط. هنا يتم ترك القرار لمطوري المتصفح.
يؤدي الاحتفاظ بـ CSI-Salt دون تغيير لفترة طويلة إلى إضعاف حماية الرمز المميز المنقول ، مما يسمح للمهاجم ، عند اعتراض الرمز المميز ، باستخدامه حتى يكمل المستخدم الشرعي تسجيل الخروج ويقدم طلبًا غير مصرح به نيابة عن الضحية.

2.3 إجراء تبادل الملح بين المتصفح والخادم

2.3.1 الرمز استنادًا إلى مفتاح خادم عشوائي أو غير مسجل ^[1] .

المتصفح	الخادم
الطلب الأولي (تهيئة جلسة عمل المستخدم)
المستعرض يرسل الرمز كما هو. يفتقد طلبك CSI-Salt.	يرى الخادم أولاً رمزًا مميزًا. بالمناسبة قد لا يكون الخادم أول من يرى هذا الرمز المميز. ويعتبر المتصفح غير مسجل. يمكن أن يحدث هذا عند إعادة إنشاء المفتاح استنادًا إلى المفتاح الرئيسي على جهاز آخر . لذلك ، يجب أن يؤخذ هذا الموقف أيضًا في الاعتبار. ينظر إليها كما هي (تعتبرها غير محمية). يستخدم هذا الرمز المميز كمعرف جلسة. يولد _{الملح الخاص به} . إرجاعه في الاستجابة في رأس CSI-Salt.
الطلب الثاني
يولد الملح مع _الملح . يربط المتصفح ^[3] ملحه وملح الخادم. المستعرض يرسل الطلب ، ويمر رمز ملح مشترك. يرسل CSI- الملح.	يستقبل الخادم الطلب ويسترجع عميل CSI-Salt . يقوم الخادم بتوصيل ملح المتصفح الخاص به ويستخدمه للتحقق من الرمز المميز. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم.
الطلبات اللاحقة
المستعرض يرسل الطلب ، ويمر رمز ملح مشترك. يفتقد طلبك CSI-Salt.	يستقبل الخادم الطلب ويتحقق من الرمز المميز. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم.
بعد بعض الوقت ^[2]
يولد ملح C جديد. قم بتوصيل الملح الجديد لملح الخادم. يرسل طلبًا ، ويمرر رمزًا محميًا بواسطة ملح مشترك جديد. يرسل CSI- الملح.	يستقبل الخادم الطلب ويسترجع عميل CSI-Salt الجديد . يقوم الخادم بتوصيل ملح المتصفح الخاص به ويستخدمه للتحقق من الرمز المميز. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم.

2.3.2 الرمز استنادًا إلى المفتاح المسجل بواسطة الخادم ^[1] .

المتصفح	الخادم
الطلب الأولي (تهيئة جلسة عمل المستخدم)
يولد الملح مع _الملح . يرسل CSI- الملح. نقل الرمز المميز في نموذج محمي.	يستقبل الخادم الطلب ويسترجع عميل CSI-Salt . يقرأ رمزية محمية. يبحث عن الرمز المميز الكامل للعميل في قاعدة البيانات الخاصة به (يستخدم الرمز المميز الأول 128 بت الذي تم استلامه في طلب البحث). لأن هذا هو الطلب الأولي ، لم يرسل الخادم الملح إلى العميل ، ثم يتم التحقق من صحة الرمز المميز في هذه المرحلة فقط بواسطة ملح العميل . بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. يولد _{الملح الخاص به} . إرجاعه في الاستجابة في رأس CSI-Salt .
الطلبات اللاحقة
يجمع المتصفح بين الملح والملح الخاص به. المستعرض يرسل الطلب ، ويمر رمز ملح مشترك. يفتقد طلبك CSI-Salt .	يستقبل الخادم الطلب ويتحقق من الرمز المميز. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم.
بعد بعض الوقت ^[2]
يولد ملح C جديد. يقوم المتصفح بتوصيل الملح الجديد بملح الخادم. يرسل المستعرض الطلب ، ويمرر رمزًا محميًا بواسطة الملح المشترك الجديد. يرسل CSI- الملح .	يستقبل الخادم الطلب ويسترجع عميل CSI-Salt الجديد . يقوم الخادم بتوصيل ملح المتصفح الخاص به ويستخدمه للتحقق من الرمز المميز. إذا نجح التحقق من صحة الرمز المميز ، فإنه يوفر للمستخدم المحتوى وفقًا لحقوقه. بالنسبة لأخطاء التحقق ، تقوم بإرجاع CSI-Token-Action: رأس غير صالح إلى العميل. إرجاع المحتوى أو إرجاع استجابة فارغة: يعتمد الخادم.

^{[1] يُعد الرمز المميز غير مسجل إذا: تم إنشاؤه على أساس مفتاح عشوائي ؛} ^{لم يتم قبوله من قبل الخادم بعد إرسال التغيير إلى أو المفتاح الدائم باستخدام CSI-Token-Action: استجابة النجاح.} ^{[2] يتم تحديد الوقت الذي يتم من خلاله تغيير CSI-Salt بواسطة المتصفحات نفسها.} ^{يمكن أن يحدث هذا بعد سلسلة من الطلبات ، بعد انقضاء مهلة ، بعد عدد معين من الطلبات.} ^{– CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

. , - . .
, . , .

, ( ). . .

, . , . , , ajax- .

, . , <script>, , . , <script>, , , . <script> .

LINK, SCRIPT, IMG, IFAME , - , DOM – .

FORM, A, META , (submit, click, timeout) – .

, . , .

FORM , , INPUT, .

, , , , , , . .

. , , click ( ), submit ( ) onclick/onsubmit.

. – META http-equiv=«refresh» content=«0».

^{P. Context}

	?
	المستخدم	. JS	. JS
¹	P1. Referrer	P2. Variant ³	P3. Empty	P4. Inherit
	P5. Inherit	P6. Variant ³	P7. Empty	P8. Inherit
	P9. Empty	PA. Empty	PB. Empty	PC. Empty
	PD. Domain	PE. Variant ³	PF. Empty	PG. Variant ⁴

( SRC IMG), , , / , — , «».

^{R. Context /}

	?
	DOM Parser	. JS	. JS
²	R1. Page
	R4. Page
	R7. Empty
	RA. Referrer	RB. Page	RC. Referrer

^{[1]
[2]
[3] Inherit , Empty
[4] Inherit , Empty (. )}

Referrer – Referrer.
Page – (Tab) .
Empty – .
Domain – Context
Inherit – Context
Variant – Context «-»

P1..PF, R1..RC .

Referrer Domain . , , , .

2.5 Sender Recipient

Sender – //, . , , . ajax. . .

Recipient – , .

, .

site.net. :

site.net/css/common.css
common.css fonts.google.com/fonts/Roboto.css
Roboto.css fonts.google.com/fonts/Roboto.ttf
, img.site.net/picture1.jpg
, adriver.ru/frame
adm.site.net/admin.js

( adriver.ru) :

adriver.ru/style.css
img.adriver.ru/img/01.png
adriver.ru/libs.js
api.adriver.ru/v1/ad.js

Sender / Recipient DOM

	Sender	Recipient
site.net/css/common.css	site.net	site.net
fonts.google.com/fonts/Roboto.css	site.net	fonts.google.com
fonts.google.com/fonts/Roboto.ttf	fonts.google.com	fonts.google.com
img.site.net/picture1.jpg	site.net	img.site.net
adriver.ru/frame	site.net	adriver.ru
adm.site.net/admin.js	site.net	adm.site.net
adriver.ru/style.css	adriver.ru	adriver.ru
img.adriver.ru/img/01.png	adriver.ru	img.adriver.ru
adriver.ru/libs.js	adriver.ru	adriver.ru
api.adriver.ru/v1/ad.js	adriver.ru	api.adriver.ru

Sender / Recipient ajax-.

Sender / Recipient

		Sender	Recipient
adm.site.net/admin.js	site.net/api/	adm.site.net	site.net
adriver.ru/libs.js	adriver.ru/api/	adriver.ru	adriver.ru
api.adriver.ru/v1/ad.js	api.2gis.ru/…	api.adriver.ru	api.2gis.ru

2.6 Context

, ( ) , Context .

P1 – submit . / . . .

site.net google.com, Context (google.com). site.net ( , ).

( ) P1 , Context site.net, .. Context = Referrer.

CSRF -.

P5 – , / , ; submit , / ( FORM, INPUT). / .

P9 – , P5 , , ( ).

PD – . .

URL . .

, , , , , PG ( ). F5, , PG . Enter PD .

CSRF- .

Context, , F5 ( ). , - ( P1 ).

, site.net, , . , , … , , , site.net.

P2 – , , click/submit. , . .

, Context . , Context .

P6 – , P2 , / / .

PA – , P2 , / / .

PE – window.location.href window.open(…).

site.net , Context . Context = site.net.

ya.ru, maps.ya.ru, Context . Context , .

, – . CSRF-.

P3 – P2 , click/submit . Context ( ), ( ).

P7 – P6 , / / .

PB – PA , / / .

PF – PE , .

P4 – <META>. . . Context . PE .

P8 — <META>. / . , Context . PE . .

PC – P8 , . Context .

PG – . , , . , , . , Context .

CSRF- .

, Context .

, , ( ) HTTP- Header. , Context . – .

- -.

, - . SSO- – .

« » , - . :

;
SSO- , ;
SSO-;
SSO-, Changed-To, - ;
- «», ;
P1 , -, (, ).
-, , .

, , , . UI- :

SSO-. .

, , Context .

R1 – ( ). Context Context .

, site.net adriver.ru, img.disk.com, HTTP- img.disk.com Context , site.net.

R4 – , R1 . / , DOM Parser . , site.net/index.html site.net/require.js ( <script src=…>) site.net/min.js, main.js. Context , site.net.

R7 – , R1 . / , Context 256- . evil.com/drop.js, site.net, site.net , .. .

RA – . , site.net/css/common.css, site.net/index.html, fonts.google.com/fonts/Roboto.css, fonts.google.com Referrer = site.net/css/common.css. Context Referrer. Roboto.css Roboto.ttf, fonts.google.com/fonts/Roboto.ttf Referrer = fonts.google.com/fonts/Roboto.css. Context Referrer, .

, , Roboto.css ( ) /, CSRF- :

@import "https://site.net/api/payment?victim_params"

على أمل تلبية الطلب على site.net نيابة عن مستخدم مخول. ولكن المشكلة بالنسبة للمهاجم هي أن site.net يتوقع أن يتلقى رمز مميز من المستخدم:

$T_s ^ 1 = HMAC_k (site.net \ cup site.net \ cup site.net)$

ثم ، كما هو الحال مع طلب CSRF ، سيقوم المتصفح بإنشاء رمز مميز:

$T_s ^ 2 = HMAC_k (fonts.google.com \ cup site.net \ cup fonts.google.com)$

وسيقدم طلب إلى الموقع نيابة عن موقع مجهول ليس لديه حقوق الوصول لأداء هذه العمليات.

RB - يتم تحميل المحتوى بواسطة البرنامج النصي الخاص بالموقع. في هذه الحالة ، يتم استخدام السياق لحساب الرمز المميز للطلب ، والذي يساوي الصفحة التي تحتوي على البرنامج النصي. بالنسبة للبرنامج النصي site.net/1.js من صفحة سياق site.net ، سيكون مساوياً لسياق الصفحة نفسها.

لاحظ أن سياق الصفحة نفسها لا يساوي دائمًا اسم نطاق الصفحة ويعتمد على كيفية فتحه في الأصل.

لنفترض أن موقع المهاجم evil.com يفتح صفحة الموقع site.net الذي تمت مهاجمته ، حيث ينفذ النص site.net/util.js طلبًا باستخدام المعلمات التي تم تمريرها عبر عنوان URL للصفحة. يأمل المهاجم ، عن طريق تمرير "معلماته" عبر عنوان URL ، في فرض البرنامج النصي site.net/util.js الخاص به لتنفيذ طلب ajax لتنفيذ إجراءات مهمة نيابة عن الضحية.

لنفترض أن المستخدم نفسه ذهب إلى evil.com عبر رابط مباشر. ثم السياق ل evil.com سيكون evil.com. المزيد evil.com يفتح موقع site.net/api/payment؟victim_params النصي بنص ، على أمل تنفيذ هجوم ، ولكن حقل سياق الموقع site.net سيكون فارغًا (حالة PE / PF). النص البرمجي site.net/utils.js ، الذي ينفذ طلب ajax ، سوف يجبر المستعرض على أخذ السياق من صفحة site.net. وهو فارغ معنا. ولكن بعد ذلك سيتلقى site.net طلب ajax مع هذا الرمز المميز:

$T = HMAC_ {site.ru-key} (site.net \ cup site.net \ cup random)$

بينما بالنسبة للمستخدم المصرح له ، من المتوقع:

$T_s = HMAC_ {site.ru-key} (site.net \ cup site.net \ cup site.net)$

ستشاهد site.net رمزًا غير معروف ولن يتمكن من تحديد هوية المستخدم. عملت الحماية.

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

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

RC - يتم تحميل المحتوى بنص موقع خارجي. في هذه الحالة ، يتم استخدام السياق لحساب الرمز المميز للطلب ، وهو يساوي حقل طلب الإحالة.

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

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

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

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

لن تساعد خدعة إنشاء أو تعديل العلامة <script> في الصفحة التي تمت مهاجمتها في DOM. سيبقى حقل المصدر فارغًا.

ولكن في ظل نفس الظروف ، ستؤدي البرامج النصية الداخلية إلى استعلامات مع Source تساوي قيمتها السابقة. وإذا كانت الصفحة الأصلية تحتوي على Source = Domain ، فسيكون كل شيء على ما يرام. سيبقى المستخدم مصرحًا به لمثل هذه الطلبات.

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

نحن نصف الموقف الذي قد يقع فيه المطور. نتيجة لإجراءات المستخدم ، يعيد البرنامج النصي توجيه المستخدم المخول إلى إحدى صفحات الموقع (على سبيل المثال ، يتم ذلك عن طريق نموذج) ، مما يتطلب أن يظل المستخدم مصرحًا به. يدعو البرنامج النصي الخاص بك ، على سبيل المثال ، $ (نموذج). تقديم () باستخدام برنامج نصي jQuery تحميل من CDN. في هذه الحالة ، يرى المستعرض أنه في مكدس الاستدعاءات الذي أدى إلى حدوث حدث إرسال النموذج ، توجد وظيفة من برنامج نصي خارجي. لمنع هجمات XSS / CSRF ، يجعل المستعرض حقل المصدر فارغًا ، ويضيف وحدات بايت عشوائية لإنشاء الرمز المميز (الحالة P9 ). نتيجة لذلك ، يصبح المستخدم في الصفحة الجديدة فجأة غير مصرح به ولا يمكنه إكمال العملية. هذا يمكن أن يكون مربكا للمطورين الذين اعتادوا على استخدام CDNs.

2.7 سيناريوهات البروتوكول

فيما يلي السيناريوهات الرئيسية المحتملة للمستخدم الذي يعمل مع الموقع ، والتي تؤثر على جميع المواقف المحتملة ومراحل تنفيذها (تسجيل الدخول المجهول ، "تذكرني" ، "نسيتني" ، والتحول إلى استخدام مفتاح دائم ، إذن وخروج ، تسجيل ومصادقة ثنائية العامل ، تصدير / استيراد المفتاح ، استبدال المفتاح ، إلخ.)

1 منتدى ، مدونة ، ويكيبيديا
المستخدم	المتصفح	خادم الموقع
1.1 أول وصول إلى هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم.
1.2 عرض الصفحات.	يرسل رمزية آمنة ضد مفتاح عشوائي.	يوفر المحتوى العام. يتحقق أقل قليلا 128 بت رمزية.
1.3 محاولة القيام بإجراءات (إضافة تعليقات ، وما إلى ذلك)	يرسل رمزية آمنة ضد مفتاح عشوائي.	يخبر المستخدم أنهم يحتاجون إلى تقديم أنفسهم للنظام. في هذه المرحلة ، الموقع واثق من أن المفتاح عشوائي.
1.4 يخبر المتصفح لجعل الموقع يتذكره.	إصلاح المفتاح الحالي. يرسل مفتاح دائم. الرمز ، كما كان من قبل ، ينتقل في شكل محمي. يرسل هذا المفتاح حتى يتلقى النجاح من الخادم.	الآن يعرف الموقع أن المفتاح ثابت. يرسل CSI-Token-Action: النجاح. يمكن أن يطبق أسلوب تذكر المستخدم لفترة طويلة: إما أنه يحفظ الرمز المميز في قاعدة البيانات لاسترداد الجلسة في المستقبل مع المستخدم. أو تعقد الجلسة لفترة أطول (حفظ إلى ملف).
1.5 ينفذ الإجراءات (إضافة المشاركات والتصويت ، وما إلى ذلك)	إرسال رمز CSI آمن من مفتاح ثابت.	يسجل الإجراءات من هذا المستخدم.
1.6 يغلق علامة تبويب المتصفح.	لا تهتم.	إنه ينتظر طلبات المستخدم التالية.
1.7 يعود إلى الموقع.	يرسل مفتاح ثابت آمن.	تواصل العمل مع المستخدم. يتم أخذ بيانات الجلسة من قاعدة البيانات أو الملف المؤقت بواسطة الرمز المميز.
1.8 التراجع عن تثبيت المفتاح (نسيتني في هذا الموقع)	يرسل مفتاح الخروج	حذف بيانات المستخدم في قاعدة البيانات ، كما كان مفتاحًا ثابتًا ، ولن يتمكن المستخدم من استعادته مرة أخرى. ينهي الجلسة. لن يقوم المتصفح أبداً بإرسال مثل هذا الرمز مرة أخرى.
1.9 عند الوصول إلى الموقع لأول مرة بعد تسجيل الخروج.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	هذا الموقع مستخدم جديد بالفعل. نحن نعتبر المستخدم مجهول. نستخدم الرمز المميز كمعرف لجلسة المستخدم.
1.10 تصفح الصفحات.	يرسل رمزية آمنة ضد مفتاح عشوائي.	يوفر المحتوى العام. يتحقق أقل قليلا 128 بت رمزية.
1.11 يغلق علامة تبويب المتصفح.	لا تهتم.	يكسر جلسة بعد مهلة.
1.12 يعود إلى الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم.
1.13 ينشئ مفتاح موقع دائم.	لا تهتم.
1.14 تفعيل المفتاح الدائم.	يسأل المستخدم: هل تريد حقًا أن يتذكر الموقع مفتاحك؟ تأكد من أن هذا الموقع هو من يدعي أنه. يرسل التغيير إلى. في هذه اللحظة فقط يمرر المستعرض الرمز المميز إلى غير المحمي. في جميع الأوقات التالية ، سيقوم المتصفح دائمًا بإرسال رمز مميز محمي عند تسجيل الدخول. ولكن لهذا ، يجب أن يؤكد الموقع تغيير الرموز من خلال CSI-Token-Action: النجاح.	تذكر رمز المستخدم الجديد في قاعدة البيانات. يغير معرف الجلسة. يستمر في انتظار الطلبات من الرمز المميز الجديد. يرسل CSI-Token-Action: النجاح.
1.15 ينفذ الإجراءات (إضافة المشاركات والتصويت وما إلى ذلك)	يرسل رمزية آمنة من مفتاح دائم	يسجل الإجراءات من هذا المستخدم. للتحقق من الرمز المميز 128 بت.
1.16 يجعل "الخروج".	يرسل مفتاح الخروج	يكسر الجلسة
1.17 يعود إلى الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم الرمز المميز كمعرف لجلسة المستخدم.
1.18 تفعيل المفتاح الدائم.	يرسل التغيير إلى. الرمز محمي بالفعل ، لأن آخر مرة أجاب فيها الموقع على CSI-Token-Action: النجاح.	نقوم بتحميل بيانات المستخدم المحفوظة من قاعدة البيانات. يغير معرف الجلسة. نحن نعمل مع الرمز المميز المحفوظ. نحن نعلم أن الرمز المميز يعتمد على مفتاح دائم.
1.19 يغلق علامة تبويب المتصفح.	لا تهتم. أو مفتاح تسجيل الخروج ، إذا تم تكوين "الخروج التلقائي" عند إغلاق علامة التبويب.	يقطع الجلسة بعد انتهاء المهلة ، أو عند استلام مفتاح تسجيل الخروج.
2 متجر على شبكة الإنترنت أو موقع الإعلان
المستخدم	المتصفح	خادم الموقع
2.1 مدرج أولاً في هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم.
2.2 عرض الصفحات.	يرسل رمزية آمنة ضد مفتاح عشوائي.	يوفر المحتوى العام. يتحقق أقل قليلا 128 بت رمزية.
2.3 محاولة القيام بإجراءات (إضافة إعلانات ، عمليات شراء ، إلخ.)	يرسل رمزية آمنة ضد مفتاح عشوائي.	يخبر المستخدم أنهم يحتاجون إلى تقديم أنفسهم للنظام. في هذه المرحلة ، الموقع واثق من أن المفتاح عشوائي.
2.4 أخبر المتصفح لجعل الموقع يتذكره.	إصلاح المفتاح الحالي. قبل الطلب الأول ، يرسل رمز CSI آمن مع المفتاح الدائم. بعد تلقي النجاح ، توقف عن إرسال هذا المفتاح.	الآن يعرف الموقع أن المفتاح ثابت. يمكن أن يطبق أسلوب تذكر المستخدم لفترة طويلة: إما أنه يحفظ الرمز المميز في قاعدة البيانات لاسترداد الجلسة في المستقبل مع المستخدم. أو تعقد الجلسة لفترة أطول (عدة أيام).
2.5 ينفذ الإجراءات (إضافة الإعلانات والمشتريات ، وما إلى ذلك)	إرسال رمز CSI آمن من مفتاح ثابت.	يسجل الإجراءات من هذا المستخدم. يتحقق الرمز.
2.6 يغلق علامة تبويب المتصفح.	لا تهتم.	يحمل الجلسة. مع عدم النشاط لفترة طويلة ، فإنه يحفظ بيانات الجلسة من ذاكرة الوصول العشوائي إلى ملف أو قاعدة بيانات.
2.7 تسجيل الدخول إلى الموقع مرة أخرى.	يرسل مفتاح ثابت آمن.	تستمر الجلسة. نحن نعمل مع المستخدم ، وكأن شيئا لم يحدث.
2.8 إنشاء أو استيراد مفتاح موقع ثابت.	لا تهتم.
2.9 تفعيل المفتاح الدائم. هنا ، في الواقع ، هناك انتقال من استخدام مفتاح ثابت إلى مفتاح دائم.	يرسل مفتاح التغيير إلى. يتم نقل الرمز المميز دون حماية للمفتاح المنشأ حديثًا والرمز المميز غير مسجل على الخادم. يتم نقل الرمز المميز المحمي للمفتاح المستوردة.	2.9.A. الرمز استنادًا إلى المفتاح الجديد. إذا تم حفظ الرمز المميز القديم في قاعدة البيانات - فقط قم بتغيير الرمز المميز في قاعدة البيانات. 2.9.V. الرمز استنادًا إلى المفتاح الذي تم استيراده. إذا تم حفظ الرمز المميز القديم في قاعدة البيانات - احذفه. عند دمج ملفي تعريف لمستخدم واحد (ما يمكنك أن تسأله عنه) - لأن في الحقيقة ، لدى المستخدم رمزان مخزنان في قاعدة البيانات: من مفتاح ثابت ومن مفتاح مستورد. يغير معرف الجلسة. يرسل CSI-Token-Action: النجاح. استمر في انتظار الطلبات من الرمز المميز الجديد.
2.10 ينفذ الإجراءات (المشتريات ، نشر الإعلانات ، عربة التسوق ، المفضلات ، التعليقات ، المقارنات)	يرسل رمزية آمنة من مفتاح دائم	يسجل الإجراءات من هذا المستخدم. للتحقق من الرمز المميز 128 بت.
2.11 يغلق علامة تبويب المتصفح.	لا تهتم. أو مفتاح تسجيل الخروج ، إذا تم تكوين "الخروج التلقائي" عند إغلاق علامة التبويب.	يقطع الجلسة بعد انتهاء المهلة ، أو عند استلام مفتاح تسجيل الخروج.
3 مواقع ذات تسجيل مسبق إلزامي (شبكة اجتماعية)
المستخدم	المتصفح	خادم الموقع
3.1 المدرجة في هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم. تركنا فقط في الأقسام العامة. عندما تحاول الوصول إلى محتوى مغلق ، نترجم إلى نموذج التفويض.
3.2 إنشاء مفتاح موقع دائم	لا شيء
3.3 تفعيل المفتاح الدائم.	يسأل المستخدم: هل تريد حقًا أن يتذكر الموقع مفتاحك؟ تأكد من أن هذا الموقع هو من يدعي أنه. يرسل التغيير إلى. ينتقل الرمز في واضحة .	تذكر الرمز الجديد. نحن لسنا في عجلة من أمرنا لحفظ قاعدة البيانات حتى يتم الانتهاء من التسجيل حتى الآن. نبقي المستخدم على نموذج "التسجيل" حتى يتم تأكيد الملكية (عن طريق الهاتف ، البريد). يرسل CSI-Token-Action: التسجيل
3.4 أدخل تفاصيل الاتصال الخاصة بك.	يرسل طلبات اياكس. يرسل التغيير إلى. الرمز القديم على نفس المفتاح العشوائي. يتم الآن نقل الرمز المميز الجديد في شكل محمي . بمجرد أن يتلقى النجاح ، يستمر في استخدام رمز مميز جديد (مفتاح دائم).	الشيكات تفاصيل الاتصال. إذا نجح كل شيء ، فإنه يرسل CSI-Token-Action: النجاح. خلاف ذلك: CSI-Token-Action: التسجيل. إذا تم إرسال CSI-Token-Action: تم إحباط التسجيل ، فلن ينجح التسجيل. يجب أن يعود المتصفح إلى استخدام رقم عشوائي (إلغاء الإدخال). وأبلغ المستخدم بذلك.
3.5 ينتقل إلى القسم المغلق من الموقع	يرسل رمز آمن من مفتاح دائم.	يوفر الوصول عن طريق التحقق من الرمز المميز 128 بت.
3.6 ينفذ الإجراءات (المشتريات ، نشر الإعلانات ، عربة التسوق ، المفضلات ، التعليقات ، المقارنات)	يرسل رمز آمن من مفتاح دائم.	يسجل الإجراءات من هذا المستخدم. للتحقق من الرمز المميز 128 بت.
3.7 يغلق علامة تبويب المتصفح.	لا تهتم. أو مفتاح تسجيل الخروج ، إذا تم تكوين "الخروج التلقائي" عند إغلاق علامة التبويب.	يقطع الجلسة بعد انتهاء المهلة ، أو عند استلام مفتاح تسجيل الخروج.
3.8 المدرجة في هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم. تركنا فقط في الأقسام العامة. عندما نحاول الوصول إلى محتوى مغلق ، نعلم المستخدم أنه مستخدم مجهول.
3.9 تفعيل المفتاح الدائم.	يرسل التغيير إلى. يتم نقل كلا الرموز المميزة بطريقة آمنة.	نقوم بتحميل بيانات المستخدم من قاعدة البيانات بواسطة الرمز المميز (أعلى 128 بت). الآن يعرف الموقع من هو هذا المستخدم.
3.10 يغير المفتاح الدائم للنطاق (إلى آخر دائم)	يسأل المستخدم: هل تريد حقًا أن يتذكر الموقع مفتاحك الجديد؟ تأكد من أن هذا الموقع هو من يدعي أنه. يرسل التغيير إلى. يتم نقل الرمز المميز الجديد في مسح؛ القديم - في المحمية	تغيير الرمز المميز في قاعدة البيانات إلى واحدة جديدة. تحميل بيانات الملف الشخصي. يستخدم رمز مميز جديد من الطلبات التالية. يرسل CSI-Token-Action: النجاح
3.11 ينفذ الإجراءات (إضافة المنشورات والتصويت ، وما إلى ذلك)	يرسل رمزية آمنة من مفتاح جديد	يسجل الإجراءات من هذا المستخدم. للتحقق من الرمز المميز 128 بت.
3.12 يجعل "خروج".	يرسل مفتاح الخروج	يكسر الجلسة
3.13 المدرجة في هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم. نترجم إلى نموذج التفويض.
3.14 تفعيل مفتاح دائم	يرسل التغيير إلى. يتم نقل كلا الرموز المميزة بطريقة آمنة.	نقوم بتحميل بيانات المستخدم من قاعدة البيانات بواسطة الرمز المميز (أعلى 128 بت).
3.15 استيراد مفتاح مختلف لهذا المجال. هام: يجب أن يتم تسجيل المفتاح المستورد على الخادم.	يرسل مفتاحًا ، خروج التبديل إلى استخدام مفتاح عشوائي.	يكسر الجلسة
3.16 ينشط مفتاح جديد	يرسل التغيير إلى. يتم نقل كلا الرموز المميزة بطريقة آمنة. يرجى ملاحظة أن المفتاح "السابق" هو بالفعل مفتاح عشوائي (انظر 3.15).	يجب أن يكون هذا المفتاح معروفًا في قاعدة البيانات. يُسمح بتصدير المفتاح من المستعرض للرموز المسجلة فقط. وبالتالي ، فإن المتصفح متأكد من أن المفتاح المستورد معروف للخادم ويرسله آمنًا. خلاف ذلك ، لا يمكن أن يتعرف الخادم على رمز المستخدم ولا يمكنه تخويله.
3.17 ينفذ الإجراءات (إضافة المشاركات والتصويت وما إلى ذلك)	يرسل رمزية آمنة من مفتاح جديد	يسجل الإجراءات من هذا المستخدم. للتحقق من الرمز المميز 128 بت.
3.18 يخرج	يرسل مفتاح الخروج	يكسر الجلسة
4 مواقع مع ترخيص عاملين (Sberbank Online)
المستخدم	المتصفح	خادم الموقع
4.1 مدرجة في هذا الموقع.	يولد مفتاح عشوائي. يرسل رمزًا غير آمن من مفتاح عشوائي.	نحن نعتبر المستخدم مجهول. نستخدم هذا الرمز المميز كمعرف لجلسة المستخدم. نترجم إلى نموذج التفويض.
4.2 إنشاء مفتاح موقع دائم	لا شيء
4.3 تفعيل المفتاح الدائم.	يسأل المستخدم: هل تريد حقًا أن يتذكر الموقع مفتاحك؟ تأكد من أن هذا الموقع هو من يدعي أنه. يرسل التغيير إلى. ينتقل الرمز في واضحة .	الرمز المميز غير معروف للموقع. تذكر الرمز الجديد. . CSI-Token-Action: registration.
4.4 . «»	Change-To success. . .	. .
4.5 .	ajax-. Change-To. success, ( ).	. ( ). CSI-Token-Action: success . , CSI-Token-Action: registration. CSI-Token-Action: abort. , .
4.6 .	Token	.
4.7 «»	Logout
4.8 .	. .	. . «».
4.9 .	Change-To. (.. ; ).	( 128-). , . , . . CSI-Token-Action: success
4.10 .	ajax-. .	. . . .
4.11 .	Token .	.
4.12 «»	Logout
4.12 ().	Logout, «» . .	, Logout. .
5 : ESXi
المستخدم	المتصفح
5.1 .	. .	. . .
5.2 .
5.3 ( , ). , .
5.4 (SSH, RDP). ( .htaccess – . )
5.5
5.6 .	. .	. . .
5.7 .	Change-To. (.. , ; ).	(. ). ( 128-). 128-. . CSI-Token-Action: success. CSI-Token-Action: abort ( ), 403 – Forbidden. .
5.8	.	.
5.9	Logout, «» . .	, Logout. .
6 :
المستخدم	المتصفح
6.1 .	. .	. . . CSI-Support: yes;
6.2 .
6.3 .	: , ? , , . Change-To. .	, CSI-Token-Action: registration, .. .
6.4 / « »	/ POST- . Change-To, .	/. . . CSI-Token-Action: success
6.5 «»	Token	/. .
6.6	Logout
6.7 .	. .	. « »
6.8 .	Change-To. (.. ; ).	128- . .
6.9	Token	.
6.10	Logout

.htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory>

 cat /etc/apache2/.csi_keys

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user

2.7.1

K , «» T , . , : , . , vsphere.local, :

 Sender = Recipient = Context = vsphere.local

() , :

$T_s = HMAC_{K}(Sender \cup Recipient \cup Context)$

, . 128 , CSI-Salt ^* . , :

$T = Hi(T_s) \cup HMAC_{salt}( Lo(T_s) )$

Hi – 128 , Lo – 128 .
, , - , .. .

^{* . « ».}

2.8

( )


	, . . . 128 . . CSI-Salt.
( 128 )	. CSI-Salt – . . CSI-Token. , CSI-Token-Action: invalid. 400. – 200.

Permanent

. , , . – . CSI-Token-Action: success CSI-Token-Action: abort.

Logout

, . «» , ( ), (« »).

, , . .

Change-To

T, – '.

: T' ( , ), ( 128 ).

^*
T	T'
لا	لا	: . T' CSI-Token-Action: success. «». . ( ). CSI-Token-Action: registration, , ( ). Change-To ( ) , success abort. , , . – ( ).
لا		: Login . T' . . . CSI-Token-Action: success. . Change-To , CSI-Token-Action: success, Change-To . , . . , «» . , -. لأن « », .
	لا	: . T T'. . CSI-Token-Action: success.
,		: , , -. - . ( ). – . . CSI-Token-Action: success
, .		. . . CSI-Token-Action: abort. . 256- SHA-2. ( ) . : ; ; . , – - . , . Logout . Login . .

^{* , .}

2.9 -

, - -, . , site.ru img.site.ru, download.site.ru, .

site.ru -, . , site.ru, , - . .

, .
site.ru :

$T_1 = HMAC_{site.ru-key}(site.ru \cup site.ru \cup site.ru)$

, site.ru site.ru :

T ₁ (. R1 , R4 , RB ). site.ru.

site.ru, download.site.ru. ( R1 , R4 ):

$T_2 = HMAC_{site.ru-key}(site.ru \cup download.site.ru \cup site.ru)$

download.site.ru , ajax- site.ru ( RB , RC ).

domain :

$T_3 = HMAC_{site.ru-key}(site.ru \cup domain \cup site.ru)$

, , , A, B, C . - . , .

site.ru ajax- . ID != T ₁ , site.ru. ID T _x . ID . ID .

. , , .. site.ru .

3

تعليق

. .

3.1

, , .

.

:

( )
«» ( )

, - ( « » ), . , PIN-; .

- . : ?

, -, «», -, , , : « - ».

^* ( ). , . 100% , . , , , .

, (.. ). ( ) , – . - .

: + ( API ). « ». .

, , . , , , . : .

( ). , , .

^{*, 32- 64- . .}

3.2

. , .

. . :

, «» , , . , -, .

(), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .

, , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . أي ~10 . 5 . 10- 15 . 10 , 1-2 .

, .
, .
, . أي ( SHA-2).
, , , . .

3.3 /

-?

, . ?

, . -, -, . .

, , ? , ( « »)? « » ?

, , , . , . , (email, mobile). , (, ). , , 100% , – .

-, -.

? , . , , bitcoin. , - . . . «», .

-?
. - ( ) , , , - . , . javascript. . …

-?

. . هادئ وهادئ. . . .

. , , , – . : , . , -.

. ( ). . IP- , , .

4

4.1

, , . -, . -, - – .

, , :

( , ).
( ) .

2 : , . == .

, № 2. «» ( ), «», , . , .

№ 1. .

1 H ₁ , 2, 1 – H ₂ . , (H ₁ , H ₂ ) -.
3, 2, . 3 H ₃ , 2, 3 – H _2' != H ₂ (. ). , , .. .

, fingerprint . , .

: , . .

4.2 XSS

XSS – , victim.com . , CDN .

. - ( ), ( ), ( ).

– Source .

: XSS ( ), . «». -.

4.3 SRF

evil.com, . (GET/POST/HEAD/PUT/DELETE) , (, ). (, ). , Referer . , .

CSRF , . . , . GET- ( ) .

.

4.4 SSO

S ₁ S ₂ , , , SSO, . .. (- ), ( ), S ₁ .

A, . S ₂ , ( S ₁ ) H ₁ . . S ₁ , S ₂ .

S ₂ .

 <meta http-equiv="refresh" content="0">

.

S ₂ A «»:

, . S ₂ H ₂ (.. 2.4 P1: ).

S ₂ S ₁ , H ₁ H ₂ , H ₂ S ₁ . S ₁ S ₂ , .. .

, .. , .

: . S ₂ , . , S ₁ S ₂ . .

4.5 SSO

, SSO, . .

.

.

, SSO, SSO. , . أي SSO – .

. .

- : Id- SSO . Id SSO . , .
(. « » ).

. , , SSO, - , .

. , – . - Id- . , , , .

: ( ). . . , . , , , .

. SSO ( , ). SSO ( !).

SSO (, ), .

4.6

, 100% . ( ), . .

SSL . HTTPS . , HTTP. .

, . .

– . , . . - , .

, , , Javascript . Cookie HttpOnly. ajax- .

: , , ( ). cookie .

: , , ; ( , ).

4.7

. . : , «». - – .

, -, .

, . . , .

, -: - .

, , , , . .

, , , -, :

$DomainKey = HMAC_{M_{key}}( DomainName \cup VersionNumber )$

استنتاج

, , : « ?»

, ( ), (?) , .

, , - . , , , . ( , ). , « » «-».

- « ». , «». , . ( Google , Facebook – ). ( DDOS- . – ) - . , SSO , . ?

, , , . , - -. , ., . email, . . , . ?

-. ? SSO – .

, « ». . . . . , .

- «» . , « ». , .

-, ?

! للأسف. , «/».

1. , , popup

« cookie! , ! «», ».

popup . GDPR ( ).

. , cookie ! «». , . , +1 .

2. . SSO : OAuth, SAML, Kerberos .., , , ; - SSO, : « , ». . . , … , . = .

...

. . , - - . . . .

-, -, « » .

3. . . , . -, - . -. ?

4. , . . .

5. . XSS, CSRF. - . — .

6. . .

7. , . , , , , , , , . SQL-.

, , . «» , - . . , «-» .

– ,
.

PS
. Habr . , () . sergey201991[]. , . / . . -.

, , :

, , ;
; , SSO
«», - : - ( )
-

. 1 — , : , 1000. .

. 2 — . . , . 80- , .

, !

تحديد هوية العميل على المواقع بدون كلمات مرور وملفات تعريف الارتباط: تطبيق قياسي