ثغرات الأمن في فيبريت PHP؟

Question

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

بدلاً من الاضطرار إلى grep باستمرار من خلال error_log لـ "ملف غير موجود" ، فإن الأخطاء المتعلقة بهذا المجال - لدينا حوالي 15 أو هكذا نستضيفها على هذه الخوادم - كنت أتساءل عما إذا كان من الأسهل القيام بما يلي ببساطة عند 404 يحدث خطأ:

• إعادة التوجيه إلى صفحة PHP وتمرير طلب عنوان URL الأصلي
• اطلب من صفحة PHP الجديدة تفريغ عنوان URL إلى ملف تسجيل الدخول

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

Answer 1

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

فكرة تسجيل 404 أخطاء بهذه الطريقة ليست جديدة: لقد رأيت ذلك تم القيام به عدة مرات ، ولم تواجه أي مشكلة كبيرة في ذلك (أكبر مشكلة رأيتها كانت ملفًا كبيرًا بسرعة كبيرة ، لأنه كان هناك الكثير من الأخطاء ^ ^)

على سبيل المثال ، يقوم Drupal بعمل قليل من هذا: يتم تسجيل الأخطاء 404-ولكن إلى قاعدة بيانات ، لذلك من الأسهل تحليلها باستخدام واجهة الويب.

Answer 2

حسنًا ، مجرد أشياء نظام الملفات المعتادة: لا تدع المستخدم يحدد أين سيذهب الملف: أشياء مثل script.php?filename=../../../../../../../etc/passwd لا ينبغي حتى الحصول على فرصة للكتابة إلى /etc /passwd (أيضا لا ينبغي أن يكون للنص أذونات FS لذلك). بخلاف ذلك ، لا يحتوي Fwrite () على أي chars خاصة من شأنها أن تسمح لها بالقفز إلى نوع من وضع الأوامر.

أيضا ، صفحة 404 بسيطة جدا (في httpd.conf):

ErrorDocument 404 /error_page.php

وفقط REQUEST_URL إلى ملف

Answer 3

يجب أن يكون اللوني آمنًا جدًا.

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

Answer 4

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

Answer 5

هناك مشكلة محتملة يجب البحث عنها هي إذا كنت تكتب سجلات على أنها HTML (أو نوع ملف آخر يحدث للسماح بتضمين التعليمات البرمجية). هذه الملفات هي بالطبع معرضة لهجمات XSS.

Answer 6

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

1. تأكد من أن الملف الذي تكتبه لا يمكن تقديمه كـ HTML بواسطة خادم الويب
2. النظر في ترميز URL أو HTML ترميز عناوين URL.

Answer 7

يجب أن تقوم بالفعل بتسجيل الأخطاء 404 في error_log.

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