(تم الإبلاغ عنه سابقًا عبر قنوات الأمان، وتم رفضه، والآن يتم الكشف عنه للجمهور باتباع عملية الإفصاح المسؤولة)
ملخص / طلب
كمستخدم، أريد أن يتم تخزين الصور المرتبطة بالروابط الساخنة المنشورة في الدردشة بواسطة الخادم، ثم يتم عرضها لي فقط لحماية عنوان IP الخاص بي من خادم استضافة صور خبيث لطرف ثالث. ما زلت أرغب في رؤية الصورة المخزنة مؤقتًا / الوكيلة، رغم ذلك!
يحتوي Discourse بالفعل على إعدادات لهذا الغرض، ولكنها لا تُطبق بشكل صحيح على الدردشة. يجب أن يؤدي تمكين كلا الإعدادين ذوي الصلة للروابط الساخنة (أدناه) إلى نفس سلوك المنتدى. أي: يتم تنزيل الصورة المستضافة من طرف ثالث إلى الخادم، ثم يتم عرضها للمستخدم فقط.
الخلفية / التأثير
في الأيام الخوالي للمنتديات على الإنترنت، كان من الشائع جدًا السماح للمستخدمين بنشر تضمينات الصور عن طريق “الربط الساخن” بخوادم طرف ثالث تستضيف الصور.
بينما كان هذا شائعًا جدًا مع المنتديات القديمة، مع تقدم الإنترنت تعلمنا أن هذه كانت ممارسة سيئة. تطورت جميع منصات التواصل الاجتماعي تقريبًا لمنع ذلك. كان جزء من السبب هو تجنب مشاكل الصور المكسورة / المفقودة، أو إرهاق الخوادم الصغيرة، ولكن هناك اعتبار أمني مهم للغاية أيضًا:
يقوم المستخدم الذي ينشر صورة من خادم خارجي بتنزيلها من الخادم المرتبط. هذا يسمح لخادم طرف ثالث خبيث بتسجيل عنوان IP للمستخدم. هذا يمثل مشكلة كبيرة لأنه إذا كان الخادم يديره مستخدم خبيث، فسيعرف الآن عنوان IP للمستخدم الآخر. (تخيل حالة يراسلك فيها مستخدم خبيث لاكتشاف عنوان IP الخاص بمنزلك)
يمكن استخدام عنوان IP المسرب من قبل شخص خبيث لـ تحديد الهوية الحقيقية للمستخدم أو لمسح جهاز التوجيه المنزلي / الكمبيوتر الخاص به بحثًا عن نقاط ضعف، وما إلى ذلك. قد تتمكن حتى من إجراء XSS به على موقع آخر إذا كان الموقع الآخر لديه أي ثغرات XSS.
لهذا السبب فإن كل شبكات التواصل الاجتماعي الرئيسية تقريبًا (Twitter، Discord، Facebook، إلخ) لم تعد تقوم بالربط الساخن للصور لأسباب أمنية. يتم الآن تخزين كل صورة لطرف ثالث على الخادم بدلاً من قيام المستخدم بسحبها مباشرة.
إعدادات Discourse ذات الصلة
يوفر Discourse إعدادين ذوي صلة:
Block hotlinked media سيستبدل الصور المرتبطة بالروابط الساخنة برابط نصي بدلاً من ذلك.
Download remote images to local سيحول الصور المرتبطة بالروابط الساخنة إلى صور مخزنة محليًا.
سلوك الإعداد في المنتدى
مع تمكين هذين الإعدادين، يبدو أن المنتدى يعمل كما هو متوقع في اختباري المحدود. يتم تحويل الصور الخارجية إلى صور محلية قبل عرضها للمستخدمين الآخرين، مما يحمي عنوان IP للمستخدم. لم أجرب هجمات توقيت مكثفة للتحقق من السلوك، ولكن على الأقل في اختباري المحدود، عمل بشكل صحيح.
(هذا ما أتوقعه لأي منصة اجتماعية حديثة، مشابه للسلوك على Twitter / Discord / Facebook إلخ)
سلوك الإعداد في الدردشة
في الدردشة، لم أتمكن من الحصول على سلوك مماثل. لا ينتج عن أي مجموعة من الإعدادات نتائج مرضية:
يؤدي تمكين كلا الإعدادين إلى تحويل الصورة البعيدة إلى رابط فقط. ومع ذلك، هناك نافذة زمنية قصيرة جدًا لا تزال فيها الصورة تُعرض للمستخدم الآخر وبالتالي يتم إجراء طلب ويب، مما يعرض عنوان IP للمستخدم للمستخدم الآخر. هذا هو أسوأ نتيجة بشكل أساسي، حيث يتم كشف عنوان IP للمستخدم ولا تحصل حتى على رؤية الصورة.
يؤدي تعطيل Block hotlinked media وتمكين Download remote images to local إلى ربط ساخن فقط؛ لم يبدو أنه يقوم بتنزيل الصورة البعيدة فعليًا. ليست ثغرة أمنية، ولكن يبدو أنها خطأ.
يؤدي تمكين Block hotlinked media وتعطيل Download remote images to local إلى نفس السلوك كما لو كان كلاهما ممكّنين. يتم عرضه كرابط بدلاً من صورة - ولكن يتم سحب الصورة أحيانًا بواسطة العميل البعيد، مما يعرض عنوان IP. (وجدت أحيانًا أنه عند إرسال الصورة لأول مرة، سيتم حظرها، ولكن في المرة الثانية لن تفعل ذلك لفترة وجيزة، أو تحدث مشاكل أخرى متعلقة بالتوقيت بشكل متكرر.)
(تمت إعادة الاختبار على نسخة تطوير من git اليوم: 3.5.0.beta8-dev (2c0635ee4c))
الإفصاح / الرد
لقد أبلغت عن هذا سابقًا (في عام 2024) عبر البريد الإلكتروني و HackerOne، ولكن قيل لي إنه ليس مشكلة أمنية وتم رفض تقرير الأمان (2844784)، للأسف. كان هذا هو البيان ذي الصلة:
شكراً لتقريرك. بعد مراجعة دقيقة، أغلق هذا لأن السلوك الموصوف هو وظيفة ويب قياسية بدلاً من ثغرة أمنية.
عندما يقوم المتصفح بتحميل أي مورد خارجي (صور، نصوص برمجية، إلخ)، فإنه يقوم بالضرورة بطلب إلى الخادم المضيف. سيشاهد هذا الخادم بشكل طبيعي عنوان IP المطلوب - هذا أمر أساسي لكيفية عمل الإنترنت ولا يعتبر ثغرة أمنية بحد ذاته. في حين يمكن اعتبار عناوين IP بيانات شخصية في بعض السياقات، فإن تعرضها من خلال طلبات الويب القياسية هو سلوك متوقع يقبله المستخدمون ضمنيًا عند تصفح الإنترنت.
تم تصميم حماية الربط الساخن في Discourse لمنع إعادة الاستخدام غير المصرح به للمحتوى المستضاف، وليس لإخفاء عناوين IP للمستخدمين من الخوادم الخارجية.
قد يكون هذا هو الاستخدام المقصود لميزة حظر الربط الساخن، ولكن أعتقد أن عدم معالجة هذا يعرض مستخدمي المكون الإضافي للدردشة للخطر - خاصة في المجتمعات الأكثر صخبًا التي قد يكون لديها مستخدمون يحاولون العثور على عنوان IP لمنزل عدو لهم وفضحهم / شن هجمات DDoS عليهم.
أعترض أيضًا على فكرة أن المستخدمين يوافقون ضمنيًا على الوصول إلى عناوين URL للروابط الساخنة غير الموثوق بها على موقع منتدى موثوق به في العصر الحديث. لن أعلق على الآثار المترتبة على اللائحة العامة لحماية البيانات / إلخ لأنني لا أعرفها، ولكن من توقع الخصوصية الأساسي، هذا غير متوقع إلا في المنتديات القديمة جدًا. بالتأكيد ليس في المنتديات الحديثة.
أبلغت عن نيتي بالنشر علنًا على هذا المنتدى بشأن المشكلة في 22 نوفمبر 2024 ولم أسمع أي شيء منذ ذلك الحين.
أنا أنشر هنا حتى يكون مسؤولو Discourse الآخرون على علم ويشجعون على تحسين حماية الربط الساخن من قبل فريق الهندسة. نظرًا لأن الوقت قد طال ولم يحدث تحسن، فإنني أنشر بحسن نية على أمل أن يؤدي الوعي وربما التشجيع المجتمعي على أهمية المشكلة إلى تحسين.
شكرا للقراءة 