لقد تلقينا مؤخرًا تقريرين عن اختراق مواقع Discourse، من المحتمل أن يكون ذلك بسبب كلمات مرور ضعيفة لحسابات المسؤولين. لذلك، نود توثيق ما يلي:
- ما يجب فعله عند حدوث اختراق
- ما يمكننا القيام به لتحسين الوقاية من ذلك في المستقبل
قاعدة البيانات
يرجى ملاحظة أن Discourse، لعدة سنوات حتى الآن، لديه إجراءات الحماية التالية المعمول بها حول قاعدة بيانات الموقع:
-
سيتم إرسال روابط تنزيل النسخ الاحتياطي الكامل لقاعدة البيانات فقط عبر البريد الإلكتروني الصالح لأحد مسؤولي الموقع، لذلك لا يمكنك مجرد تسجيل الدخول (عبر التنصت على الكتف، أو نسيان تسجيل الخروج)، بل يجب عليك أيضًا التحكم في عنوان البريد الإلكتروني لأحد مسؤولي الموقع. ولديك إعداد المصادقة الثنائية (2FA) لبريدك الإلكتروني، أليس كذلك؟
-
لتغيير البريد الإلكتروني للموظفين، يجب عليك التحقق من التحكم في عنوان البريد الإلكتروني القديم والجديد - بينما يحتاج المستخدم العادي فقط إلى التحقق من التحكم في عنوان البريد الإلكتروني الجديد. هذا يجعل تغيير البريد الإلكتروني لأحد أعضاء الفريق أكثر صعوبة.
-
بافتراض أنك قمت بتكوين مفتاح واجهة برمجة التطبيقات لقاعدة بيانات تحديد الموقع الجغرافي (إنه مجاني، ويتطلب التسجيل)، فسيتم تحذيرك بنشاط عندما يقوم أعضاء الفريق بتسجيل الدخول من مواقع بعيدة ماديًا عن المكان الذي سجلوا منه آخر مرة.
-
يُطلب من المسؤولين الذين لم يسجلوا الدخول لأكثر من عام إعادة التحقق من صحة عنوان بريدهم الإلكتروني، لتقليل سطح الهجوم. إعداد الموقع لهذا هو
invalidate inactive admin email after daysويتم تعيينه افتراضيًا على 365.
ومع ذلك، في حالة الاختراق، يجب عليك دائمًا افتراض أن حساب مسؤول مخادع قد قام بتنزيل نسخة كاملة من قاعدة بيانات/نسخة احتياطية للموقع.
لذلك، يجب عليك فورًا إعادة تعيين جميع كلمات مرور الحسابات باستخدام الأمر التالي:
./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'
بالإضافة إلى ذلك، يجب عليك تسجيل خروج جميع المستخدمين
./launcher enter app
rails r 'UserAuthToken.destroy_all'
أخيرًا، يجب عليك إزالة جميع مفاتيح واجهة برمجة التطبيقات (API)
./launcher enter app
rails r 'UserApiKey.destroy_all'
rails r 'ApiKey.destroy_all'
كلمات مرور الحساب في قاعدة البيانات
وفقًا لوثيقة الأمان الخاصة بنا، يستخدم Discourse تجزئات قوية جدًا وبطيئة للهجوم على كلمات المرور المخزنة في قاعدة البيانات:
يستخدم Discourse خوارزمية PBKDF2 لتشفير كلمات المرور المملحة. يتم اعتماد هذه الخوارزمية من قبل NIST. يميل خبراء الأمن على الويب إلى الاتفاق على أن PBKDF2 خيار آمن.
والحد الأدنى لطول كلمة المرور الافتراضي هو 10 للمستخدمين، و 15 للمسؤولين - وهذا يجعل من الصعب عكس تجزئات كلمات المرور بالقوة الغاشمة للحصول على التجزئة. ولكن هذا لا يمنع المستخدمين من تعيين كلمة مرور مثل password1password1 أو شيء آخر يسهل عكسه، حتى مع وجود تجزئة قوية.
رسائل البريد الإلكتروني في قاعدة البيانات
يمكن للمهاجم رؤية جميع عناوين البريد الإلكتروني لجميع المستخدمين على موقعك. هذه عادةً معلومات مميزة تتطلب من المشرفين النقر على زر للكشف عنها.
محتوى الرسائل في قاعدة البيانات
نظرًا لأن المهاجم لديه نسخة من قاعدة البيانات، يمكنه رؤية جميع المعلومات المخزنة في جميع المشاركات.
-
إذا كان لديك كلمات مرور خارجية أو معلومات حساب يتم ترحيلها في ردودك، سواء كانت خاصة أو عامة، فيجب عليك تغيير كلمات المرور هذه على الفور.
-
إذا كانت لديك معلومات حساسة في ردودك، سواء كانت خاصة أو عامة، فاعلم أن المهاجم يمكنه رؤية تلك المعلومات.
الرسائل المشفرة
إذا كنت تستخدم المكون الإضافي Discourse Encrypt، فسيتم تشفير الرسائل الخاصة من طرف إلى طرف. هذا يعني أنه إذا حدث تسرب لقاعدة البيانات، فلن يتمكن المهاجم من الوصول إلى المحتوى الموجود في الرسائل المشفرة.
اللوائح
تأكد من طلب المشورة القانونية المتخصصة بشأن متطلباتك القانونية. قد تفرض لوائح معينة مثل اللائحة العامة لحماية البيانات (GDPR) وقانون خصوصية المستهلك في كاليفورنيا (CCPA) الإفصاح.
في المستقبل
قد ترغب في طلب المصادقة الثنائية لمستخدمي الفريق إذا كان لديك سبب للاعتقاد بأن موقعك سيكون تحت الهجوم. إعداد الموقع الذي تريده هو “فرض العامل الثاني”
فرض العامل الثاني
يجبر المستخدمين على تمكين المصادقة الثنائية. اختر “الكل” لفرضها على جميع المستخدمين. اختر “الموظفين” لفرضها على مستخدمي الفريق فقط.