تنظيف مدخلات المستخدم في PHP: أهم الأخطاء والحماية

"أنا فقط أفلت علامات الاقتباس": لماذا كودك عرضة للاختراق

إذا كنت قد بحثت يومًا عن "كيفية تنظيف مدخلات المستخدم في PHP؟"، فأنت لست وحدك. هذا السؤال على Stack Overflow حصد مئات الآلاف من المشاهدات. ولا عجب: موضوع الأمان من أكثر المواضيع سخونة في تطوير الويب.

لكن المفارقة هي أن معظم الإجابات على هذا السؤال إما قديمة أو خطيرة. لا يزال المطورون يكتبون شيئًا مثل mysql_real_escape_string() (التي اختفت منذ 10 سنوات) أو ببساطة يحذفون الأحرف "الخطيرة". تنبيه: هذا لا يعمل.

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

الخطأ رقم 1: الإيمان الأعمى بـ"التنظيف" كحل سحري

أكبر خطأ هو الاعتقاد بوجود دالة واحدة "تنظف" أي بيانات. إليك كودًا نموذجيًا لمبتدئ:

<?php\n$name = $_POST['name'];\n$name = strip_tags($name);\n$name = addslashes($name);\n// هل البيانات آمنة الآن؟ لا!\n?>

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

الحل الصحيح: حدد ما تفعله بالبيانات في كل مرحلة. لقاعدة البيانات شيء، ولـ HTML شيء آخر، ولـ JSON شيء ثالث.

الخطأ رقم 2: استخدام دوال قديمة (أو استخدامها بشكل خاطئ)

لنستعرض "الديناصورات" في أمان PHP:

\n
• mysql_real_escape_string() — أُزيلت في PHP 7.0. انسَ أمرها.
\n
• addslashes() — لا تحمي من جميع هجمات حقن SQL، خاصة مع الترميزات متعددة البايت.
\n
• strip_tags() — تزيل الوسوم لكنها لا ترمز المخرجات. هجمات XSS لا تزال ممكنة عبر الخصائص.
\n

مثال على كود خطير لا يزال موجودًا:

<?php\n$id = $_GET['id'];\n$id = addslashes($id);\n$query = "SELECT * FROM users WHERE id = '$id'";\n// إذا كانت id = 1 OR 1=1 -- تم اختراقك\n?>

الحل الصحيح: استخدم الاستعلامات المحضرة (Prepared Statements). هذه هي الطريقة الوحيدة الموثوقة للحماية من حقن SQL.

<?php\n$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");\n$stmt->execute(['id' => $_GET['id']]);\n?>

أرأيت؟ لا حاجة لتنظيف SQL. فقط معاملات. قاعدة البيانات نفسها ستفصل بين البيانات والأوامر.

الخطأ رقم 3: الخلط بين التحقق من الصحة والتنظيف

كثيرون يعتقدون: "سأحذف جميع الأحرف المشبوهة وسأكون آمنًا". لكن هذا يكسر منطق التطبيق. تخيل أن المستخدم أدخل كلمة مرور P@ssw0rd!، وقمت بحذف الرمزين @ و !. ستصبح كلمة المرور Pssw0rd — ولن يتمكن المستخدم من تسجيل الدخول بعد الآن.

التحقق من الصحة (Validation) — يتحقق مما إذا كان الإدخال يطابق التنسيق المتوقع (بريد إلكتروني، رقم، رابط). إذا لم يطابق، نرفضه.

التنظيف (Sanitization) — يزيل أو يعدل الأحرف غير المرغوب فيها، ولكن فقط عندما يكون ذلك ضروريًا حقًا (مثل اسم ملف).

مثال على التحقق الصحيح من البريد الإلكتروني:

<?php\n$email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL);\nif ($email === false) {\n    // البريد الإلكتروني غير صالح — لا نحفظه ولا نخرجه\n    echo "أدخل بريدًا إلكترونيًا صحيحًا";\n    exit;\n}\n// الآن $email سلسلة آمنة لأي غرض\n?>

القاعدة الذهبية: إذا كنت تتوقع رقمًا — تحقق من أنه رقم. إذا كان بريدًا إلكترونيًا — تحقق من التنسيق. كل ما عدا ذلك — ارفضه.

الخطأ رقم 4: تجاهل سياق المخرجات (XSS)

لقد حفظت البيانات في قاعدة البيانات باستخدام استعلامات محضرة. رائع، لا يوجد حقن SQL. لكن