تم فتح تذكرة WordPress رقم 30465 منذ 10 سنوات - هل سيكون عام 2025 هو العام الذي سيتم فيه حل هذه المشكلة أخيرًا؟

في نوفمبر/تشرين الثاني 2014، أثار مطور ووردبريس يُدعى سيرجي مولر ما بدا وكأنه مصدر قلق معقول: لم يكن لدى المستخدمين أي وسيلة لمعرفة ما إذا كان البرنامج الإضافي الذي كانوا يستخدمونه قد تمت إزالته من المستودع الرسمي - حتى لو تمت إزالته لأسباب أمنية. تم إغلاق تذكرته - رسميًا رقم 30465 - بعد فترة وجيزة نسبيًا، ولكن دون حل. ولم يكن سيرج يعلم أنه سيتم إعادة فتحه بعد عشر سنوات تقريبًا.

وها نحن، في بداية عام 2025، أكتب تحديثًا حول هذا الموضوع.

لماذا؟

لعدة أسباب.

أولاً، إنه ذو صلة كبيرة ببعض أحداث أمان المكونات الإضافية التي حدثت مؤخرًا - أكتوبر من العام الماضي على وجه الدقة. سأتحدث عن تلك قريبا. وثانيًا، اكتسبت الإرادة والزخم لحل هذه المشكلة بعض القوة الجدية - آخر نشاط على التذكرة كان قبل أقل من شهر:

لذا يبدو كما لو أن صبر سيرج قد يؤتي ثماره قريبًا...

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

من "لن يتم الإصلاح" إلى اعتلاء المسرح في WCEU 2023 🙅‍♂️

عندما تم فتح التذكرة لأول مرة، تلقت بعض الردود ولكن تم إغلاقها بسرعة كبيرة بواسطة المطور الرئيسي لـ WordPress Andrew Nacin. لقد أغلقه ووضع علامة "لن يتم إصلاحه"، موضحًا أن عمليات إزالة المكونات الإضافية حدثت لأسباب مختلفة، وليس فقط مشكلات أمنية:

كانت هناك موجة من التعليقات بعد ذلك، لكنها تلاشت بعد ذلك لتتحول إلى تعليق مرة واحدة سنويًا (وأحيانًا أقل من ذلك) لشخص يحاول إحياء القضية.

ثم، في مارس 2023 ، حدث شيء مثير للاهتمام. قام جوست دي فالك، وهو شخصية معروفة في مجتمع ووردبريس، بإعادة فتح التذكرة رسميًا . كانت حجته هي أن WordPress يتحمل مسؤولية إخبار المستخدمين ما إذا كان سيتم الحفاظ على المكون الإضافي أم لا.

وأشار أيضًا إلى أن WordPress.org كان يعرض بالفعل هذه المعلومات على المنصة نفسها، ولكن فقط بعد فترة انتظار مدتها 60 يومًا. كان اقتراحه هو جلب نفس الشفافية إلى الواجهة الخلفية لـ WordPress حيث يقوم المستخدمون فعليًا بإدارة المكونات الإضافية الخاصة بهم.

أدى ذلك إلى إطلاق موجة جديدة من الحماس عبر الموضوع. أصبحت التذكرة شائعة جدًا لدرجة أن أوليفر سيلد، الرئيس التنفيذي والمؤسس المشارك لشركة Patchstack، ذكرها في خطابه في WCEU 2023 :

ولم يذكر ذلك فحسب، بل شجع الحاضرين في WCEU على ترك تعليقات على الموضوع باستخدام رمز الاستجابة السريعة المخصص الذي أضافه إلى العرض التقديمي الخاص به. لقد استخدم أيضًا هذا القابس باعتباره زقاقًا متأخرًا للمسابقة التي سيستضيفها Patchstack في العام التالي.

حدث Patchstack في أكتوبر 2024 🪲

في أكتوبر 2024، أطلقت Patchstack حدث Bug Bounty كجزء من شهر الأمن السيبراني. إذا كان ذكر أوليفر للتذكرة رقم 30465 في خطابه في WCEU بمثابة الزقاق، فإن نتائج هذا الحدث ستكون بمثابة الضربة القاضية.

انتهى الأمر بالباحثين الأمنيين الذين شاركوا في هذا الحدث إلى اكتشاف 1571 تقريرًا صالحًا عن الثغرات الأمنية في شهر واحد. ولم تكن هذه مجرد مشكلات بسيطة أيضًا - فنحن نتحدث عن:

• 73 حالة يمكن للمهاجمين فيها تحميل ملفات ضارة
• 67 ثغرة أمنية في حقن SQL قد تؤدي إلى اختراق قواعد البيانات بأكملها.
• 58 طريقة للمهاجمين لتصعيد امتيازاتهم
• 17 ثغرة أمنية في تنفيذ التعليمات البرمجية عن بعد (نعم!)

وأدت النتائج إلى إغلاق ما يقرب من 1000 مكون إضافي مؤقتًا. وعندما حاول Patchstack الاتصال بمطوري المكونات الإضافية بشأن هذه المشكلات، لم يكن من الممكن الوصول إلى ما يقرب من 74% منهم. إما أن نماذج الاتصال الخاصة بهم معطلة، أو ارتدت رسائل البريد الإلكتروني الخاصة بهم، أو انتهت صلاحية نطاقاتهم.

المثير في الأمر هو أن العديد من هذه المكونات الإضافية الضعيفة كانت موجودة في المستودع لمدة تتراوح بين 6 و11 عامًا. بعضها يعود تاريخه إلى 17 عامًا! ونعم، لا تزال هناك مواقع ويب حية تعتمد على هذه المكونات الإضافية.

وغني عن القول أن كل هذه البيانات أعطت أوليفر نفوذًا في الموضوع لدفع التذكرة رقم 30465 للأمام نحو الاكتمال. لقد استغل ذلك بسعادة، ونشر بعض التفاصيل قبل أسبوعين من نشر منشور مدونة Patchstack الرسمي الذي يناقش الحدث:

من المناقشة إلى العمل 🛠️

كان النشاط على الموضوع يتزايد بالفعل عندما أضاف أوليفر تعليقه، لذا فإن قياس تأثيره الفردي أمر صعب. ومع ذلك، ليس من غير المعقول أن نفترض أنه أضاف الوقود إلى اللهب المتنامي. خاصة مع المستخدمين الآخرين (واحد منهم على الأقل موظف في Patchstack) يدعمون تعليقه بشكل علني.

ردًا على ذلك، أبدى المطور الرئيسي لـ WordPress Dion Hulse (@dd32) بعض المعارضة بشأن عدة نقاط، ولكنه تقدم أيضًا بشكل كبير من خلال إنشاء مكون إضافي تجريبي ينفذ الميزة التي طال انتظارها:

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

يجد أحدهم سيرج ويقول له: "ماما لقد نجحنا!"

حسنا...تقريبا.

إنها ليست جزءًا من جوهر WordPress حتى الآن، ولكنني أشعر أننا قريبون من خط النهاية هنا!

والآن بعد أن ثبت أن ذلك ممكن، فإن الخطوة التالية هي اتخاذ قرار بشأن التنفيذ النهائي. ومن ثم يمكن دمجه في WordPress core.

ما هي الخطوة التالية؟ 🎯

اعتبارًا من وقت كتابة هذه السطور، يتم النظر في تضمين الميزة في WordPress 6.8 (حسب Dion Hulse)، على الرغم من أنه لا تزال هناك بعض العقبات التي يجب التغلب عليها. وتشمل هذه:

• الانتهاء من توقيت الإشعار (هناك نقاش حول إمكانية تمديد نافذة الـ 60 يومًا).
• توحيد وثائق سبب الإغلاق.
• الموازنة بين وعي المستخدم وعبء دعم المطورين.
• تحديد الموقع الدقيق (شاشة صحة الموقع مقارنة مباشرة بالمكون الإضافي كما هو موضح في لقطة شاشة مثال المكون الإضافي).

الصورة الكبيرة 🌐

يخبرنا تطور تذكرة WordPress رقم 30465 بشيء رائع حول كيفية تغير أمان WordPress على مدار العقد الماضي. ما تم رفضه ذات مرة باعتباره حالة هامشية أصبح بالغ الأهمية بشكل متزايد مع نمو النظام البيئي وتضاعف التحديات الأمنية.

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

إذا كنت ترغب في متابعة التطوير، فاطلع على المكون الإضافي التجريبي على GitHub، أو راقب التذكرة رقم 30465. قد تكون هذه واحدة من تلك اللحظات النادرة التي نشهد فيها محادثة استمرت عقدًا من الزمن تتحول إلى نتيجة ملموسة. 💡

ما رأيك في هذه الميزة؟ هل تعتقد أنه سيكون من المفيد لك كمستخدم WordPress أن يتم إعلامك بإغلاق المكون الإضافي؟ اسمحوا لي أن أعرف في التعليقات. سوف أراك هناك.