انتبه: وظائف PHP و WordPress التي يمكن أن تجعل موقعك غير آمن

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

يوفر WordPress نفسه مكتبة كبيرة من الوظائف ، قد يكون بعضها خطيرًا. علاوة على ذلك ، هناك الكثير من وظائف PHP التي سيستخدمها مطور WordPress (PHP) مع بعض الترددات التي يمكن أن تكون خطيرة عند استخدامها.

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

وظائف PHP التي يجب الانتباه إليها

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

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

أو ذكر أن PHP 5.6 هو آخر إصدار 5.x لا يزال يدعم الأمان المستمر. يجب أن تكون عليه ، على الأقل. ويجب أن يكون لديك خطة للانتقال إلى PHP 7 قبل انتهاء دعم 5.6 بنهاية 2018.

بعد ذلك ، سيكون لديك فقط بعض الوظائف المحفوفة بالمخاطر للتعامل معها. بدءا من…

extract هو خبر سيء ، خاصة على $_POST أو ما شابه

لحسن الحظ ، فإن استخدام وظيفة extract PHP أصبح غير صالح إلى حد كبير. كان جوهر استخدامه هو أنه يمكنك تشغيله على مجموعة من البيانات ، وستصبح أزواج القيمة الرئيسية الخاصة به متغيرات حية في التعليمات البرمجية الخاصة بك. وبالتالي

 $arr = array( 'red' => 5 ); extract($arr); echo $red; // 5

سيعمل. هذا أمر رائع ، ولكنه خطير أيضًا إذا كنت تستخرج $_GET و $_POST وما إلى ذلك. في هذه الحالات ، تقوم بشكل أساسي بإعادة إنشاء مشكلة register_globals بنفسك: يمكن للمهاجم الخارجي تغيير قيمك المتغيرة بسهولة عن طريق إضافة سلسلة استعلام أو حقل النموذج. الحل الأفضل بسيط: لا تستخدم extract .

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

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

" eval Is Evil" لأن الشفرة التعسفية مخيفة

إن eval في PHP وأي لغة أخرى تحملها دائمًا ما تكون في مرتبة عالية في قوائم مثل هذه. ولسبب وجيه. تقول الوثائق الرسمية لـ PHP على PHP.net بصراحة تامة:

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

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

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

لكن ضع في اعتبارك دائمًا هذا السطر من Rasmus Lerdorf ، مؤسس PHP:

"إذا كانت" EVAL () `هي الإجابة ، فمن شبه المؤكد أنك تسأل السؤال الخطأ.

الاختلافات في eval

بالإضافة إلى eval المعروف ، هناك مجموعة متنوعة من الطرق الأخرى التي تدعمها PHP تاريخيًا السلاسل التي تم تقييمها على أنها كود. الأكثر ملاءمة لمطوري WordPress هما preg_replace مع معدل /e ، و create_function . يعمل كل منهما بشكل مختلف قليلاً ، ولا يعمل preg_replace بعد PHP 5.5.0 على الإطلاق. (لم تعد PHP 5.5 والإصدارات الأقدم تتلقى تحديثات أمنية رسمية ، وبالتالي من الأفضل عدم استخدامها.)

/e المُعدِّلات في Regex "شريرة" أيضًا

إذا كنت تستخدم PHP 5.4.x أو أقل ، فستحتاج إلى مراقبة مكالمات PHP preg_replace التي تنتهي بـ e. يمكن أن يبدو مثل:

 $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );)

تقدم PHP طرقًا مختلفة لـ "سياج" في تعبيرك العادي ، ولكن الشيء الأساسي الذي تريد أن تكون على اطلاع عليه هو "e" باعتباره الحرف الأخير في الوسيطة الأولى لـ preg_replace . إذا كان هناك ، فأنت تقوم بالفعل بتمرير المقطع الموجود بالكامل كوسيطة لـ PHP المضمنة ، ثم تقوم eval . هذا له نفس المشكلات تمامًا مثل eval إذا كنت تسمح لمدخلات المستخدم بالانتقال إلى وظيفتك. يمكن استبدال رمز المثال باستخدام preg_replace_callback بدلاً من ذلك. ميزة هذا هو أنك كتبت وظيفتك ، لذلك يصعب على المهاجم تغيير ما يتم تقييمه. لذلك ستكتب ما ورد أعلاه على النحو التالي:

 // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html );

السماح بإدخال المستخدم create_function s سيئ أيضًا ...

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

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

assert هو أيضا eval -مثل

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

تضمين الملفات المتغيرة هو طريقة محتملة للسماح بتنفيذ PHP غير خاضع للرقابة

لقد اكتشفنا جيدًا سبب eval ، ولكن شيئًا مثل include أو require($filename'.php') يمكن أن يكون أخبارًا سيئة بالمثل ، خاصة عندما يتم تعيين $filename من قيمة يمكن التحكم فيها من قبل المستخدم. السبب يختلف بمهارة عن eval . غالبًا ما تستخدم أسماء الملفات المتغيرة لأشياء مثل توجيه URL إلى ملف بسيط في تطبيقات PHP بخلاف WordPress. ولكن قد تراها مستخدمة في WordPress أيضًا.

جوهر المشكلة هو أنه عندما تقوم include أو require (أو include_once أو require_once ) ، فإنك تجعل البرنامج النصي ينفذ الملف المضمن. إنه ، إلى حد ما ، eval مفاهيمي لهذا الملف ، على الرغم من أننا نادرًا ما نفكر فيه بهذه الطريقة.

إذا كنت قد كتبت جميع الملفات التي include المتغير الخاص بك والتي قد يسحبها ، وفكرت في ما سيحدث عندما يحدث ذلك ، فأنت بخير. لكنها أخبار سيئة إذا لم تفكر في ما سيفعله include ing password.php أو wp-config.php . إنها أيضًا أخبار سيئة إذا تمكن شخص ما من إضافة ملف ضار ثم تنفيذ include الخاص بك (على الرغم من أنك ربما تواجه مشكلات أكبر في هذه المرحلة).

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

 $white_list = ['db.php', filter.php', 'condense.php'] If (in_array($white_list, $file_to_include)) { include($file_to_include); }

لا تمرر مدخلات المستخدم مطلقًا إلى shell_exec والمتغيرات

هذا هو واحد كبير. تسمح كل من shell_exec و system و exec و backticks في PHP للكود الذي تقوم بتشغيله بالتحدث إلى الغلاف الأساسي (عادةً نظام Unix). هذا مشابه لما يجعل eval خطيرًا ولكنه مضاعف. تضاعف لأنك إذا سمحت بإدخال المستخدم هنا بلا مبالاة ، فلن يكون المهاجم مقيدًا بقيود PHP.

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

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

مشاهدة unserialize . يقوم بتشغيل التعليمات البرمجية تلقائيًا

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

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

تتمثل نقطة الضعف الأساسية هنا في أنه عندما تقوم PHP بإلغاء تسلسل سلسلة في فئة ، فإنها __wakeup unserialize في تلك الفئة. إذا تم السماح بإدخال المستخدم غير unserialized غير متسلسل ، فمن المحتمل أن يتم الإشارة إلى شيء مثل استدعاء قاعدة البيانات أو حذف الملف في طريقة __wakeup إلى موقع خطير أو غير مرغوب فيه.

unserialize eval الثغرات الأمنية لأنه يتطلب استخدام الأساليب السحرية على الكائنات. بدلاً من إنشاء الكود الخاص به ، يضطر المهاجم إلى إساءة استخدام الأساليب المكتوبة بالفعل على كائن ما. تعتبر كل من الطرق __toString __destruct و __toString على الكائنات محفوفة بالمخاطر أيضًا ، كما توضح صفحة OWASP Wiki هذه.

بشكل عام ، أنت بخير إذا لم تستخدم __wakeup أو __destruct أو __toString في فصولك الدراسية. ولكن نظرًا لأنك قد ترى لاحقًا شخصًا يضيفهم إلى فصل دراسي ، فمن الجيد ألا تدع مستخدمًا قريبًا من مكالماتك لإجراء serialize unserialize تسلسل وتمرير جميع البيانات العامة لهذا النوع من الاستخدام على الرغم من شيء مثل JSON ( json_encode و json_decode ) حيث يوجد لا يتم تنفيذ التعليمات البرمجية تلقائيًا.

يعد جلب عناوين URL باستخدام file_get_contents بالمخاطر

من الممارسات الشائعة عند كتابة بعض أكواد PHP بسرعة والتي يجب أن تستدعي عنوان URL خارجيًا ، الوصول إلى file_get_contents . إنه سريع وسهل ولكنه ليس آمنًا للغاية.

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

المشكلة هنا هي أن file_get_contents سوف يجلب لك الصفحات البعيدة. ولكن عندما يفعل ذلك ، فإنه لا يتحقق من سلامة اتصال بروتوكول HTTPS. ما يعنيه ذلك هو أن البرنامج النصي الخاص بك قد يكون ضحية لهجوم man-in-the-middle والذي من شأنه أن يسمح للمهاجم بوضع ما يريده إلى حد كبير في نتيجة صفحة file_get_contents الخاصة بك.

هذا هجوم مقصور على فئة معينة. ولكن للحماية من ذلك عندما أكتب PHP حديثة (قائمة على الملحن) ، فأنا دائمًا ما أستخدم Guzzle لتغليف واجهة برمجة تطبيقات cURL الأكثر أمانًا. في WordPress ، الأمر أسهل: استخدم wp_remote_get . إنه يعمل بشكل أكثر تناسقًا بكثير من file_get_contents ، وسوف يكون افتراضيًا للتحقق من اتصالات SSL. (يمكنك تبديل ذلك ، ولكن ، ربما لا تفعل ذلك ...) من الأفضل ، ولكن أكثر إزعاجًا للحديث عنه ، هي wp_safe_remote_get ، وما إلى ذلك. تعمل هذه الوظائف بشكل مماثل للوظائف بدون safe_ في أسمائها ، ولكنها ستجعل تأكد من عدم حدوث عمليات إعادة التوجيه وإعادة التوجيه غير الآمنة على طول الطريق.

لا تثق بشكل أعمى في التحقق من صحة عنوان URL من filter_var

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

المشكلة هنا محددة جدًا: إذا كنت تحاول استخدامها للتأكد من أن عنوان URL آمن ، فإن filter_var لا يتحقق من صحة البروتوكول. هذه ليست مشكلة في كثير من الأحيان ، ولكن إذا كنت تقوم بتمرير إدخال المستخدم إلى هذه الطريقة للتحقق من الصحة ، وكنت تستخدم FILTER_VALIDATE_URL ، فسيتم تمرير شيء مثل javascript://comment%0aalert(1) . وهذا يعني أن هذا يمكن أن يكون ناقلًا جيدًا جدًا لهجوم XSS أساسي في مكان لم تكن تتوقعه.

للتحقق من صحة عنوان URL ، سيكون لوظيفة esc_url في WordPress تأثير مماثل ، ولكنها تتيح فقط من خلال البروتوكولات المسموح بها. javascript ليس في القائمة الافتراضية ، لذلك من شأنه أن يبقيك في مأمن. ومع ذلك ، على عكس filter_var ، فإنه سيعيد سلسلة فارغة (ليست خاطئة) لبروتوكول غير مسموح به يتم تمريره إليه.

وظائف خاصة بـ WordPress يجب متابعتها

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

يقوم WordPress بإلغاء التسلسل باستخدام maybe_unserialize

ربما يكون هذا واضحًا إذا قرأت ما ورد أعلاه. في WordPress ، هناك وظيفة تسمى maybe_unserialize ، وكما تعتقد ، فإنها تلغي تسلسل ما تم تمريره إليها إذا لزم الأمر.

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

لا is_admin إذا كان المستخدم مسؤولاً!

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

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

add_query_arg() لا يقوم بتعقيم عناوين URL

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

الشيء الأساسي الذي كان عليهم فعله بشكل مختلف: تعقيم نتيجة استدعاء هذه الوظيفة قبل استخدامها. إذا قمت بذلك ، فأنت في مأمن حقًا من هجمات XSS التي كنت تعتقد أنها كذلك. لذلك يبدو هذا مثل:

 echo esc_url( add_query_arg( 'foo', 'bar' ) );

$wpdb->query() مفتوح أمام هجوم حقن SQL

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

السبب في أنني أستدعي على وجه التحديد $wpdb->query هو أن بعض الطرق الأخرى (مثل insert delete وما إلى ذلك) على $wpdb تعتني بهجمات الحقن نيابة عنك. بالإضافة إلى ذلك ، إذا كنت معتادًا على إجراء استعلامات قاعدة بيانات WordPress أساسية باستخدام WP_Query أو ما شابه ، فلن تحتاج إلى التفكير في إدخال SQL. هذا هو السبب في أنني أستدعي الأمر: للتأكد من أنك تفهم أن هجوم الحقن على قاعدة البيانات ممكن عندما تحاول أولاً استخدام $wpdb لإنشاء استعلامك الخاص.

ما يجب القيام به؟ استخدم $wpdb->prepare() ثم $wpdb->query() . ستحتاج أيضًا إلى التأكد من الاستعداد قبل طرق "الحصول" الأخرى مثل $wpdb مثل ، get_row() و get_var() . وإلا فقد تحصل عليك Bobby Tables.

لا esc_sql من حقن SQL أيضًا

بالنسبة لمعظم مطوري WordPress ، أود أن أقول إن esc_sql لا يسجل بأي معنى ، لكن يجب أن يكون كذلك. Ase الذي ذكرناه للتو ، يجب أن تستخدم wpdb->prepare() قبل إجراء أي استعلام عن قاعدة البيانات. هذا سوف يحافظ على سلامتك. ولكن من المغري والمفهوم أن يصل المطور إلى esc_sql بدلاً من ذلك. وقد يتوقعون أنه سيكون آمنًا.

تكمن المشكلة في أن esc_sql لا يحتوي على وسائل حماية قوية ضد حقن SQL. إنها حقًا نسخة مجيدة من وظيفة add_slashes في PHP ، والتي لم نشجعك على استخدامها لحماية قاعدة البيانات الخاصة بك لسنوات.

هناك المزيد للقيام به ، ولكن هذه بداية كبيرة

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

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

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