Second Life Blog

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

و ﻷستطيع بيان وجهة نظرى سوف أذكر حالة حدثت بالفعل فى PHP  و سببت ثغرة أمنية إعتبرت فى ذاك الوقت خطيرة ليس على PHP وحدها (و لنا فى هذا مقال إن شاء الله)

أى برنامج يأخذ القيمة المدخلة بواسطة المستخدم و يضعها فى متغير و الذى بدوره تقوم PHP بتخزينه فى الـSTACK (عذراً فلم أستمزج أن أقتنع بترجمة معينة لهذة الكلمة – كما هو الحال مع الـPARAMETER) ، و على افتراض أن القيمة النصية المدخلة أكبر من المساحة المخصصة للمتغير فى الـSTACK و بما أن حجم المتغير لا يتم تحديده فى PHP ، و هذا يعنى أنه نظرياً ممكن يكون بأى حجم ، و لكن عملياً هو محدد بحجم الذاكرة المتاحة على الخادم (أبسط تعريف ممكن) ، فى عام 2006 و تقريباً فى الشهور الأخيرة (لا أذكر التاريخ تحديداً) تم اكتشاف ثغرتين فى PHP من أهم و أخطر الأشياء التى حددت مستقبل اللغة فيما بعد ، و الثغرتين هما: htmlspecialchars و htmlentities

هما “وظيفتان” – كما يحلو لى ترجمة FUNCTIONS  أو “دالتان”  بالترجمة المتعارف عليها – من ضمن البنية الأساسية لـPHP و فكرة عملهما أن وسوم HTML لا تكون أكثر من ثمانية أحرف و هذا صحيح فى معظم الأحيان ، و (لكن) و عند استخدام UTF-8  و قيام PHP بالتدقيق على البيانات التى سوف تقوم بتمريرها هذه “الوظائف” و تجد أنها (البيانات) تزيد على الثمانية أحرف فإن PHP و بكل بساطة تزيد المساحة بمقدار حرفين (أصبح الناتج عشرة أحرف) و تحدث الثغرة بدءاً من تمرير إحدى عشر حرفاً (و هو ما يتمكن عن طريقه المهاجم أو “القرصان” من تمرير أى شفرة يرغب عن طريقها فى الحصول على بيانات بطريقة غير مشروعة).

و هنا يجدر بى الشرح قليلاً لموضوع الأحد عشر حرفاً (غاية فى الأهمية) و هو الـUTF-8 ، إحدى أساليب معالجة تشفير اللغات  فى الـUNICODE بما يسمح باستخدام الأحرف من خارج الأبجدية الرومانية لعرض الـMULTIBYTE LANGUAGES مثل العربية و الروسية و لغات أخرى ، و تقريباً تشمل الـUNICODE القياسية كل اللغات المتداولة ، و هى لغات كل حرف فيها يتم رسمه بأكثر من BYTE واحد و إخترعت فى الأساس لحل مشاكل محدودية جدول الـASCII و جدير بالذكر أن ASCII 128 (و هى الجدول المستخدم فى الحوسبة عموماً) تحتاج فى تشفيرها للحروف إلى BYTE واحد فإذا عادلنا حرف من جدول الـASCII بالـUTF-8 نجده ما زال حرفاً واحداً ، و الـUNICODE القياسية تحتاج إلى ثلاثة BYTES لتتضمن (افتراضياً) معظم الأحرف المستخدمة فى كل اللغات تقريباً كما سبق و ذكرنا ، و فى الـUTF-8 نجدها تحجز أربعة BYTES و لا نعتقد أن الـBYTE الرابع فارغ أو غير ضار (و هو ما سنحاول اثباته فى كتابنا ان شاء الله).

نخرج من هذه القصة العريضة (أعتذر عن الإطالة) بحتمية تحديث الـPHP كلما توفرت نسخة مستقرة و مراعاة تحديث الأنظمة و ملفاتها و مكتباتها الأساسية و الفرعية كلما أمكن ذلك ، و المحصلة أنه بما أن هذه المشكلة أو القصور قد كان و تم التعامل معه فى PHP 5.2 و ما بعدها فإن هذا لا يعنى عدم وجود مشكلات أخرى قد تكون أكبر و لكنها مختفية أو لنقل أنها لم تظهر بعد ، و الغريب أن نفس المشكلة ظهرت من قبل فى وظيفة أخرى قبل هاتين الوظيفتين و هى wordwrap وقد تم حلها. المقصود أيضاً من كلامى أنه لا يمكن الإعتماد على PHP وحدها لإبقاء برامجنا آمنة و خالية من القصور و المشاكل الأمنية ، بل لابد لنا من الدفاع عن شفرة برامجنا و بياناتنا بأساليبنا البرمجية التى قد تكون فى بعض الأحيان معقدة لخدمة غرض آخر أكبر و أهم و هو “الأمن”.

ملحوظة: هذا المقال لا يعنى شيئاً بلا مناقشات حقيقية حول أساليب الحماية البرمجية و للحديث جزء آخر عن إعدادات الـPHP.ini

المراجع

• The web applications hackers handbook
• أخطاء المبرمجين الأمنية (كتابنا الذى لم ننته منه بعد) إدعوا لنا بالتوفيق
• php.net
• unicode.org