عندما تصبح عمليات إعادة التوجيه في WordPress ثغرة أمنية تؤدي إلى تدمير الخادم
لقد قضيت سنوات في التحسين WordPress المواقع، الضبط MySQL، وإعداد إعدادات الخادم، ومحاولة التغلب على اختناقات الأداء. لكن لا شيء جهزني للاكتشاف الذي توصلت إليه عندما بدأ خادمي ينهار تحت وطأة الضغط المستمر. وحدة المعالجة المركزية: لم يكن ارتفاعًا حادًا في عدد الزيارات، ولم يكن عطلًا في أحد الإضافات، ولم يكن حتى استعلامًا سيئًا بالمعنى المعتاد. تبيّن أن السبب الحقيقي هو شيء لم أتوقعه أبدًا: طريقة إعادة توجيه ووردبريس لمطابقات ذاكرة التخزين المؤقت للإضافات.
ظاهريًا، يبدو تخزين نتائج إعادة التوجيه مؤقتًا أمرًا ذكيًا. إذا اكتشف مُكوِّن إضافي لإعادة التوجيه تطابقًا في النمط، فلماذا يُعاد تقييمه لنفس المسار؟ مع عمليات إعادة التوجيه الدقيقة من واحد إلى واحد، يكون هذا السلوك غير ضار، بل مفيدًا. ولكن بمجرد تعرض الموقع للهجوم، ودمجه مع... LIKE أو عمليات إعادة التوجيه بنمط regex، تصبح ذاكرة التخزين المؤقت لإعادة التوجيه مسؤولية شديدة لدرجة أنها قد تدمر موارد الخادم لديك بهدوء.
هذه هي قصة كيف اكتشفت هذه الثغرة الأمنية من خلال تتبع مشكلات الأداء من ارتفاعات وحدة المعالجة المركزية إلى تشبع MySQL ثم إلى عمق نمو الجدول الذي خرج عن السيطرة تمامًا.
بداية الانهيار
لقد كان خادمي يعمل بشكل أسرع من أي وقت مضى منذ الانتقال إلى فلاي دبليو بيلذا كان الارتفاع المفاجئ في استهلاك وحدة المعالجة المركزية مثيرًا للقلق. كان MySQL دائمًا يُصنف ضمن أعلى معدلات الاستخدام، PHP كان العمال ينتظرون في طوابير، وحتى تحميل الصفحات البسيطة كان بطيئًا. إعادة تشغيل الخادم منحني فترة استقرار قصيرة، ولكن في غضون ساعات, كل شيء سوف يتدهور مرة أخرى.
لقد كان هناك خطأ جوهري.
شغّلتُ تسجيل الاستعلامات بالكامل، متوقعًا العثور على عمليات ربط مكلفة أو عمليات بحث غير مفهرسة. لكن بدلًا من ذلك، ظهر نمط مفاجئ. كان عدد هائل من الاستعلامات يصل إلى جدول ذاكرة تخزين مؤقت لإعادة التوجيه أنشأته إضافات إعادة التوجيه في ووردبريس. في البداية، لم يُقلقني هذا الأمر، فحفظ مطابقات إعادة التوجيه مؤقتًا تقنية شائعة لتسريع الطلبات المستقبلية. لكن عدد الإدخالات المخزنة مؤقتًا كان يفوق بكثير ما يمكن لحركة المرور العادية تبريره.
وهذا قادني إلى حفرة الأرنب.
تتبع المشكلة إلى MySQL
كان جدول ذاكرة التخزين المؤقت لإعادة التوجيه يتضخم في الحجم. في كل مرة أتحقق منه، أجد آلاف الصفوف الإضافية. وبنظرة فاحصة، اتضح السبب: في كل مرة URL ضرب الخادم وأي قاعدة إعادة توجيه تستخدم المطابقة الجزئية—LIKE المقارنات، أو أنماط الأحرف البدل، أو التعبيرات العادية - سجل البرنامج المساعد النتيجة كإدخال جديد في ذاكرة التخزين المؤقت.
لم يكن المخترقون وأدوات الزحف يحاولون اختراق عدد قليل من عناوين URL، بل كانوا يخترقون آلاف التغييرات في الموقع بأكمله:
/random-path
/random-path1
/random-path2
/admin-old
/admin-new
/login-old
/login-backupأدى كل مسار من هذه المسارات إلى تقييم جديد لإعادة التوجيه. مع تفعيل عمليات إعادة التوجيه القائمة على الأنماط، اضطر المكون الإضافي إلى إجراء مقارنات مكلفة مع قواعد إعادة التوجيه الخاصة به. ولأنه كان يخزن كل مطابقة مؤقتًا، فقد ازداد حجم الجدول مع كل طلب من الروبوتات والماسحات الضوئية وأدوات القوة الغاشمة.
كلما كبر الجدول، زادت تكلفة كل مقارنة. لم يكن لدى MySQL أي فرصة لمواكبة هذا التطور. لم يكن الخادم مُثقلًا بحركة مرور بيانات مشروعة، بل كان مُثقلًا بتكلفة إدارة أنماط إعادة التوجيه.
الخطر الخفي لعمليات إعادة التوجيه القائمة على الأنماط
تعد جميع مكونات إعادة التوجيه الخاصة بـ WordPress بالتوافق المرن:
- إعادة توجيه أي شيء يبدأ بمسار محدد
- إعادة توجيه أي شيء ينتهي ببنية محددة
- إعادة توجيه الأنماط باستخدام الأحرف البدل
- إعادة التوجيه باستخدام الكامل رجإكس تقنية
هذه الميزات فعّالة نظريًا وغير ضارة على المواقع الصغيرة. يظهر الخطر فقط عند تعارض تخزين إعادة التوجيه ومطابقة الأنماط على نطاق واسع.
يبدو التخزين المؤقت ممارسة جيدة، ومع عمليات إعادة التوجيه الدقيقة، فهو كذلك. ولكن عندما LIKE إذا كانت هناك عوامل تشغيل أو أنماط تعبيرات عادية، فإن التخزين المؤقت يُصبح بمثابة قنبلة موقوتة. إن الجمع بين منطق البحث المكثف والمطابقة المستمرة والنمو غير المحدود في ذاكرة التخزين المؤقت يعني أن المُخترق المُصمم لا يحتاج حتى إلى استهداف عمليات إعادة التوجيه بشكل مُحدد. فحص المسارات عبر موقعك كافٍ لتعطيل خادمك.
مع اختبار المزيد من عناوين URL، يتم إنشاء المزيد من صفوف ذاكرة التخزين المؤقت. ومع إنشاء المزيد من الصفوف، تصبح كل مقارنة جديدة أبطأ. ومع تباطؤ المقارنات، يرتفع استخدام وحدة المعالجة المركزية بشكل حاد. في النهاية، يُثقل MySQL كاهله، وتتوقف خيوط PHP خلفه، وتبدأ البنية بأكملها في الانهيار.
هذا ليس عيبًا في إضافة واحدة. هكذا تعمل إضافات إعادة التوجيه في ووردبريس عمومًا عند تفعيل المطابقة المعقدة.
العثور على السبب الجذري
بعد أن ربطتُ بين تحميل الاستعلام ونشاط إعادة التوجيه في ذاكرة التخزين المؤقت، فحصتُ جدول ذاكرة التخزين المؤقت مباشرةً. لقد كبر حجمه لدرجة أن حتى العمليات الأساسية كانت بطيئة. لم يكن من غير المألوف رؤية آلاف الصفوف تُضاف في نافذة قصيرة. كل ماسح ضوئي، وزاحف، وروبوت يصطدم بمسارات غير متوقعة كان يُضيف المزيد من الإدخالات.
في هذه المرحلة، اتضحت الثغرة: تسمح إضافات إعادة التوجيه في ووردبريس للمهاجمين، دون قصد، بتكبد تكاليف باهظة من خلال فحص أعداد كبيرة من عناوين URL. لا تحتاج هذه الإضافات إلى مسارات صالحة، ولا تحتاج إلى اختراقها. كل ما تحتاجه هو إجبار منطق إعادة التوجيه على العمل.
لقد قام محرك إعادة التوجيه بالباقي.
الإصلاح
بمجرد فهمي للآلية، ظهر الحل سريعًا. مع أن اسم الجدول يختلف باختلاف الإضافة، إلا أن كل إضافة لإعادة التوجيه تحتفظ بذاكرة تخزين مؤقتة مماثلة. في هذه الحالة، أستخدم Rank Math لأمثلة أدناه:
- إزالة جميع عمليات إعادة التوجيه بنمط LIKE وregexكان لا بد من تعطيل أي قاعدة إعادة توجيه تستخدم المطابقة القائمة على الأنماط. لم يُسمح إلا لعمليات إعادة التوجيه الدقيقة (واحد لواحد) بالبقاء نشطة. ولأن المسؤول كان متجاوبًا، اضطررتُ إلى القيام بذلك عبر استعلام تحديث مباشرةً في قاعدة بياناتي.
UPDATE wp_rank_math_redirections
SET status = 'inactive'
WHERE sources NOT LIKE '%"comparison":"exact"%';- قطع جدول ذاكرة التخزين المؤقت لإعادة التوجيه:أدى مسح الجدول إلى إزالة التراكم الهائل للمطابقات المخزنة:
TRUNCATE TABLE wp_rank_math_redirections_cache;- مراقبة الخادم بعد التنظيفانخفض حمل وحدة المعالجة المركزية بشكل شبه فوري. استقر MySQL. استأنفت برامج PHP العمل بشكل طبيعي. توقف النمو الهائل.
عملت عمليات إعادة التوجيه الدقيقة كما هو متوقع تمامًا. بدون عمليات إعادة التوجيه باستخدام أحرف البدل أو التعبيرات العادية، لم تتمكن أي هجمات من إجبار ذاكرة التخزين المؤقت على النمو.
ماذا يعني هذا لمستخدمي WordPress
إضافات إعادة التوجيه في ووردبريس ليست غير آمنة بالمعنى التقليدي. لكنها تشترك في ثغرة هيكلية مشتركة: تخزين نتائج إعادة التوجيه مؤقتًا لا يكون مفيدًا إلا إذا كانت عمليات إعادة التوجيه دقيقة. بمجرد إدخال مطابقة الأنماط، يصبح التخزين المؤقت خطيرًا لأن كل عنوان URL غير معروف يصبح مدخلًا جديدًا في ذاكرة التخزين المؤقت.
في موقع ذي حركة مرور عالية أو يتم الزحف إليه بشكل كبير، يعني هذا:
- يصبح نمو الجدول غير محدود
- يصبح MySQL مثقلًا
- دوامات استخدام وحدة المعالجة المركزية
- الخادم يتباطأ أو يفشل
أفضل حماية هي بسيطة:
- لا تعتمد أبدًا على عمليات إعادة التوجيه باستخدام الأحرف البدل أو التعبيرات العادية داخل WordPress
- الحفاظ على منطق إعادة التوجيه دقيقًا كلما أمكن ذلك
- دفع قواعد إعادة التوجيه المعقدة إلى NGINX أو طبقة حافة CDN
- فحص أو مسح جداول ذاكرة التخزين المؤقت لإعادة التوجيه بشكل دوري
يُعدّ التخزين المؤقت لإعادة التوجيه مفيدًا عند استخدامه بقواعد بسيطة ودقيقة. ولكن بمجرد أن يُصاب الموقع بفحص آلي وعمليات إعادة توجيه مبنية على الأنماط، تُصبح آلية التخزين المؤقت نفسها عبئًا قد يُؤثر سلبًا على أداء الخادم.
لقد تعلمتُ هذا الدرس بصعوبة. آمل أن يُساعد هذا شخصًا آخر على تجنّب الوقوع في نفس الفخ.
