رفض الوصول خطأ عند محاولة تخصيص بعض نصوص الموقع

[jordan-violet]

أيضًا، بما أنني بدأت في هذا المسار، أحصل الآن على هذا عندما أحاول تعديل نصوص معينة في الموقع:

[tobiaseigen]

أنا قادر على تكرار ذلك. هذا هو عنوان URL الذي لا يعمل:

/admin/customize/site_texts?q=confirm%20old

[Moin]

@tobiaseigen

/admin/customize/site_texts?q=confirm%20old

لا أتذكر أن الرابط كان يعمل بدون معلمة locale

/admin/customize/site_texts?q=confirm%20old&locale=en يعمل بشكل جيد بالنسبة لي.

وأعتقد أن حقيقة أنك لا تستطيع تخصيص نص “تأكيد البريد الإلكتروني القديم” أمر مقصود. إنه بريد إلكتروني يُرسل فقط إلى الموظفين.

@codinghorror

ومع ذلك

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

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

ومع ذلك، نعتقد بقوة في كوننا آمنين افتراضيًا في Discourse، ونعتقد أن هناك المزيد الذي يمكننا القيام به بعد تحليل هذه القصة عن كثب. ونتيجة لذلك، قمنا للتو بتطبيق تغيير commit/9f422c93f67f156c3216a57cdf1afc0c5fc94e28 بحيث لا أحد، ولا حتى المسؤول، يمكنه تعديل قالب البريد الإلكتروني هذا بالتحديد. نعتقد أنها حالة نادرة، ولكنها تستحق المعالجة، لأن:

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

[tobiaseigen]

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

[RGJ (Richard - Communiteq)]

يبدو أن الرسالة المخصصة لا تصل إلى واجهة المستخدم؟

[Moin]

@Moin

إنه بريد إلكتروني يُرسل للموظفين فقط

لفت انتباهي أنه منذ منشور Codinghorror، تمت إضافة إعداد require change email confirmation (يتطلب تأكيد تغيير البريد الإلكتروني). هذا يعني أنه يمكن الآن إرسال الرسالة إلى أكثر من مجرد الموظفين.

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

1. استخدام كلمة المرور لإعداد المصادقة الثنائية لهذا الحساب.
2. إنشاء حساب جديد.
3. استخدام رمز المصادقة الثنائية لمنح الحساب الجديد حقوق المسؤول.

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

لذا السؤال هو: هل لا يزال حظر التعديلات على هذا القالب منطقيًا؟ يتم إرساله الآن إلى المستخدمين العاديين ولم يعد يحمي تنزيل النسخة الاحتياطية.

أيضًا، يتم الآن تثبيت Data Explorer دائمًا ويمكن استخدامه للوصول إلى قاعدة البيانات.

[zogstrip]

@Moin

وأعتقد أن حقيقة أنه لا يمكنك تخصيص نص “تأكيد البريد الإلكتروني القديم” مقصودة.

وهذا صحيح والحل هو عدم عرضها عند التصفية/البحث عنها

FIX: Filter restricted email template keys from site text search