كشف معلومات حساسة: سر عميل OAuth2 مكشوف في إعدادات المسؤول (غير مخفي)

وصف المشكلة

خلال مراجعة أمنية لنشر Discourse المخصص لدينا، وجدنا احتمال تسرب معلومات حساسة في واجهة المسؤول

الإعدادات فيما يتعلق بأسرار عميل OAuth2.

التفاصيل

  • في صفحة تكوين المسؤول، يتم عرض سر عميل OAuth2 (وربما رموز/مفاتيح حساسة أخرى) كنص عادي، بدلاً من إخفائها (على سبيل المثال، باستخدام علامات النجمة).

  • يُطلب من المسؤولين إدخال السر العادي مباشرة في الإعدادات. يمكن لأي شخص لديه وصول إلى واجهة المسؤول رؤية السر بالكامل.

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

التأثير الأمني

  • يؤدي التعرض النصي العادي للأسرار في واجهة المسؤول إلى زيادة خطر تسرب بيانات الاعتماد.

  • عدم الإخفاء لا يتماشى مع أفضل الممارسات الأمنية للتعامل مع الأسرار.

  • يمكن إساءة استخدام الأسرار/الرموز لتصعيد الامتيازات، أو انتحال الهوية، أو لمزيد من الهجمات ضد الخدمات المتكاملة.

أسئلة

  • هل هناك خطة لإخفاء الحقول الحساسة مثل أسرار OAuth2 في واجهة إعدادات المسؤول (على سبيل المثال، عرضها كـ ****** مع خيار الكشف عنها إذا لزم الأمر)؟

  • هل هناك أساليب موصى بها أو إضافات لتعزيز حماية بيانات الاعتماد الحساسة في عمليات نشر Discourse؟

  • هل تمت مناقشة هذه المشكلة سابقًا؟ هل هناك حلول بديلة متاحة حتى يتم إصلاحها رسميًا؟

شكراً لاهتمامكم بهذا الشأن الأمني الهام!

مرحباً @Evie_Tao
أنت تبلغ عن الكثير من المخاوف الأمنية. هل فكرت في الإبلاغ عنها على HackerOne، كما هو موضح في مستودع GitHub؟

إعجابَين (2)

نحن لا نعتبر الكشف عن المعلومات للمسؤولين مشكلة، ولكن نعم يجب تمييزها على أنها حساسة لتجنب ظهورها بشكل غير ضروري، بنفس الطريقة التي يتم بها التعامل مع google_oauth2_client_secret على سبيل المثال.

هذا إصلاح بسيط:

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

ومع ذلك، يمكن تحديد أي أسرار (أي إعداد موقع حقًا) عبر البيئة، ولن تظهر بعد ذلك في واجهة إعدادات المسؤول.

(صحيح @pmusaraj؟)

إعجابَين (2)