ولكن يبدو أن بروتوكولات البريد العشوائي تنشئ حسابات بقيمة لهذا القائمة المنسدلة غير قابلة للاختيار. مما يجعلها تعمل تقريبًا كـ"مصيدة نحل" (honeypot) لتحديد أي الحسابات ليست من صنع البشر. ولكن قد يكون هذا أيضًا مشكلة أمنية؟
السبب في ذلك هو أن الروبوتات لا تستخدم صفحة التسجيل الأمامية التي تحتوي على أدوات التحقق. فبدلاً من ذلك، تستخدم روبوتات البريد العشوائي طلبات POST آلية إلى نقطة نهاية واجهة برمجة تطبيقات التسجيل. كما أعتقد أنه عندما تكون الحقول اختيارية، فإن التحقق في الخلفية قد لا يكون صارمًا بما يكفي في بعض الأحيان، مما يؤدي إلى حفظ قيمة الحمولة في قاعدة البيانات.
لا أعرف بالضبط ما هو الإصلاح الجوهري، لكنك على الأرجح تحتاج أيضًا إلى إعدادات أو أدوات إضافية لمكافحة البريد العشوائي. (أستخدم روبوت مكافحة البريد العشوائي المدعوم بالذكاء الاصطناعي في منتداي العام، ويعمل بشكل ممتاز، كما أن لدي حقولًا اختيارية في التسجيل أيضًا.)
يمكنك العثور على جميع المستخدمين في منتداك باستخدام مستكشف البيانات - أعتقد أن هذا سيعمل لكنني لم أجربه بعد (بافتراض أن الحقل المخصص هو user_field_1):
SELECT user_id, value
FROM user_custom_fields
WHERE name = 'user_field_1'
AND value NOT IN ('Bro', 'Sis', '')
إذا قمت مؤخرًا بتغيير الحقل من حقل إدخال نصي إلى قائمة منسدلة، فقد يكون هذا أيضًا سببًا في وجود بعض حسابات الروبوت ذات قيم الحقل غير الصحيحة.
@Lilly على حق. لا يوجد قدر كافٍ من عدم الثقة في الخلفية هنا.
نظرًا لأن هذا الأمر قد طُرح، فقد قررت التحقق مما إذا كان يؤثر أيضًا على صفحة الملف الشخصي، وهو لا يفعل. نقوم بتنقية القيم بشكل صحيح عند تحديث المستخدمين لملفاتهم الشخصية. وهذا جعل من السهل نسبيًا نسخ منطق التنقية هذا إلى نقطة نهاية التسجيل أيضًا. يوجد طلب دمج (PR) هنا:
لا أعتقد أنه تقنيًا كذلك. نعم، يمكن للمستخدمين إدخال قيم عشوائية، لكن لا يزال يتم تطبيق التنقية قبل عرضها في أي مكان (لذا لا توجد نقطة ضعف XSS). وقد تم تطبيق حد الطول بشكل صحيح بالفعل في نقطة نهاية التسجيل أيضًا (لذا لا توجد نقطة ضعف DoS).