من الممكن جمع مجموعة من أسماء المستخدمين الصالحة من خلال التفاعل مع آلية المصادقة الخاصة بالتطبيق. سيكون هذا الاختبار مفيدًا لاختبار القوة الغاشمة، حيث يتحقق المختبر مما إذا كان من الممكن العثور على كلمة المرور المقابلة بالنظر إلى اسم مستخدم صالح.
غالبًا ما تكشف تطبيقات الويب عن وجود اسم مستخدم على النظام، إما نتيجة لسوء التكوين أو كقرار تصميم. على سبيل المثال، في بعض الأحيان، عندما نقدم بيانات اعتماد غير صحيحة، نتلقى رسالة تفيد بأن اسم المستخدم موجود في النظام أو أن كلمة المرور المقدمة خاطئة. يمكن للمهاجم استخدام المعلومات التي تم الحصول عليها للحصول على قائمة بالمستخدمين على النظام. يمكن استخدام هذه المعلومات لمهاجمة تطبيق الويب، على سبيل المثال، من خلال هجوم القوة الغاشمة أو هجوم اسم المستخدم وكلمة المرور الافتراضيين.
الإصلاح المقترح:
يجب أن يتصرف مربع حوار “نسيت بريدي الإلكتروني” بنفس الطريقة سواء كان البريد الإلكتروني جيدًا أو سيئًا.
تمكين المسؤول - الإعدادات - تسجيل الدخول - إخفاء البريد الإلكتروني المستخدم
إخفاء البريد الإلكتروني المستخدم
لا تُعلِم المستخدمين بوجود حساب بعنوان بريد إلكتروني معين أثناء التسجيل أو أثناء تدفق نسيان كلمة المرور. اطلب البريد الإلكتروني الكامل لطلبات “نسيت كلمة المرور”.
شكراً لكما. صادفت هذه المشكلة بشكل طبيعي على meta.discourse.org ولم أكن أعرف عن هذا الإعداد، ولكن من الجيد معرفة أن الإصلاح قد تم ترميزه بالفعل وأن التصحيح يجب أن يكون مباشرًا جدًا. لتلبية أفضل ممارسات OWASP، يجب تمكين هذا الإعداد دائمًا. لا أعرف لماذا قد يرغب أي مسؤول في تعطيله، حيث أن القيام بذلك يمثل ثغرة أمنية وخصوصية غير ضرورية تمامًا تنتهك معايير أفضل الممارسات الصناعية بشكل صريح. إذا كان هناك أي سبب للاحتفاظ بهذا الخيار للتثبيتات القديمة التي لا يمكنني فهمها، فيجب إضافة تحذير للإشارة إلى أن التكوين الحالي ينتهك معايير أفضل الممارسات الصناعية والتوصية بالتكوين المتوافق بدلاً من ذلك.
شكراً لربط هذا الموضوع. @awesomerobot يحق لهم إبداء رأيهم، لكنهم يتحدون بجرأة أفضل الممارسات القياسية للصناعة ويصرون على أن خطأ معروف جيدًا، تم الإبلاغ عنه كثيرًا وتم ترميزه صراحةً، هو بطريقة ما “ليس خطأ”، وأنا لا أجد رأيهم مقنعًا جدًا مقارنة بأفضل الممارسات القياسية المنشورة للصناعة.
إن لم يكن هناك شيء آخر، فيجب أن تعكس القيمة الافتراضية التكوين الأكثر أمانًا، ويجب أن يكون هناك بعض المؤشرات لإخبار المسؤولين المبتدئين بأن تعطيل هذا الخيار يشكل ثغرة أمنية وخصوصية متعمدة وغير ضرورية في منتداهم. رابط إلى مدخل OWASP أو شيء من هذا القبيل.
هل يمكن لأحد أن يوضح لي السيناريو الذي قد يكون من الأفضل فيه تعطيل هذا الخيار؟ أنا حقًا لا أعرف لماذا هذه قضية خلافية وأود أن أعرف ما إذا كنت أفوت أي حالة استخدام تلغي نموذج الأمان الاختياري الذي يتم تنفيذه بهذا الإعداد. إذا لم يكن من الممكن اقتراح مثل هذا السيناريو، فيجب تمكين هذا الإعداد دائمًا وبالتالي لا ينبغي أن يكون إعدادًا على الإطلاق.
أعتقد أن كل شيء يعمل كما هو متوقع حاليًا، لذلك لا يمكننا تصنيف هذا على أنه Bug. ومع ذلك، نقوم بإعادة تقييم الإعدادات الافتراضية لدينا بشكل روتيني، وقد قدمت بعض النقاط المثيرة للاهتمام التي تستحق النظر.
ببساطة… الناس سيئون في تذكر عنوان البريد الإلكتروني الذي استخدموه لإنشاء حساب، وسيتصلون بالمسؤولين لاستكشاف الأخطاء وإصلاحها.
هذا مشابه لـ فرض العامل الثاني أو الحد الأدنى لطول كلمة المرور — أعتقد أن التوصية العامة هي المطالبة دائمًا بعامل ثانٍ، ويبدو أن توصيات الحد الأدنى لطول كلمة المرور الآن أعلى من الإعداد الافتراضي الحالي للمستخدمين العاديين… ولكن هناك أيضًا فجوة بين توصيات الأمان ومهارات الكمبيوتر المتوسطة.
أنا لست ضد تغيير الإعدادات الافتراضية بقوة، ولكن تجدر الإشارة إلى أنها يمكن أن تؤثر على سهولة الاستخدام.
شكراً لكم جميعاً على مدخلاتكم ووجهات نظركم القيمة بشأن هذه الثغرة. بالنسبة لي، هذا أمر بسيط للغاية وغير معقد على الإطلاق: هناك ثغرة معروفة موجودة في Discourse تم طرحها مرارًا وتكرارًا من قبل المسؤولين والمتخصصين في الأمن مثلي، ويتم التعامل معها كميزة بدلاً من ثغرة أمنية: NIST: CWE-200: الكشف عن معلومات حساسة لجهة غير مصرح لها.
تبرير هذا التكوين الافتراضي غير الآمن الذي ينتهك أفضل الممارسات القياسية للصناعة بالاستشهاد بموقف افتراضي حيث يغرق مسؤول المنتدى باستفسارات المستخدمين حول رسائل البريد الإلكتروني التي استخدموها للتسجيل لا معنى له، حيث أن استخدام صفحة “نسيت كلمة المرور الخاصة بي” لن يستلزم هذا التفاعل الإداري بغض النظر عن تكوين هذا الإعداد: إذا تم تمكين الإعداد الأكثر أمانًا والمتوافق مع المعايير، فسيقوم المستخدم ببساطة بالتحقق من بريده الإلكتروني (رسائل البريد الإلكتروني) في مربع حوار “نسيت بريدي الإلكتروني” ويرى ما إذا كان هذا العنوان قد تلقى بريدًا إلكترونيًا لإعادة تعيين كلمة المرور، تمامًا كما هو موضح في مربع الحوار، وكما هو شائع في جميع التطبيقات الحديثة التي تحترم الخصوصية والمتوافقة مع المعايير. علاوة على ذلك، فإن تبرير هذا الانتهاك بناءً على فرضية أن مواقع أخرى قد تنتهك أيضًا أفضل الممارسات ليس حجة منطقية أو مقنعة من منظور الأمن وحماية البيانات. أجد صعوبة في فهم سبب منحنا للمسؤولين “ميزة” جعل تثبيت Discourse الخاص بهم أقل أمانًا وأقل توافقًا مع المعايير بشكل هامشي دون فائدة واضحة.
Baidu: تسمح بتعداد المستخدمين في صفحة نسيان البريد الإلكتروني، وتطبق اختبار CAPTCHA (وربما تحديد المعدل؟ لغتي الصينية سيئة). ومن المثير للاهتمام أن عملية الاسترداد تتطلب تقديم استئناف إلى فريق الإدارة، بدلاً من بريد إلكتروني بسيط للاسترداد. نموذجي جدًا للتحكم المركزي للحزب الشيوعي الصيني.
Wikipedia: لا تسمح بتعداد المستخدمين.
Yahoo: تسمح بتعداد المستخدمين عبر صفحة نسيان كلمة المرور الخاصة بها، ولكنها تطبق تحديد المعدل واختبار CAPTCHA. لم أتمكن من العثور على أمثلة لـ Yahoo متورطة في جدل أو دفع أموال للقراصنة الذين يستغلون هذه الثغرة، ولكن من الصعب جدًا البحث عن Yahoo على أي محرك بحث لأسباب واضحة.
Yandex: تسمح بتعداد المستخدمين في صفحة تسجيل الدخول، وتطبق اختبار CAPTCHA وسؤال تحدي في صفحة نسيان البريد الإلكتروني.
Whatsapp: لا تسمح بتعداد المستخدمين. تسجيل الدخول إلى الكمبيوتر الشخصي يتم عبر بيانات اعتماد الهاتف المحمول. بيانات اعتماد الهاتف المحمول مرتبطة برقم هاتفك. لا يوجد زر تسجيل خروج، ولا صفحة تسجيل دخول / نسيان بريدي الإلكتروني.
Xnxx: لا تسمح بتعداد المستخدمين. الموقع الرئيسي لا يحتوي حقًا على صفحة تسجيل دخول، والموقع “الذهبي” لا يسمح بتعداد المستخدمين. وجدت صفحة تسجيل دخول معطلة على النسخة المحمولة من الموقع العادي، وهي ببساطة لا تحتوي على وظيفة “نسيت بريدي الإلكتروني” على الإطلاق (وهي معطلة أيضًا على ما يبدو، لصالح موقعهم “الذهبي”).
Tik Tok: لا تسمح بتعداد المستخدمين. تفرض المصادقة متعددة العوامل على صفحة نسيان كلمة المرور.
(21. Reddit: لا تسمح بتعداد المستخدمين. إنها متوافقة مع أفضل الممارسات القياسية للصناعة.)
من بين أفضل 15 موقعًا في تلك القائمة، 8/15 لا تسمح بتعداد المستخدمين (أو 9/16 إذا قمت بتضمين Reddit، وربما إضافة 0.5 لـ Facebook نظرًا لأنها تسمح فقط بتعداد المعلومات التي وافق المستخدم صراحةً على جعلها عامة)، وقد واجهت 3/7 على الأقل من المواقع من تلك القائمة التي تسمح بتعداد المستخدمين أحداثًا أمنية حرجة نتيجة لهذا القرار.
ألا ينطبق ذلك على أي موقع يحتوي على صفحة تسجيل، وليس فقط موفري خدمة البريد الإلكتروني؟ يمكنني أن أفهم وجهة نظرك بشأن كيف أن صفحات التسجيل هي ناقل محتمل لنقاط ضعف مماثلة في الخصوصية والبيانات وبالتالي يجب حمايتها، ولكن هذا جزء مختلف من تدفق مصادقة المستخدم عما نناقشه في هذا الموضوع. في هذا الموضوع، نحن ننظر تحديدًا إلى التسريبات من مربع حوار “نسيت كلمة المرور الخاصة بي”. لا تفهموني خطأ: كلاهما مهم للغاية، ويتطلب اهتمامًا دقيقًا، ويتطلب تخفيفات لمنع نقاط ضعف الخصوصية والبيانات. عادةً ما تتطلب نماذج التسجيل رمزًا للتحقق (captcha)، ولنقاط نهاية “نسيت كلمة المرور الخاصة بي” تريد الحصول على نفس الاستجابة بغض النظر عما إذا كان البريد الإلكتروني صحيحًا أم خاطئًا. تؤمن العديد من المواقع أيضًا نقطة نهاية “نسيت كلمة المرور الخاصة بي” برمز تحقق (captcha). يجب تحديد معدل كلا نقطتي النهاية.
بالتأكيد لم أحاول أن أكون مخادعًا. لا أعتقد أن من المقبول عدم الامتثال لأن مواقع أخرى غير ممتثلة أيضًا هو استنتاج منطقي على أي حال، كنت فقط أفي بطلب سام وأخفف من أي مخاوف قد تكون لديه من خلال تلبية “الدليل” الذي سعى إليه باستخدام الرابط الذي قدمه.
أشجع بالتأكيد حرية المسؤولين، ولا أحب جعل حياة المسؤولين أو المستخدمين أكثر صعوبة، لكنني لا أعتقد أن “إيجابيات” هذا الإعداد تفوق “سلبياته” في أي سيناريو، ولا توجد حالة يرغب فيها المسؤول فعليًا في هذه “الميزة”. تمامًا كما لا نسمح للمسؤول بفرض حد أقصى لطول كلمة المرور، لا ينبغي لنا السماح له بتقويض أمان منتدى المستخدمين بشكل هامشي وغير ضروري من خلال السماح بنقطة ضعف التعداد هذه في مربع حوار “نسيت كلمة المرور الخاصة بي”. أعتقد أنه يجب علينا ببساطة إزالة الخيار تمامًا وإجبار الجميع على اتباع الطريقة المتوافقة مع المعايير. بصراحة، لا أعتقد أن معظم المسؤولين سيلاحظون أو يهتمون، لكن ذلك سيجعل نقطة نهاية تواجه الإنترنت العام أكثر أمانًا على جميع تثبيتات Discourse. إذا كان لا بد من تضمين الإعداد، فيجب أن يكون في الموضع الأكثر أمانًا افتراضيًا، ويجب تحديد الموضع الأقل أمانًا بوضوح حتى يفهم المسؤولون المبتدئون سبب عدم التوصية به. أعتقد أن مجرد إعادة هيكلة هذا الإعداد للخروج من الوجود هو الخيار الأفضل. سأكون سعيدًا بتقديم طلب سحب (PR) لذلك.
لا أعتقد أنه يمكنك النظر إلى أي منهما بمعزل عن الآخر. في عملية التسجيل الخاصة بـ Discourse، توجد رسالة “البريد الإلكتروني مأخوذ بالفعل” ومن الصعب رؤية كيفية القيام بذلك بشكل مختلف. طالما أن هذا موجود، فمن الصعب رؤية ما هي المشكلة الكبيرة مع رسالة “وجدنا حسابًا مطابقًا” على وجه التحديد.
أفترض أنه سيحدث فرقًا في منتدى يسمح فقط بالمصادقة الخارجية.
بعد أن تغلبت على الرغبة في الاختلاف معك لمجرد أسلوبك، أعتقد أنك على حق في جوهر الأمر إلى الحد الذي يتمثل فيه موقفك في أن الخيار الافتراضي يجب أن يكون الخيار الأكثر أمانًا، على الأقل عند استخدام المصادقة الخارجية. ما زلت لا أتفق على أنه لا يوجد مكان للخيار الأقل أمانًا (منتدى الخاص بي لديه عملية التسجيل الافتراضية لـ Discourse لذا لا أخطط لتغيير خيار إعادة تعيين كلمة المرور).
بالمناسبة، ضحكت حقيقة أنك تركت القارئ يخمن من السياق أن XVideos و Xnxx (على الرغم من عدم X) إباحية، لكنك بذلت جهدًا لشرح أن Amazon هو “موقع تجارة إلكترونية”.
كان ذلك لتمييز Amazon.com عن AWS. وبما أنك سألت: AWS لا تسمح بتعداد المستخدمين.
أتفق على أنه يجب عليك مراعاة جميع خطوات تدفق مصادقة المستخدم وكيفية عملها معًا. هذا أمر بالغ الأهمية وهو أحد أكثر مصادر الثغرات الأمنية شيوعًا. إذا لم يتم التخفيف من حدة خطأ تعداد البريد الإلكتروني المماثل هذا على صفحة التسجيل الذي ذكرته بشكل صحيح، فيجب إصلاحه بغض النظر عن نتيجة هذا الموضوع. سيكون خطأ في تنفيذ hide_email_address_taken. ربما يجب أن يتم النقاش حول هذا الخطأ/الإشراف المحتمل في موضوع مختلف (وربما مع علامة bug).
فقط للإشارة، مع تمكين إخفاء البريد الإلكتروني المأخوذ، فإنه لا يعطي هذه الرسالة عند التسجيل أيضًا (كما أنه يغير رسالة الدعوة أيضًا عند إدخال بريد إلكتروني موجود هناك).
أعتقد أن إحدى التعقيدات المحتملة لمجرد تبديل الإعداد الافتراضي هي أنه يتضمن أيضًا “طلب البريد الإلكتروني الكامل لإعادة تعيين كلمة المرور” المضمن، والذي قد يعقد الأمور بشكل مفرط (على الرغم من أنه من المحتمل ألا يكون مانعًا كاملاً).
هذا هو. مع تمكين إخفاء عنوان البريد الإلكتروني المستخدم، تحتاج إلى إدخال البريد الإلكتروني للحساب نفسه لإعادة تعيين كلمة المرور، ولا يمكنك استخدام اسم المستخدم فقط.
أقترح إعادة تسمية hide_email_address_taken SiteSetting لتصبح prevent_password_recovery_by_username، ثم إعادة هيكلة السلوك غير المتوافق خارج التطبيق لجميع المستخدمين. سيؤدي ذلك إلى الحفاظ على وظيفة إعادة تعيين كلمة المرور دون تغيير لجميع التثبيتات مع معالجة ثغرة تعداد البريد الإلكتروني. أنا مطور RoR + javascript ماهر وسأكون سعيدًا بتنفيذ طلب السحب هذا؛ لقد ألقيت نظرة سريعة على قاعدة التعليمات البرمجية وأرى أنها لن تكون طلب سحب واسع الانتشار بشكل كبير.
إذا لم يكن من الممكن حقًا إعادة هيكلة هذه “الميزة” لتختفي، فأعتقد أنه لا يزال من المنطقي فصل هذين المفهومين المرتبطين إلى إدخالات SiteSetting منفصلة.
)
