Posts tagged 'PHP5'
PHP: الدليل على أهمية التحديث
بداية تشرفت بالعمل فى إمارة مكة المكرمة و بصحبة عدد من التقنيين المحترمين و حقيقة أنا سعيد بالعمل معهم, و ثانيا هذا الموضوع غير ذى صلة ب PHP 5.2.0 أو ما يليها و لكنه للتدليل على أهمية تحديث PHP كلما كان ذلك ممكنا و كلما توافرت نسخة جديدة و مستقرة.
و لأستطيع بيان وجهة نظرى سوف أذكر حالة حدثت بالفعل فى PHP و سببت ثغرة أمنية إعتبرت فى ذاك الوقت خطيرة ليس على PHP وحدها (و لنا فى هذا مقال إن شاء الله)
أى برنامج يأخذ القيمة المدخلة بواسطة المستخدم و يضعها فى متغير و الذى بدوره تقوم PHP بتخزينه فى ال STACK (عذرا فلم أستمزج أن أقتنع بترجمة معينة لهذة الكلمة - كما هو الحال مع ال specifikacija), و على افتراض أن القيمة النصية المدخلة أكبر من المساحة المخصصة للمتغير فى ال STACK و بما أن حجم المتغير لا يتم تحديده فى PHP-u, و هذا يعنى أنه نظريا ممكن يكون بأى حجم, و لكن عمليا هو محدد بحجم الذاكرة المتاحة على الخادم (أبسط تعريف ممكن), فى عام 2006 و تقريبا فى الشهور الأخيرة (لا أذكر التاريخ تحديدا) تم اكتشاف ثغرتين فى PHP من أهم و أخطر الأشياء التى حددت مستقبل اللغة فيما بعد, و الثغرتين هما: htmlspecialchars و htmlentities
هما "وظيفتان" - كما يحلو لى ترجمة FUNKCIJE أو "دالتان" بالترجمة المتعارف عليها - من ضمن البنية الأساسية ل PHP و فكرة عملهما أن وسوم HTML لا تكون أكثر من ثمانية أحرف و هذا صحيح فى معظم الأحيان, و (لكن) و عند استخدام UTF -8 و قيام PHP بالتدقيق على البيانات التى سوف تقوم بتمريرها هذه "الوظائف" و تجد أنها (البيانات) تزيد على الثمانية أحرف فإن PHP و بكل بساطة تزيد المساحة بمقدار حرفين (أصبح الناتج عشرة أحرف) و تحدث الثغرة بدءا من تمرير إحدى عشر حرفا (و هو ما يتمكن عن طريقه المهاجم أو "القرصان" من تمرير أى شفرة يرغب عن طريقها فى الحصول على بيانات بطريقة غير مشروعة).
و هنا يجدر بى الشرح قليلا لموضوع الأحد عشر حرفا (غاية فى الأهمية) و هو ال UTF-8, إحدى أساليب معالجة تشفير اللغات فى ال UNICODE بما يسمح باستخدام الأحرف من خارج الأبجدية الرومانية لعرض ال Opcija JEZICI مثل العربية و الروسية و لغات أخرى, و تقريبا تشمل ال UNICODE القياسية كل اللغات المتداولة, و هى لغات كل حرف فيها يتم رسمه بأكثر من BYTE واحد و إخترعت فى الأساس لحل مشاكل محدودية جدول ال ASCII و جدير بالذكر أن ASCII 128 (و هى الجدول المستخدم فى الحوسبة عموما) تحتاج فى تشفيرها للحروف إلى BYTE واحد فإذا عادلنا حرف من جدول ال ASCII بال UTF-8 نجده ما زال حرفا واحدا, و ال UNICODE القياسية تحتاج إلى ثلاثة BYTE لتتضمن (افتراضيا) معظم الأحرف المستخدمة فى كل اللغات تقريبا كما سبق و ذكرنا, و فى ال UTF-8 نجدها تحجز أربعة BYTE و لا نعتقد أن ال BYTE الرابع فارغ أو غير ضار (و هو ما سنحاول اثباته فى كتابنا ان شاء الله).
نخرج من هذه القصة العريضة (أعتذر عن الإطالة) بحتمية تحديث ال PHP كلما توفرت نسخة مستقرة و مراعاة تحديث الأنظمة و ملفاتها و مكتباتها الأساسية و الفرعية كلما أمكن ذلك, و المحصلة أنه بما أن هذه المشكلة أو القصور قد كان و تم التعامل معه فى PHP 5,2 و ما بعدها فإن هذا لا يعنى عدم وجود مشكلات أخرى قد تكون أكبر و لكنها مختفية أو لنقل أنها لم تظهر بعد, و الغريب أن نفس المشكلة ظهرت من قبل فى وظيفة أخرى قبل هاتين الوظيفتين و هى omatanje riječi وقد تم حلها. المقصود أيضا من كلامى أنه لا يمكن الإعتماد على PHP وحدها لإبقاء برامجنا آمنة و خالية من القصور و المشاكل الأمنية, بل لابد لنا من الدفاع عن شفرة برامجنا و بياناتنا بأساليبنا البرمجية التى قد تكون فى بعض الأحيان معقدة لخدمة غرض آخر أكبر و أهم و هو " الأمن ".
ملحوظة: هذا المقال لا يعنى شيئا بلا مناقشات حقيقية حول أساليب الحماية البرمجية و للحديث جزء آخر عن إعدادات ال php.ini
المراجع
- Web aplikacija hakeri priručnika
- أخطاء المبرمجين الأمنية (كتابنا الذى لم ننته منه بعد) إدعوا لنا بالتوفيق
- php.net
- unicode.org
