ليس ووردبريس غيرَ آمن. فالمواقعُ التي تعمل به تُخترَق لأربعة أسباب، بترتيب الشيوع هذا، وليس فيها واحدٌ خللًا في ووردبريس نفسه.
١. إضافةٌ لم تُحدَّث
وهو أكبر الأسباب بفارق. تُنشَر ثغرة، فيجد ماسحٌ آليّ كلَّ موقعٍ ما يزال على النسخة القديمة في أيّام، والباقي يجري آليًّا.
- شغّل التحديثَ التلقائيّ للإضافات التي تثق بها.
- واحذف ما لا تستعمله. فالإضافةُ المعطَّلة تبقى ملفًّا يمكن بلوغُه مباشرةً.
- وانظر أهُجرت الإضافةُ أم لا — فـ«آخر تحديث قبل ٣ سنوات» قرارٌ بالكفّ عن استعمالها.
٢. كلمةُ مرورٍ مستعمَلةٌ في مكانٍ آخر
تسرّبت من موقعٍ لا صلةَ له، ثمّ جُرّبت هنا. والتحقّقُ بخطوتين يجعل التسريبَ بلا أثر، ولهذا هو أثمن من أيّ إضافة.
٣. مرفوعاتٌ تُنفَّذ
فإن كان ملفٌّ موضوعٌ في wp-content/uploads يُشغَّل بوصفه PHP، صار نموذجُ الرفع بابَ دخول. سُدَّه عند الخادم لا بإضافة.
location ~* /wp-content/uploads/.*\.(php|phtml|phar)$ {
deny all;
}
٤. تحرير الملفّات من لوحة التحكّم
فالمحرّرُ المدمَج يحوّل جلسةَ إدارةٍ مسروقة إلى شفرةٍ كيفما شاء صاحبُها على خادمك. ولا يكاد أحدٌ يستعمله قاصدًا.
define('DISALLOW_FILE_EDIT', true);
وثلاثةٌ أخرى لا تكلّف شيئًا
- انقل wp-config.php فوق جذر الوِب، أو امنعه صراحةً. ففيه كلمةُ مرور قاعدة البيانات.
- أطفئ XML-RPC إلّا أن يحتاجه شيء — فهو هدفٌ شائع للتخمين بالقوّة.
- وأخفِ رقمَ الإصدار. وليس هذا أمنًا، لكنّه يُخرجك من عمليّات البحث عن «مواقع تعمل بالإصدار كذا».
وبعد أيّ اختراق، غيّر الأملاح في wp-config.php. فذلك يُبطل كلَّ جلسة، ومنها جلسةُ المهاجم، وهو الخطوةُ التي تفوت أكثرَ عمليّات التنظيف.