الهجمات الشائعة على المواقع

من يهاجم موقعا صغيرا

خلال الأيام الثلاثة والنصف الماضية، سجل سجل هذا الموقع نفسه ٩٥٠ طلبا لم يكن أي منها يحاول قراءة صفحة. جاءت من ١٠٧ عناوين متمايزة وكان لها شكل واحد: تجرب مسارا، تتلقى ٤٠٤، تنتقل إلى المسار التالي. وفي النافذة نفسها وصل إلى هذا الخادم ٦٥٩٬٣٧٥ طلبا، فتلك الـ٩٥٠ جزء من واحد بالمئة. لكن العدد لا ينزل إلى الصفر أبدا.

لم يجلس أحد ليختار هذا الموقع. فمعظم تلك الطلبات تأتي من نطاقات عناوين مزودي السحابة لا من حاسوب منزلي: تستأجر آلة، وتسلمها قائمة نطاقات، وتمضي. وتجربة عنوان واحد تكلف ما يقارب الصفر، فلا وجود لشيء اسمه «أصغر من أن يستحق العناء».

وتوزيع تلك الطلبات الـ٩٥٠ هو الدرس نفسه.

وأطرف المجموعات ليست تلك التي تبحث عن ثغرة، بل تلك التي تبحث عن باب خلفي لشخص آخر. فأسماء مثل alfa.php وup.php وdb.php ملفات يخلفها مهاجمون سابقون على مواقع اخترقوها من قبل، والماسح يتحقق إن كان هذا الموقع مخترقا أصلا ليستفيد من عمل أنجزه سواه. ٢٥٤ طلبا من ٤٤ عنوانا، لأجل هذا السؤال وحده.

والمجموعة التالية لا تقل دلالة. ٢٥٩ طلبا كانت تبحث عن ملف إعدادات، تحت ٤٩ اسما مختلفا لملف واحد: env. وenv.backup. وenv.old. وهكذا حتى آخر القائمة. ومن كتب تلك القائمة يعلم أن المطورين يتركون نسخة من إعداداتهم بجوار الأصل، وأن هذا الملف يحمل كلمة مرور قاعدة البيانات ومفاتيح الخدمات. لا هجوم هنا؛ بل تخمين جيد لعادات البشر.

فكون الموقع صغيرا ليس دفاعا. موقعك ليس هدفا، بل سطر في قائمة، والماسح لا يعرف ما تبيعه ولا يعنيه.

تخمين كلمة المرور؛ الهجوم الذي لا يحتاج ثغرة أصلا

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

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

على هذا الموقع نفسه، سجلت الإضافة الأمنية ٢١٠ أحداث قوة غاشمة منذ مارس ٢٠٢٥ وأغلقت عنوانا ٢٢ مرة. والإعدادات الحالية: خمس محاولات فاشلة من عنوان واحد، أو عشر على اسم مستخدم واحد، داخل نافذة خمس دقائق، ثم إغلاق خمس عشرة دقيقة وقائمة سوداء سبعة أيام إن تكرر.

وفي النافذة الثلاثية نفسها كانت محاولات الدخول أوسع المجموعات انتشارا: ١٢٧ طلبا، لكن من ٤٩ عنوانا متمايزا. وللمقارنة، جاءت طلبات كشف معلومات الخادم الـ٢٣٣ من ١٠ عناوين فقط. والسبب واضح؛ تخمين كلمة مرور رخيص إلى حد يجعل الجميع يفعله.

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

وهنا يفسد الأمر عادة. فتحديد المحاولات لا يجعل كلمة المرور الضعيفة قوية؛ بل يشتري وقتا فحسب. فإن كانت كلمة مرورك في القوائم المسربة، لا يحتاج المهاجم آلاف المحاولات بل واحدة، وتحديد المحاولات لا شأن له بمحاولة واحدة. والطبقة الثانية، التي تغلق المسألة فعلا، هي التحقق بخطوتين: شيء لا يملكه المهاجم حتى بكلمة المرور الصحيحة.

حين يتحول ما كتبه المستخدم إلى أمر

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

في حقن SQL ذلك الموضع هو قاعدة البيانات. فالبرنامج يبني استعلاما ويلصق قيمة النموذج داخل نص الاستعلام؛ وإن كانت تلك القيمة نفسها تشبه جزءا من استعلام، فقاعدة البيانات لا تفرق وتنفذها. والنتيجة قراءة صفوف لم يكن يفترض أن تُرى قط.

وفي البرمجة عبر المواقع ذلك الموضع هو متصفح زائر آخر. فالنص الذي كتبه مستخدم في تعليق أو حقل ملف شخصي يُطبع بلا تغيير داخل HTML الصفحة؛ وإن أشبه ذلك النص شفرة، عدّه المتصفح شفرة، إذ لا سبيل آخر لديه للتمييز. فتُنفذ الشفرة في متصفح الضحية بالصلاحيات نفسها التي يملكها هو.

ولدفاع الاثنين منطق واحد يجلس في موضعين مختلفين.

فللقاعدة، الجواب هو الاستعلام المعامل: يُرسل شكل الاستعلام منفصلا عن القيم، فلا تستطيع قيمة أن تصير كلمة مفتاحية مهما احتوت. وفي ووردبريس هذا ما تفعله prepare. وللمتصفح، الجواب هو تهريب المخرَج: كل قيمة جاءت من مستخدم تُجعل غير ضارة لحظة طباعتها، بما يناسب الموضع الذي تحل فيه. ولووردبريس دالة لكل موضع؛ واحدة للنص المجرد، وواحدة للسمة، وواحدة للعنوان، وواحدة لنص يجب أن يبقي شيئا من HTML.

والآن الجزء الأقل كتابة والأكثر إفسادا: إغراء تنظيف المدخل مرة واحدة عند الدخول ثم الاطمئنان. يبدو أأمن وهو أسوأ، لأن صحة التهريب تتعلق بالوجهة لا بالمصدر. فالقيمة المهيأة لـHTML تخرج خاطئة يوم تدخل في سمة أو عنوان أو استجابة JSON، وقد تفتح ثقبا جديدا هناك. والقاعدة التي تصمد أمام الشفرة الحقيقية هي: خزّن البيانات كما وصلت، وهيّئها لحظة الطباعة للموضع الذي تُطبع فيه بالضبط.

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

إسقاط الموقع، والشيء الذي يشبهه تماما

لهجوم تعطيل الخدمة منطق بسيط: أرسل من الطلبات ما يكفي كي لا تجد الطلبات الحقيقية مكانا. وله شكلان ودفاعهما ليس واحدا.

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

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

والآن أصدق ما يمكن قوله في هذا الباب. أكبر سيل مرور رآه هذا الخادم لم يكن هجوما.

ففي ٨ أغسطس ٢٠٢٦ دخل زاحفان، GPTBot وmeta-externalagent، في حلقة بنتها صفحات الدخول والتسجيل في هذا الموقع بنفسها: فكل رابط يضع عنوان الصفحة الحالية داخل معامل عودة، ثم يدخل ذلك العنوان بدوره في المعامل التالي. ولم تنته الشجرة أبدا. وحين أُوقفت كان قد كُتب ١٠ غيغابايت من السجلات وبلغ القرص ٩٦ بالمئة.

وكان الحل قاعدة واحدة في إعداد خادم الويب تعرف بصمة المشكلة. فمعامل العودة السليم يُرمَّز مرة واحدة تماما، فلا تظهر داخله علامة نسبة مرمَّزة أبدا؛ فإن ظهرت، فذلك العنوان لا يمكن أن يكون قد جاء إلا من داخل الحلقة. ويُغلق مثل هذا الطلب بلا أي استجابة ولا تعمل PHP إطلاقا.

وبعد شهر ما زال النمط نفسه يصل. ففي النافذة الثلاثية التي يأخذ منها هذا الدرس أرقامه، أُغلق ٥٦٤٬٣٦٥ طلبا من أصل ٦٥٩٬٣٧٥، أي ٨٥.٦ بالمئة من كل ما وصل إلى هذا الخادم، قبل أن يبلغ PHP.

وموقفنا: ما يفصل تلك الحكاية عن هجوم حقيقي هو النية لا الأثر. فالخادم الساقط تحت الحمل لا يعنيه أجاء الحمل من سوء نية أم من قلة انتباه، ودفاع الاثنين واحد. ولهذا فإن معظم «الهجمات» التي يبلغ عنها صاحب موقع تتبين، حين تفتح السجل، زاحفا سيئ السلوك.

حين تتغير الصفحة الأولى، أين وقع الهجوم فعلا

حين تتغير الصفحة الأولى لموقع وتظهر عليها رسالة غريبة، فما تراه ليس الهجوم. بل نتيجة هجوم نجح من قبل.

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

وهذا ما يجعل استعادة النسخة الاحتياطية وحدها خطوة خاطئة. فالنسخة تعيد الموقع ولا تغلق طريق الدخول. والموقع الذي يُستعاد دون العثور على مدخله يرى الأمر نفسه غالبا خلال أيام، وعندها يستنتج صاحبه أن النسخة كانت معطوبة.

وللترتيب الصحيح ثلاث خطوات. احتفظ أولا بنسخة من الحالة المخترقة، فهي ما يبين كيف دخلوا وهي تختفي لحظة الاستعادة. ثم استعد النسخة الاحتياطية. وقبل أن تفتح الموقع من جديد، غيّر كل كلمة مرور ومفتاح كان في تلك النسخة؛ فهي لم تعد لك.

أما العلامات التي تظهر قبل تغير الصفحة الأولى فمجموعة في مقال منفصل على هذا الموقع: سبع علامات على أن موقعك معرض للاختراق.

أي من هذه الخمس يعنيك فعلا

هذه الهجمات الخمس لا تعنيك بالقدر نفسه، ولا يقول أحد ذلك صراحة لأن القائمة الكاملة تبدو أكثر احترافا.

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

وقائمة OWASP تقول الشيء نفسه. ففي نسخة ٢٠٢٥ منها يأتي التحكم المكسور في الوصول أولا، وسوء الإعداد ثانيا، والثالث بند له معنى مباشر لصاحب موقع ووردبريس: إخفاقات سلسلة توريد البرمجيات. وسلسلة توريدك هي قائمة إضافاتك. أما الحقن فانتقل من المرتبة الثالثة عام ٢٠٢١ إلى الخامسة عام ٢٠٢٥، أي أنه تقلص لا أنه انتهى.

وأكثر ما يُحدث فرقا اعتبارا من اليوم هو الدرس التالي في مسار الأمن: الترتيب الحقيقي لتحصين موقع ووردبريس. وإن كان لديك موقع ولا تعرف حاله، فتلك المراجعة والتحصين هما ما ننفذه للعملاء تحت عنوان أمن الموقع.