كيفية التحقق مما إذا كان نظام WordPress الخاص بك مؤمنًا ضد هجمات XSS

في جميع أنحاء العالم ، ما يقرب من 48 في المائة من جميع مواقع الويب عرضة للبرمجة النصية عبر المواقع (XSS). في جميع أنحاء العالم ، ما يقرب من 25 في المائة من جميع مواقع الويب تستخدم منصة WordPress.

ويترتب على ذلك أنه في مخطط Venn لمواقع الويب المعرضة لـ XSS ومواقع الويب التي تشغل منصة WordPress ، يجب أن يكون التداخل كبيرًا جدًا.

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

مقدمة في البرمجة النصية عبر المواقع

أولاً ، دعونا نناقش كيفية تنفيذ هجمات XSS. هناك أكثر من نوع واحد من هجمات XSS ، لذا سأبدأ بتعريف مبسط. بشكل عام ، تبدأ هجمات XSS بإدخالات غير صحيحة - نماذج التعليقات ومربعات التعليقات وأشرطة البحث وما إلى ذلك. تختلف هذه الهجمات على نطاق واسع في التعقيد. في الواقع ، يرى مستخدمو WordPress أبسط شكل من أشكال هجوم XSS كل يوم: تعليق البريد العشوائي. أنت تعرف ما أتحدث عنه: " شكرًا على المقال الممتاز. بالمناسبة ، ها هو موقعي حيث أجني 5000 دولار في الأسبوع من المنزل: www.only-an-idiot-would-click-this-link.co.uk. "

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

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

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

وقف الهجمات

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

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

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

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

[xhtml]
<script> CoughUpYourPreciousData () ؛ </script>
[/ xhtml]

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

يمكنك أن ترى أنه في هذا المثال ، لا تشبه سلسلة الكود أعلاه أي شيء مثل اسم شخص ما. الخادم الخاص بك لا يعرف هذا ، ولكن باستخدام بعض المعلمات المحددة ، يمكنك تعليمه. على سبيل المثال ، يمكنك إخبار هذا الحقل برفض الأحرف الخاصة ، مثل <> و () و؛ (ليست هناك حاجة إليها بشكل خاص في قسم التعليقات). يمكنك إخبار هذا الحقل أن اسم الشخص ربما لا يحتوي على أرقام فيه. إذا كنت على استعداد لأن تكون شديد القسوة ، فيمكنك إخبار هذا الحقل برفض المدخلات التي يزيد طولها عن خمسة عشر حرفًا (أو يمكنك تغيير القيم كما تريدها). سيؤدي اتخاذ هذه الخطوات إلى الحد بشكل كبير من مقدار الضرر الذي يمكن أن يحدثه المهاجم في حقل معين.

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

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

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

أساليب أخرى

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

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

هناك أيضًا عدد من المكونات الإضافية التي تزعم أنها توفر الحماية ضد هجمات XSS. أنا في الواقع لا أوصي بهذه. بدلاً من تقليل المخاطر ، تمثل العديد من هذه المكونات الإضافية مجرد سطح هجوم آخر يمكن للمتسلل استغلاله. حتى واحد من أكثر المكونات الإضافية للأمان شهرةً وانتشارًا ، Akismet ، وُجد أنه عرضة لهجمات XSS العام الماضي. عندما يتعلق الأمر بتشتيت هجمات XSS ، فلا تعتمد على أنصاف الإجراءات. طور المهارات اللازمة واستخدم مجموعة الأدوات المناسبة للحفاظ على موقع الويب الخاص بك آمنًا.

تطبيقات عملية أخرى

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

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

افكار اخيرة

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

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

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

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