في بداية الدليل، قلنا أن تصفية البيانات هي حجر الزاوية في أمان تطبيقات الويب بأي لغة وعلى أي منصة. يتضمن ذلك التحقق من إدخال البيانات من وإلى التطبيق، ويمكن أن يساعد التصميم الجيد للبرامج المطورين على:
التأكد من عدم إمكانية تجاوز تصفية البيانات،
والتأكد من أن المعلومات غير القانونية لا تؤثر على المعلومات القانونية، وتحديد
مصدر البيانات.
هناك وجهات نظر مختلفة حول كيفية التأكد من عدم إمكانية تجاوز تصفية البيانات، واثنتان منها أكثر عمومية من غيرها وتوفر مستوى أعلى من الضمان.
طريقة الجدولة تتم جدولة هذه الطريقة باستخدام برنامج نصي PHP واحد (عبر عنوان URL). يتم تضمين أي عمليات أخرى باستخدام include أو require عند الضرورة. يتطلب هذا الأسلوب عمومًا أن يتم تمرير متغير GET منفصل لكل عنوان URL للإرسال. يمكن اعتبار متغير GET هذا بمثابة تصميم أكثر بساطة يحل محل اسم البرنامج النصي. على سبيل المثال:
http://example.org/dispatch.php?task=print_formdispatch.php هو الملف الجذر الوحيد (جذر المستند). فهو يسمح للمطورين بالقيام بأمرين مهمين للغاية:
تنفيذ بعض عمليات المعالجة الأمنية الشاملة في Submit.php في البداية، والتأكد من عدم إمكانية تجاوز هذه المعالجة.
من السهل تحديد المكان الذي تكون فيه تصفية البيانات ضرورية، خاصة بالنسبة لبعض عمليات التحكم في التدفق ذات الأغراض الخاصة.
راجع المثال التالي لمزيد من المناقشة حول البرنامج النصي send.php:
<?php/* Global Security Handling*/switch ($_GET['task']){case 'print_form':include '/inc/presentation/form.inc '; استراحة; inc/ Presentation/form.inc';}break;default:include '/inc/presentation/index.inc';break;}?>إذا كان هذا هو البرنامج النصي PHP الوحيد الذي يمكن الوصول إليه بشكل عام، فيمكنك التأكد من أن هذا البرنامج مصمم يضمن عدم إمكانية تجاوز معالجة الأمان العالمية الأولية. كما أنه يسهل على المطورين رؤية تدفق التحكم في مهام محددة. على سبيل المثال، من السهل معرفة ذلك دون تصفح الكود بأكمله: عندما يكون $form_valid صحيحًا، فإن end.inc هو الكود الوحيد الذي يتم عرضه للمستخدم لأنه كان قبل تضمين Process.inc وتمت تهيئته للتو إلى false يمكن تحديد أن المنطق الداخلي لـprocess.inc سيضبطه على صحيح، وإلا فسيتم عرض النموذج مرة أخرى (ربما مع رسالة خطأ مرتبطة).
لاحظ أنه إذا كنت تستخدم ملف توجيه دليل مثل Index.php (بدلاً من Submit.php)، فيمكنك استخدام عنوان URL مثل هذا: http://example.org/?task=print_form .
يمكنك أيضًا استخدام إعادة توجيه ApacheForceType أو mod_rewrite لضبط عنوان URL: http://example.org/app/print-form .
هناك طريقة أخرى لتضمين الأساليب وهي استخدام وحدة واحدة مسؤولة عن كافة عمليات المعالجة الأمنية. يتم تضمين هذه الوحدة في مقدمة (أو في المقدمة) جميع نصوص PHP العامة. ارجع إلى النص البرمجي التاليsecurity.inc
<?phpswitch ($_POST['form']){case 'login':$allowed = array();$allowed[] = 'form';$allowed[] = 'username' ; $allowed[] = 'password';$sent = array_keys($_POST);if ($allowed == $sent){include '/inc/logic/process.inc';}break;}?>في هذه الحالة ، يعتبر كل نموذج يتم إرساله يحتوي على قيمة التحقق الفريدة للنموذج، ويقوم موقع Security.inc بشكل مستقل بمعالجة البيانات الموجودة في النموذج الذي يحتاج إلى تصفيته. نموذج HTML الذي ينفذ هذا المتطلب هو كما يلي:
<form action="/receive.php" Method="POST"><input type="hidden" name="form" value="login" /><p>اسم المستخدم : <input type = "text" name = "اسم المستخدم" /></p><p>كلمة المرور: <input type = "password" name = "password" /></p><input type = "submit" / > </form>يتم استخدام مصفوفة تسمى $allowed للتحقق من متغيرات النموذج المسموح بها. يجب أن تكون هذه القائمة متسقة قبل معالجة النموذج. يقرر التحكم في العمليات ما سيتم تنفيذه، وprocess.inc هو المكان الذي تصل إليه البيانات الفعلية التي تمت تصفيتها.
لاحظ أن أفضل طريقة لضمان تضمين ملف Security.inc دائمًا في بداية كل برنامج نصي هي استخدام الإعداد auto_prepend_file.
مثال التصفية يعد إنشاء قائمة بيضاء أمرًا مهمًا للغاية لتصفية البيانات. نظرًا لأنه من المستحيل تقديم أمثلة لكل بيانات النموذج التي قد تواجهها، فإن بعض الأمثلة يمكن أن تساعدك في الحصول على فهم عام.
الكود التالي يتحقق من صحة عنوان البريد الإلكتروني:
<?php$clean = array();$email_pattern = '/^[^@s<&>]+@([-a-z0-9]+.) +[ az]{2,}$/i';if (preg_match($email_pattern, $_POST['email'])){$clean['email'] = $_POST['email'];}?> أدناه الرمز يضمن أن محتوى $_POST['color'] أحمر أو أخضر أو أزرق:
<?php$clean = array();switch ($_POST['color']){case 'red':case 'green ' :case 'blue':$clean['color'] = $_POST['color'];break;}?>تضمن التعليمات البرمجية التالية أن $_POST['num'] عدد صحيح:
<?php$ clean = array ();if ($_POST['num'] == strval(intval($_POST['num']))){$clean['num'] = $_POST['num'];} > ما يلي يضمن الكود أن $_POST['num'] هو عدد عائم:
<?php$clean = array();if ($_POST['num'] == strval(floatval($_POST['num ']))){ $clean['num'] = $_POST['num'];}?> يستخدم كل مثال المصفوفة $clean قبل تحويل الاسم. تعد هذه ممارسة جيدة للمطورين لتحديد ما إذا كانت بياناتهم معرضة للخطر أم لا. لا تقم أبدًا بحفظ البيانات في $_POST أو $_GET بعد التحقق من صحتها، كمطور، يجب أن تكون دائمًا متشككًا تمامًا في البيانات المحفوظة في المصفوفات العالمية الفائقة.
يجب أن نضيف أن استخدام $clean يمكن أن يساعد في التفكير فيما لم تتم تصفيته، وهو ما يشبه إلى حد كبير دور القائمة البيضاء. يمكن تحسين مستوى الأمان.
إذا قمت بتخزين البيانات التي تم التحقق من صحتها فقط في $clean، فإن الخطر الوحيد في التحقق من صحة البيانات هو أن عنصر المصفوفة الذي تشير إليه غير موجود، وليس البيانات الخطرة التي لم تتم تصفيتها.
التوقيت بمجرد بدء تنفيذ البرنامج النصي PHP، فهذا يعني أن جميع طلبات HTTP قد انتهت. في هذه المرحلة، ليس لدى المستخدم فرصة لإرسال البيانات إلى البرنامج النصي. لذلك، لا يمكن إدخال أي بيانات في البرنامج النصي (حتى إذا تم تشغيل Register_globals). هذا هو السبب في أن تهيئة المتغيرات تعتبر ممارسة جيدة جدًا.