أفضل ممارسات الأمان لبرنامج WordPress الإضافي ومطوري السمات
نشرت: 2020-12-09بصفتك مطور WordPress ، هناك العديد من القرارات التي يتعين عليك اتخاذها حول ما يجب العمل عليه. إن اهتمامك وأولويتك الأساسية هي إنشاء سمة أو مكون إضافي مذهل ، وغالبًا ما تأخذ الإجراءات الأمنية المقعد الخلفي عندما تكون في مقعد السائق للعمل على الكود. متى كانت آخر مرة جلست فيها وراجعت الكود الخاص بك لمعرفة مشكلات الأمان؟ لا ، لم أعتقد ذلك
تستند هذه النصائح إلى تجربتي من كل من تطوير المكونات الإضافية في CleverPlugins ومساعدة عدد لا يحصى من العملاء في إعادة مواقع الويب الخاصة بهم عبر الإنترنت بعد تعرضها للاختراق. إن تطوير مكون إضافي للأمان مثل WP Security Ninja لم يجعلني أقل قلقًا بشأن كود الأشخاص الآخرين.
السبب الأكثر شيوعًا لمواقع الويب التي تم اختراقها هو إدارة كلمات المرور الرديئة ، ولكن لا ينبغي أن يكون ذلك ذريعة لاستخدام بعض الطرق البسيطة التي يمكنك من خلالها حماية التعليمات البرمجية الخاصة بك.
عندما تقوم بتطوير مكون إضافي أو قالب ، فأنت تريد أن يصبح شائعًا وتثبيته على أكبر عدد ممكن من مواقع الويب. كلما زاد نجاحك ، زادت فرصة محاولة الناس إساءة استخدام عملك لاختراق مواقع الويب الخاصة بالمستخدمين.
نظرًا لشعبية WordPress ، فقد أصبح أحد أكثر الأهداف شيوعًا للمتسللين. إذا تم اكتشاف ثغرة أمنية في مكون إضافي أو سمة ، فقد يعني ذلك أن الآلاف ، إن لم يكن مئات الآلاف من مواقع الويب مفتوحة لإساءة الاستخدام.
لسوء الحظ ، تظهر ثغرة بشكل منتظم في منتج مشهور ، لذلك يجدر اتخاذ بعض الإجراءات الأمنية الأساسية لحماية شفرتك للمستخدمين.
ماذا عن فريق مراجعة WordPress.org؟
قد تعتقد أن الفريق الذي يراجع المكونات الإضافية والسمات قبل النشر على المستودع الرسمي يتحقق من جميع أنواع مشكلات الأمان ، لكن الفريق صغير ويتألف فقط من عدد قليل من الأشخاص. قائمة انتظار المكونات الإضافية والسمات التي يجب فحصها تتزايد باستمرار ، لذا فإن الوقت المتاح لمراجعة كل منها محدود.
ومع ذلك ، إذا وجدوا شيئًا ما ، فقد يغلقون المكون الإضافي الخاص بك تلقائيًا حتى تقوم بإصلاحه أو يرسل لك رسالة إلكترونية تحذر من أنه يجب عليك إصلاح ثغرة أمنية قبل إطار زمني معين.
النقطة المهمة هي أنه بمجرد إدراج المكون الإضافي أو المظهر الخاص بك في المستودع ، يمكنك دفع التحديثات عبر المستودع دون فحص إضافي ، لذلك يمكن أن تتسلل الثغرة بسهولة في أي وقت وتظل غير مكتشفة لأي فترة زمنية تقريبًا.
بشكل أساسي ، تشديد إجراءات أمان المكون الإضافي متروك لك ، لذلك دعونا نلقي نظرة على بعض الطرق التي يمكنك من خلالها حماية منتج WordPress الخاص بك ومنع نفسك من الكثير من الصداع ومن المحتمل أن يكون له تأثير سلبي على علامتك التجارية.
إليك ما يمكنك القيام به لتطوير مكون أو قالب WordPress بشكل آمن.
1. فكر في الأمن من جميع وجهات النظر!
أنت لا تعرف أبدًا من قد يستخدم المكون الإضافي أو السمة الخاصة بك وما هو مستوى فهمهم للأمان ، إن وجد على الإطلاق.
أنت لا تعرف أبدًا من قد يستخدم المكون الإضافي أو السمة الخاصة بك وما هو مستوى فهمهم للأمان ، إن وجد على الإطلاق.
قد لا يستخدم المسؤولون أو المحررون أو المستخدمون العاديون على أي موقع ويب للعميل كلمات مرور آمنة ، وقد يتم اختراق حساباتهم. إذا لم يكن منتجك مؤمنًا ، فقد يتم إساءة استخدام هذه الحسابات للحصول على وصول إضافي لتثبيت التعليمات البرمجية الضارة على موقع الويب الخاص بالعميل.
يجب ألا تتوقع من مسؤولي الخادم الذين قاموا بتكوين الخادم الذي يعمل عليه موقع الويب معرفة ما يكفي حول كيفية حماية موقع الويب الخاص بك من المواقع الأخرى على نفس الخادم. إذا تمت استضافة موقع الويب من قبل مزود كبير ، فيمكنك توقع "فصل" موقع الويب بشكل صحيح ، لكنك لا تعرف مكان تثبيت منتجك.
هل هذا يبدو بجنون العظمة؟ يمكن. ولكن ، إذا أصبح المكون الإضافي أو المظهر الخاص بك شائعًا للغاية ، فسوف يسعدك اتباع نهج جنون العظمة في الأمان.
إذا أصبح المكون الإضافي أو المظهر الخاص بك شائعًا للغاية ، فسوف يسعدك اتباع نهج بجنون العظمة تجاه الأمان.
2. منع XSS - هجمات البرمجة النصية عبر المواقع
يزداد هذا الأمر أهمية حيث أصبح WordPress مشروعًا مدفوعًا بالواجهة الأمامية مع Gutenberg و ReactJS.
أحد الأخطاء الأكثر شيوعًا لمطوري WordPress هو نسيان التحقق من صحة التعليمات البرمجية وتعقيمها - مما يتركها مفتوحة لهجمات XSS. هناك نوعان مختلفان من XSS ، ولكن بشكل عام ، يحدث هجوم XSS عندما يُسمح للمتسلل بحقن كود في الخادم ثم تنفيذه في متصفح الزائر.
تخيل أن لديك حقل إدخال. من أجل البساطة ، لنفترض أنه حقل تعليق حيث يمكن للمستخدمين أو الزوار إرسال تعليق على منشور.
سيحاول المخترق إرسال تعليق باستخدام "<script>alert('XSS');</script>" .
الآن ، هذا مجرد مثال أساسي ينبثق تنبيهًا على شاشة المستخدم ولا شيء آخر. سيستخدم المتسلل الفعلي حقل التعليق لإدخال رمز يقوم بتحميل رمز من موقعه يمكنه سرقة المعلومات من متصفح الزائر وغير ذلك الكثير.
يمكننا منع حدوث ذلك من خلال التحقق من الصحة والتعقيم والهروب.
التحقق من الصحة هو فحص البيانات المقدمة قبل القيام بأي شيء ، مثل تخزينها في قاعدة البيانات. متى تم تقديم البيانات ، يمكنك التحقق منها والتأكد من أنها مقبولة. إذا كان حقل كمية ، فإنك تتوقع رقمًا. إذا لم يكن رقمًا ، يمكنك إرجاع رسالة خطأ للمستخدم.
تعقيم البيانات هو معالجة المعلومات المقدمة والتأكد من أنها لا تحتوي على أي شيء لا نريد تخزينه ، مثل إزالة أي أحرف غير مرغوب فيها. يحتوي WordPress على العديد من الوظائف المضمنة للمساعدة في ذلك. المزيد عن التعقيم قليلاً.
الهروب يمنع أي تعليمات برمجية ضارة من التنفيذ الفعلي في متصفحك. لنفترض أن لديك بالفعل رمزًا ضارًا تم إدخاله في موقع الويب الخاص بك ، أو أن هناك مكونًا إضافيًا أو سمة أخرى تسمح للمتسللين بإدخال التعليمات البرمجية في البيانات التي تستخدمها - إن الهروب من البيانات إلى الشاشة قبل إظهارها سيمنعها من أن تكون مشكلة.
لنلقِ نظرة على نفس المثال البسيط الذي استخدمناه من قبل "<script>alert('XSS');</script>"
إذا لم نفعل أي شيء بهذه الكود ، فسيعتقد المتصفح أنه كود HTML. التفاصيل المهمة هنا هي <> الأحرف المستخدمة لتعريف علامات HTML. من خلال الهروب من هذه ، نتحول إلى & < < و > في > يفهم المتصفح الآن أن هذا ليس رمز HTML فعليًا ، ويجب أن يظهر فقط علامة أقل من وأكبر من بدلاً من ذلك.
من خلال التحقق من صحة جميع البيانات التي تدخل وتخرج من تطبيقك وتعقيمها وهروبها ، فإنك تحمي المستخدمين من إحدى طرق الهجوم الأكثر شيوعًا.
3. كن حذرا بشأن حقن SQL
كما يوحي الاسم ، يمكن للمهاجم استخدام حقن SQL لجعل موقع الويب الخاص بك يقوم بمعالجة استعلام SQL معدَّل واستخدامه للوصول إلى قاعدة البيانات الخاصة بك.
اعتمادًا على البيانات التي تخزنها على موقع الويب الخاص بك ، فإن تسريب بيانات موقع الويب الخاص بك من هجوم حقن SQL قد يتحول من كونه محرجًا إلى تدمير سمعتك وعملك تمامًا.
يعد حقن SQL طريقة قديمة لمهاجمة موقع ويب ، لكنها لا تزال فعالة للغاية وهناك العديد من الأشخاص الذين يبحثون عن طرق لاستخدام هذا النوع من الهجوم. في أكتوبر 2020 ، أعلن المكون الإضافي الشهير Loginizer WordPress عن وجود ثغرة أمنية في حقن SQL تركت أكثر من مليون موقع في خطر.
في عام 2019 ، سرق متسللون مجهولون بيانات ملايين البلغار الضريبية عبر هجوم حقن SQL ، وفي عام 2016 ، انتزعت مجموعة من المتسللين الروس معلومات الناخبين لنحو 500 ألف شخص في ولاية أوهايو. لا تزال هذه الأنواع من الهجمات فعالة للغاية ، ويمكنك العثور على الكثير من المعلومات عنها.
المصدر: https://xkcd.com/327/
المكان الأكثر شيوعًا الذي يحدث فيه إدخال SQL هو حقل نموذج يقبل إدخال المستخدم - على سبيل المثال ، الاسم. يحدث الهجوم عن طريق إدخال أجزاء من كود SQL في حقول الإدخال ، وإنشاء استعلام مخصص يعطي نتيجة مختلفة عما تتوقعه.
لنفترض أن لديك نموذجًا يسمح للأشخاص بالبحث عن اسم معين.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';
هذا المثال البسيط سوف يلتقط جميع الصفوف من جدول التعريف المنشور مع جميع الصفوف التي تحمل اسم Henry ومفتاح معين ، celebrity_name - وبهذه الطريقة ، لا نعيد قاعدة البيانات بأكملها والصفوف المعينة التي نحتاجها فقط.
سيحاول المهاجم تحليل قيمة مختلفة - على سبيل المثال 'Henry' OR 1=1--
سيعيد الاستعلام الآن جميع الصفوف ذات القيمة المحددة الخاصة بنا ، أو أي شيء آخر - نظرًا لأن OR 1=1 في SQL يكون دائمًا صحيحًا.
على الرغم من أنها تزداد سوءا. طلب استعلام SQL الخاص بنا فقط عن النتائج التي يتطابق فيها meta_key مع القيمة المعينة التي نبحث عنها ، لذلك لن نعيد كل شيء. هذا يجب أن يحد من تأثير هجوم حقن SQL ، أليس كذلك؟
حسنًا ، ليس الأمر كذلك. في SQL ، تعد الشرطة المزدوجة مؤشر تعليق ، لذلك يتم التعليق على كل ما يأتي بعد ذلك.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';
هذا يعني أن الاستعلام يبدو كالتالي:
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1
يقوم الاستعلام الآن بشكل أساسي بإرجاع كل شيء في جدول قاعدة البيانات هذا.
كان هذا مجرد مثال بسيط. هناك العديد من الطرق الأكثر تعقيدًا للوصول إلى معظم ، إن لم يكن كل ، المعلومات الموجودة في قاعدة البيانات. سيكون المهاجم قادرًا على تجربة هجمات حقن SQL العمياء ، مما يعني تشغيل التعليمات البرمجية في قاعدة البيانات الخاصة بك - إضافة مسؤول جديد ، وإزالة جميع بياناتك ، وما إلى ذلك.
ستكون معظم الهجمات في شكل سلاسل استعلام عشوائية فقط تحتوي على أجزاء من SQL يتم إرسالها إلى نماذج موقع الويب الخاص بك. ستكتشف البرامج النصية الآلية أي تغييرات في مخرجات موقع الويب الخاص بك ثم تكتشف احتمالية الهجوم.
هناك طريقة بسيطة وفعالة وهي إرسال فاصلة ' كمدخلات ومعرفة ما إذا كان يغير أي شيء ، أو حدث خطأ ، أو يتم إرجاع المزيد من النتائج.
WordPress للإنقاذ
بدلاً من التفاعل مباشرة مع قاعدة البيانات ، يجب على أي مطور استخدام فئة تجريد قاعدة البيانات المضمنة في WordPress ، $wpdb .
تحتوي فئة $wpdb في WordPress على جميع وظائف CRUD التي تحتاجها للتفاعل مع قاعدة البيانات بأمان ، ويمكنك أيضًا استخدام الفصل للتفاعل مع جداول قاعدة البيانات الخاصة بك إذا احتاج المكون الإضافي أو السمة إلى ذلك.
يمكنك حل المشكلة عن طريق توقع نوع البيانات التي يجب إدخالها بشكل معقول في كل نموذج إدخال. في مثالنا السابق ، بحثنا عن اسم. يمكننا تعقيم المدخلات للتأكد من أننا نقبل الحروف فقط. إذا كان لديك مربع تحديد أو مجموعة راديو تحتوي على خيارات قليلة فقط ، فيمكنك التحقق من البيانات للتأكد من أنها واحدة فقط من الخيارات التي تسمح بها.
أهم شيء يمكنك القيام به لحل المشكلة هو تجهيز بياناتك باستخدام الدالة $wpdb->prepare() .
تأخذ هذه الوظيفة سلسلة استعلام معدة وصفيف من الوسائط التي تريد إضافتها إلى استعلام SQL.
$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM $wpdb->postmeta WHERE meta_key = %s AND meta_value = %s",
$meta_key,
$meta_val
)
);
يتم تنفيذ جميع الأعمال داخل وظيفة prepare() . تحتوي المعلمة الأولى ، الاستعلام المعد - على العنصر النائب %s بدلاً من القيم الفعلية. يتم استبدال هذا بالمتغيرات الأخرى التي تم تحليلها ، $meta_key و $meta_val .
ملاحظة - من المهم عدم وجود فاصلة عليا في استعلامك حول العناصر النائبة ، حيث ستضيف الوظيفة تلك العناصر نيابةً عنك.
هذا مثال مبسط ، ولكن يمكن استخدام نفس العملية لأي استعلام في قاعدة البيانات ويمكنك استخدام %s للسلاسل و %d للأعداد الصحيحة و %f للعوامات.
هناك أيضًا وظائف لحالات معينة ، مثل إضافة صف جديد إلى قاعدة البيانات. لهذا الغرض يمكنك استخدام $wpdb->insert() .
$wpdb->insert(
"{$wpdb->prefix}my_custom_table",
array(
'name' => 'Henry',
'userid' => 123,
'score' => 10,
),
array(
'%s',
'%d',
'%d',
)
);
يمكن أن يساعد استخدام وظيفة التحضير في منع غالبية محاولات حقن SQL ضد منتجك.
يرجى تذكر مراجعة وثائق $ wpdb. بعض الوظائف سوف تهرب من الإدخال ؛ يتوقع الآخرون منك تجاوز الإدخال بنفسك قبل تحليل البيانات إلى الوظيفة.
4. استخدام nonces لحماية طلباتك
يمكن أن يساعدك استخدام نظام nonce في WordPress في منع العديد من الهجمات. رقم nonce من حيث الأمان هو رقم يستخدم مرة واحدة فقط. الفكرة هي إضافة هذا الرقم الفريد إلى جميع الطلبات التي تجريها من التعليمات البرمجية الخاصة بك إلى تثبيت WordPress كطريقة للتحقق من أن هذا الطلب شرعي.
إنه يشبه إلى حد ما وجود كلمة مرور سرية تحتاج إلى منحها للحارس للدخول إلى النادي
ومع ذلك ، فإن الأحرف nonces في WordPress مختلفة قليلاً - فهي ليست رقمًا ولا تستخدم مرة واحدة فقط.
من الناحية الفنية ، يمكن أن تحتوي الأحرف الصغيرة في WordPress على أحرف صغيرة وأرقام ، وبدلاً من استخدامها مرة واحدة فقط ، يتم إعادة إنشائها بعد فترة من الزمن.
الطريقة التي تستخدم بها nonce هي أن كود PHP الذي يسجل ملفات JavaScript الخاصة بك يولد مزيجًا فريدًا قليلاً من الأرقام والحروف والتحليلات بحيث يمكن أن يقرأها كود JS الخاص بك.
في كل مرة ترسل شفرة JavaScript طلبًا إلى موقع الويب الخاص بك ، يتم إرسالها مع هذا الجزء من الشفرة ، وإذا لم تتطابق الشفرة ، فيجب أن تتجاهل التعليمات البرمجية الخاصة بك الطلب تمامًا.
دائمًا ما يكون الأمر أسهل قليلاً مع وجود مثال ، لذلك دعونا نرى طريقة بسيطة لتحميل ملف .js في المكون الإضافي الخاص بك باتباع الخطوات التالية:
استخدام الرموز غير الرسمية في مكون WordPress الإضافي
add_action('wp_enqueue_scripts', 'load_my_plugin_script');
function load_my_plugin_script() {
// Register the script with all details and ensures it is loaded after jQuery
wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );
// Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
wp_localize_script(
'secure-plugin',
'plugin_ajax_object',
array(
'nonce' => wp_create_nonce('secure-plugin-nonce')
)
);
// Once that is done, we can now enqueue the script
wp_enqueue_script('secure-plugin');
}
في هذه الوظيفة ، نطلب من WordPress تحميل ملف JavaScript. أولاً ، نسجل الملف الذي نريد تحميله باستخدام wp_register_script() .
ثم نستخدم wp_localize_script() لتحليل مجموعة من البيانات ، على وجه الخصوص "nonce" التي تحتوي على nonce الفريد الذي نريد استخدامه في كود JS الخاص بنا. تذكر أنه يمكنك إرسال جميع أنواع المعلومات الأخرى في هذه المصفوفة أيضًا ، لكننا نبقيها بسيطة في هذا المثال.
عندما ترسل طلبًا من ملف JavaScript الخاص بك ، فأنت بحاجة إلى تضمين ذلك nonce الفريد. القيام بذلك سهل:
استخدام البرنامج المساعد nonce من WordPress في ملف JavaScript
jQuery(document).ready(function($) {
$.ajax({
url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
type: 'POST',
data: {
'action': 'get_custom_data',
'_ajax_nonce': plugin_ajax_object.nonce,
'user_data': 'Some input from a user'
},
success: function( response ) {
// Here we do what happens if all is good - update the interface with a success message!?
},
error: function( response ) {
// Whooops, something went wrong!
// console.log(response);
}
});
});
نظرًا لأننا استخدمنا wp_localize_script() ، يمكننا استخدام متغير plugin_ajax_object في JavaScript. نرسل nonce كمتغير ، _ajax_nonce .
تحقق من رقم nonce في مكون WordPress الإضافي وتحقق منه من كود JavaScript
add_action('wp_ajax_get_custom_data', 'get_custom_data');
function get_custom_data() {
// Ready for the magic to protect your code?
check_ajax_referer('secure-plugin-nonce');
/**
* That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
*
* If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
* if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {
* wp_send_json_error( 'Invalid nonce' );
* }
*/
$sanitized_user_data = sanitize_text_field( $_POST['user_data'] );
// ... continue with the rest of your plugin's function code ...
}
يحدث السحر مع الوظيفة check_ajax_referer() التي تتحقق من nonce وتفشل ببساطة وتوقف أي تنفيذ إضافي للكود إذا كان nonce لا يتطابق مع ما كان متوقعًا.
يمكنك تخصيص الكود بشكل أكبر لإعادة معلومات محددة للمستخدم حول ما حدث.
يعد استخدام الرموز غير الرسمية في التعليمات البرمجية الخاصة بك طريقة سريعة وسهلة وفعالة لمنع أنواع عديدة من محاولات القرصنة. هذا لا يعني أنه يمكنك تخطي القيام بجميع الإجراءات الأمنية الأخرى ، ولكنه يساعد في تقليل أسوأ المشاكل.
تذكر ما قلته عن عدم الثقة بأحد؟ يقودنا ذلك إلى طريقة أخرى لحماية شفرتك - التعقيم.
اشترك واحصل على نسخة مجانية من كتابنا
11 أسلوبًا مثبتًا لزيادة منازعات بطاقة الائتمان الخاصة بك ، حقق معدل نجاح بنسبة 740٪
شارك مع صديق
أدخل عنوان البريد الإلكتروني لصديقك. سنرسل لهم هذا الكتاب بالبريد الإلكتروني فقط ، شرف الكشافة.
شكرا لك للمشاركة
رائع - تم إرسال نسخة من "11 أسلوبًا مثبتًا لزيادة منازعات بطاقة الائتمان الخاصة بك ومعدل النجاح بنسبة 740٪" إلى . هل تريد مساعدتنا في نشر الكلمة أكثر؟ استمر وشارك الكتاب مع أصدقائك وزملائك.
شكرا على الإشتراك!
- لقد أرسلنا للتو نسختك من "11 تقنية مثبتة لزيادة معدل نجاح نزاعات بطاقة الائتمان الخاصة بك بنسبة 740٪" إلى .
هل لديك خطأ مطبعي في بريدك الإلكتروني؟ انقر هنا لتعديل عنوان البريد الإلكتروني وإرساله مرة أخرى.
5. تعقيم مدخلات المستخدم
في المثال السابق ، قمنا بتضمين جزء إضافي من البيانات المرسلة من JS إلى PHP. في كل مرة تقوم فيها بإدخال بيانات في التعليمات البرمجية الخاصة بك ، يجب أن تتوقع أن تكون غير آمنة.
'user_data':'Some input from a user'
في هذا المثال ، إنها سلسلة بسيطة ، ولكن نظرًا لأننا نرسل البيانات مرة أخرى إلى PHP ، نحتاج إلى التأكد من أن الإدخال لا يحتوي على أي كود يمكن استغلاله في بيئة PHP الخاصة بنا أو تخزينه في قاعدة البيانات مما يسمح بمزيد من إساءة الاستخدام.
يأتي التطهير. يحتوي WordPress على مجموعة من الوظائف التي تأخذ أي مدخلات تقدمها وتنظف البيانات قبل إعادتها إليك.
في هذا المثال ، استخدمنا الوظيفة sanitize_text_field() ، لكن WordPress يأتي بالعديد من وظائف التعقيم المناسبة لأنواع مختلفة من البيانات.
هناك العديد من الوظائف والطرق الرائعة الأخرى المضمنة في WordPress والتي يمكنك استخدامها للحفاظ على أمان التعليمات البرمجية الخاصة بك ومنع إساءة الاستخدام.
يجب ألا تستخدم أبدًا أي بيانات يتم إرسالها إلى التعليمات البرمجية الخاصة بك دون تعقيمها أولاً. تحقق من هذه المقالة حول أخطاء مطور WordPress الشائعة مع مزيد من التفاصيل حول التعقيم وغيرها من النصائح العملية الرائعة.
وهذا يقودني إلى النصيحة التالية ، التي اختبرها معظم مطوري WordPress:
6. تذكر أن is_admin() ليس كما تعتقد
عندما تبدأ في التفكير في حماية الكود الخاص بك من الشر لأول مرة ، فمن المحتمل أن تتعثر في الوظيفة is_admin() ، ومن الاسم ، يبدو أن كل ما تحتاجه هو كل ما تحتاج إليه ، وكل ما عليك فعله هو لف الكود الخاص بك بذلك ، و كل شيء سوف يكون جيد.
لا، للاسف لا. تكتشف الوظيفة is_admin() فقط ما إذا كان يتم تنفيذ الكود على جانب الإدارة من موقع الويب. لا يقوم بأي شيء لاكتشاف ما إذا كان يتم تشغيل التعليمات البرمجية الخاصة بك من قبل مستخدم عادي أو مسؤول.
لن تلاحظ ذلك أبدًا إذا قمت فقط بإدخال الكود في المكون الإضافي الخاص بك لأنك على الأرجح تقوم بتشغيل الكود في واجهة الإدارة ، وهذا يعني أن الكود سيتم تقييمه إلى true ، وستتوقف عن التفكير فيه وتنتقل إلى شيء ما آخر.
الطريقة الصحيحة للتحقق مما إذا كان المستخدم مسؤولاً هي التحقق من قدرة المستخدم:
if ( current_user_can( 'activate_plugins' ) ) {
// Do your code here
}
هناك إمكانات مختلفة لأدوار المستخدم المختلفة ، لذلك لديك تحكم أكثر دقة. في معظم الحالات ، يكون 'activate_plugins' هو ما تحتاجه للمسؤولين فقط.
إذا كنت تريد طريقة للسماح لكل من المسؤولين والمحررين بفعل شيء ما ، فيجب عليك اختبار إمكانية 'edit_pages' .
7. أضف rel = ”noopener” أو rel = ”noreferrer” إلى روابطك
يعد الارتباط بالموارد الخارجية أمرًا طبيعيًا تمامًا ، وطريقة المدرسة القديمة لإضافة target="_blank" إلى هذه الروابط منطقية لأنك لا تريد أن يترك المستخدمون صفحة المكون الإضافي / المظهر الخاص بك.
ومع ذلك ، فإن هذا يفتح لك ما يسمى Tabnabbing. هذه مشكلة أمنية حيث يمكن لرمز JavaScript الضار سرقة المعلومات من المستخدمين عن طريق إساءة استخدام ميزة window.opener JavaScript.
يمكن أن يكون منع هذا أمرًا بسيطًا مثل إضافة rel="noopener" إلى روابطك. قد تكون الصفحة التي ترتبط بها اليوم جيدة ، ولكن قد يتغير ذلك في المستقبل.
rel=noopener تعني أن الصفحة التي ترتبط بها لا يمكنها الوصول إلى المعلومات أو التحكم في صفحتك.
تقوم rel=noreferrer بنفس الشيء ، وتوجه المتصفح أيضًا إلى عدم تمرير أي معلومات إحالة عبر رأس Referrer. إضافة rel="noreferrer" تعني أن الصفحة التي ترتبط بها لا تعرف من أين يأتي الزائر.
ملاحظة: يجب عدم الخلط بين هاتين الخاصيتين وبين rel=nofollow ، المرتبط بـ SEO.
8. استخدم HTTPS والرموز الآمنة مع واجهات برمجة تطبيقات الطرف الثالث
بصفتك مطورًا ، سيتعين عليك غالبًا دمج واجهات برمجة التطبيقات ، ومن الضروري القيام بذلك بأمان لحماية البيانات التي ترسلها ذهابًا وإيابًا.
لحسن الحظ ، توجد بالفعل معايير موضوعة حول كيفية القيام بذلك بأمان ؛ واحد منهم هو HTTPS. يقدم استخدام HTTPS طبقة من الأمان حيث يتم تشفير جميع البيانات المرسلة.
ومع ذلك ، لضمان حماية بياناتك من أعين التجسس ، فإن استخدام HTTPS لا يكفي.
كما يوضح هذا المقال من Ars Technica ، "لا يعني HTTPS أن بياناتك آمنة ، بل يعني فقط أن اتصالك آمن."
الرموز الآمنة - JWT
معيار آمن للتعامل مع الاتصالات وتكامل API هو استخدام JSON Web Tokens، JWT.
يتم إنشاء رمز آمن عن طريق تقديم طلب إلى خادم يتحقق من صحة تفاصيل تسجيل دخول المستخدم وينشئ رمزًا مميزًا ، وهو جزء صغير من السلسلة التي تحتوي على بيانات ، مثل اسم المستخدم والمعرف وما إلى ذلك.
عندما ترسل أي طلبات لاحقة إلى الخادم ، فإنك تقوم بتضمين هذا الرمز المميز في الطلب. يثبت هذا الرمز المميز أنك تمت مصادقتك ولديك حق الوصول. إذا كان الرمز المميز صالحًا ولم تنته صلاحيته ، فسيستخدم الخادم تفاصيل المستخدم الموجودة في الرمز المميز وسحب البيانات المطلوبة.
يمكن للخادم معالجة الطلبات بسرعة بهذه الطريقة ، مقارنة باستخدام مفتاح واجهة برمجة التطبيقات ، الأمر الذي يتطلب البحث عن المستخدم عبر هذا المفتاح قبل اتخاذ قرار بمعالجة البيانات. باستخدام رمز مميز ، يمكنك تضمين بيانات داخل الرمز المميز حول المستخدم وحفظ استعلامات قاعدة بيانات متعددة.
من خلال الطريقة التي يتم بها إنشاء رمز آمن واستخدامه لاحقًا ، لا يمكن إنشاء رموز مزيفة أو التلاعب بمحتوى الرمز المميز. من الممكن فقط إنشاء رمز صالح من خلال معرفة المفتاح السري ، والذي ستبقى الشركة التي تقف وراء المنصة مخفية جيدًا.
ملاحظة مهمة للغاية يجب تذكرها وهي أن البيانات الموجودة داخل الرمز المميز غير مشفرة. من المستحيل التلاعب بمحتويات الرمز المميز دون إبطالها ، ولكن يمكن بسهولة قراءة البيانات الموجودة داخل الرمز المميز من قبل أي شخص ، لذلك فهو ليس مكانًا جيدًا لتخزين البيانات الحساسة.
مورد جيد إذا كنت ترغب في التعمق أكثر في الرموز وكيفية عملها هو مقدمة إلى JSON Web Tokens.
9. لا تستخدم مكتبات خارجية من شبكات CDN
على الرغم من أنه قد يكون من المغري تضمين أي مكتبات قد تحتاجها عبر cdnjs.com أو شبكات CDN عالمية مجانية أخرى ، إلا أن هناك بعض العيوب.
بادئ ذي بدء ، ليس لديك أي سيطرة على المكتبات وأي تعليمات برمجية ضارة تتسلل إلى الملفات التي تقوم بتضمينها.
على الرغم من أن CDN مستقرة بشكل عام وسريعة من حيث التعريف ، إلا أنها أيضًا عرضة لمزيد من الهجمات. إذا كانت التعليمات البرمجية الخاصة بك تعتمد على مكتبة JS على CDN تتعرض للهجوم ، فسيتم تحميل المكون الإضافي والقالب الخاص بك إما ببطء شديد أو لا يتم تحميلهما على الإطلاق.
حدث هذا لموقع ويب للعميل حيث كان CDN العام يستخدم مكونًا إضافيًا في ذلك الوقت كانت مهلة للمستخدمين في بعض المناطق مما يجعل الواجهة غير قابلة للاستخدام. في النهاية ، اضطررت إلى تغيير المكون الإضافي لاستخدام نسخة محلية من البرنامج النصي JS بدلاً من ذلك كإصلاح سريع.
قد يؤدي استخدام مصدر خارجي تابع لجهة خارجية إلى تعريض الخصوصية للخطر أيضًا. سيكون من الممكن لـ CDN تسجيل جميع عناوين IP الخاصة بالمستخدم - تأكد من مراجعة سياسة القانون العام لحماية البيانات (GDPR) وإبلاغ عملائك.
بشكل عام ، إذا كنت تستخدم موفري CDN من جهات خارجية ذائعة الصيت ، فلن تواجه أي مشاكل ، ولكن الطريقة الأبسط والأكثر موثوقية هي توزيع مكتبة JS المضمنة في منتجك.
هل كنت تعلم؟ يأتي WordPress مع العديد من مكتبات JS المضمنة. تأتي العديد من مكتبات JS الأكثر شيوعًا والتي قد ترغب في استخدامها مضمنة في WordPress. ستغطي هذه المكتبات معظم احتياجاتك الأساسية.
نصيحة للمطور: يرجى تحميل ملفات JS و CSS الإضافية فقط على الصفحات المحددة التي تحتاجها. بصفتي مطورًا ومستخدمًا ، فأنا لا أحب بشدة المكونات الإضافية التي تبطئ المشرف عن طريق تحميل ملفات JS و CSS غير الضرورية في كل صفحة. لا يؤدي ذلك إلى إبطاء صفحات المسؤول الأخرى فحسب ، بل يمكنه أيضًا العبث بالتخطيط المرئي وجعل بعض صفحات المسؤول غير قابلة للاستخدام تقريبًا. لو سمحت
هناك أيضًا بعض الأدوات التي يمكن أن تساعدك في حماية التعليمات البرمجية الخاصة بك ، والأداة الرائعة التي يمكنك استخدامها مجانًا هي Coderisk.
هو توظيف 
10. استخدم الأدوات والخدمات لتحليل التعليمات البرمجية الخاصة بك
قرص الترميز
هناك العديد من الخدمات الآلية للمساعدة في تحديد مشكلات التعليمات البرمجية. Exakat و SonarSource و PHPStan على سبيل المثال لا الحصر ، والمفضلة لدي - Coderisk.com - طريقة سهلة للعثور على بعض أخطاء الأمان الأكثر وضوحًا في التعليمات البرمجية الخاصة بك.
تقوم هذه الشركة بمسح جميع مكونات WordPress الإضافية من مستودع WordPress.org العام. برنامجهم قادر على مسح وتحديد مئات الأنواع المختلفة من مشكلات الأمان بناءً على معايير الترميز المختلفة.
وفقًا لإحصاءاتهم الخاصة ، قاموا بمسح أكثر من 4 مليارات سطر من التعليمات البرمجية العامة حتى الآن ، وهناك الكثير من المشكلات حتى مع المكونات الإضافية الأعلى.
يعد التسجيل للحصول على الخدمة المجانية أمرًا بسيطًا للغاية - يمكنك إنشاء حساب مجاني ثم البدء في المطالبة بالمكونات الإضافية الخاصة بك. المطالبة بمكوِّن إضافي بسيطة مثل أخذ سطر واحد من التعليمات البرمجية التي تضعها في ملف readme.txt في المرة التالية التي تنشر فيها إصدارًا جديدًا.
يتيح لك ذلك الوصول إلى أحدث مسح للمكون الإضافي الخاص بك ، وفي الداخل ، لديهم معلومات وتفاصيل محددة حول كل مشكلة ، مع روابط مباشرة إلى الرمز الخاص بك.
ضع في اعتبارك أن هذه خدمة مجانية ، لذا فقد لا يقوموا بتحديث المسح الضوئي الخاص بهم للمكون الإضافي الخاص بك كثيرًا ، ولكن بمجرد تلقي إشعار ، فإن الأمر يستحق التحقق من الكود الخاص بك ، حيث قد تكون قد ارتكبت خطأ منذ آخر مرة قمت فيها بالمراجعة كودك.
من السهل جدًا التنقل في الواجهة بمجرد تعطلها ، والنظام مفيد للغاية ، مما يمنحك سهولة شديدة في فهم الإرشادات حول الخطأ الذي يساعدك على تتبع الخطأ.
هناك أيضًا العديد من الطرق للتصفية من خلال الأخطاء ، ويمكنك وضع علامة على كل مشكلة على أنها تم إصلاحها أو العديد من الخيارات الأخرى لمساعدتك في الحصول بسرعة على نظرة عامة على جميع المشكلات.
ملاحظة: إذا لم تقم مطلقًا بتشغيل Coderisk (أو أي أداة أخرى في فئتها) على التعليمات البرمجية الخاصة بك ، فلا تقلق بشأن عدد المشكلات المشتبه فيها التي سيتم تحذيرك بشأنها. قد تولد هذه الأدوات قدرًا جيدًا من الإيجابيات الخاطئة لأنها تحلل الكود فقط دون فهم منطق الأعمال. استخدم مخرجات الأداة كقائمة بداية صلبة للعناصر المراد مراجعتها.
PHP_CodeSniffer
أداة أخرى رائعة للتحقق من التعليمات البرمجية الخاصة بك هي PHP_CodeSniffer. يتكون PHPCS من نصين ، PHPCS الذي يتحقق من التعليمات البرمجية الخاصة بك ويبلغ عن الأخطاء لك و PHPCBF الذي يمكنه تلقائيًا إصلاح مجموعة طويلة من المشاكل التي تحددها PHPCS.
يعد استخدام PHPCS سهل الاستخدام للغاية من سطر الأوامر بمجرد تثبيته. لن تمنع هذه الأداة ظهور مشكلات الأمان في التعليمات البرمجية الخاصة بك ، ولكن يمكنك التخلص من أخطاء الترميز البسيطة التي تجعل من الصعب للغاية إساءة استخدام أي مشكلات أكبر.
من الممكن أيضًا دمج PHPCS مباشرة في المحرر الخاص بك ، مثل Sublime Text و Visual Code. بهذه الطريقة يمكنك بسهولة رؤية أي أخطاء وإصلاحها بسرعة في IDE الخاص بك.
بغض النظر عما إذا كنت تعمل في فريق أو كمطور واحد ، فإن الأمر يستحق استخدام نظام آلي لأنه طريقة سهلة للتخلص من مشكلات الأمان الأساسية التي قد تفوتك بخلاف ذلك.
لا يعد استخدام نظام آلي لفحص الكود الخاص بك بحثًا عن مشكلات الأمان طريقة آمنة لجمع جميع الأخطاء ، ولكنه يمكن أن يساعدك في تحديد الأخطاء الأكثر وضوحًا.
11. لا تنسخ وتلصق التعليمات البرمجية من الويب دون مراجعة مناسبة
يجب أن يكون الحفاظ على منتج WP الخاص بك آمنًا قدر الإمكان عملية مستمرة ، وليس فقط مرة واحدة كل فترة. عند تقديم ميزات جديدة أو إزالة التعليمات البرمجية ، يمكنك أيضًا تقديم مشكلات أمان جديدة.
جوجل ليس صديقك دائما. بصفتك مطورًا ، فأنت معتاد على التحقق من الإنترنت الواسع بحثًا عن أمثلة التعليمات البرمجية لإلهامك - أو مجرد إعادة كتابة الأجزاء والقطع هنا وهناك إذا كنت كسولًا.
نادرًا ما تكون معظم أجزاء التعليمات البرمجية التي تجدها على الإنترنت جاهزة للاستخدام في بيئة إنتاج آمنة ويُقصد بها أن تكون مثالًا على أي مشكلة ترميز تحاول إصلاحها. يمكن أن يؤدي استخدام هذه الأجزاء من التعليمات البرمجية بشكل أعمى وبدون مراجعة إلى حدوث مشكلات بسرعة كبيرة.
هناك الكثير لتفعله كمطور WordPress ، ويجب ألا يكون إصلاح مشكلة أمنية ملحة في المكون الإضافي الخاص بك مع الآلاف من التثبيتات أحد هذه المشكلات.
ضع في اعتبارك أن سمعتك معرضة للخطر
إذا كنت لا تولي اهتمامًا لأمن المكون الإضافي أو موضوع الأمان ، فأنت تعرض المستخدمين لديك وأعمالهم وأعمالك وسمعتك للخطر. هذا الكثير من الوقت والمال الضائعين!
يمكن أن يكون للثغرات الأمنية تأثير كبير على الثقة والثقة التي يضعها العملاء في علامتك التجارية أو منتجاتك. يوضح مثال Loginizer أعلاه أنه حتى أكثر الثغرات الأمنية إحراجًا يمكن أن تحدث لمطوري المكونات الإضافية الأمنية أنفسهم! وتخبرنا الأمثلة الأخرى حول تزوير الناخبين والقرصنة الحكومية أن أي شخص معرض للخطر.
إذا اكتشفت ثغرة أمنية ، فتصرف بسرعة لحلها واتبع أفضل الممارسات للإعلان عن المشكلة علنًا (إذا لزم الأمر) جنبًا إلى جنب مع إصدار الإصلاح.
إذا بقيت في صدارة اللعبة عندما يتعلق الأمر بقضايا الاتصال و "العلاقات العامة" التي قد تنشأ عن ثغرة أمنية ، فيمكنك حينئذٍ تجنب بعض الصداع العملاق وزيادة سمعتك بدلاً من الإضرار بها.
شكرا للقراءة!
قد يكون من الصعب النظر في كل الأشياء التي تحتاج إلى القيام بها عندما لا تعرف ما الذي تبحث عنه لتبدأ ، وقد يكون من الصعب العثور على المعلومات الصحيحة. إذا لم يكن لديك دليل من أين تبدأ ، يجب أن تفكر في مراجعة منتجك بواسطة خبير أمان WP (أقوم بمراجعات أمنية أيضًا).
من المغري توفير المال أو الوقت لإجراء مراجعة أمنية ، ولكن تكلفة عدم تأمين منتجك قدر الإمكان يمكن أن تكون أعلى على المدى الطويل.
هذه ليست سوى بعض الطرق التي يمكنك ويجب أن تحمي بها منتج WordPress الخاص بك من إساءة الاستخدام. إذا كان لديك أي شك ، فقط تذكر - لا تثق بأحد