بسم الله الرحمان الرحيم

نقلا عن :مركز التميز لامن المعلومات بقلم :خالد الفهيد
الرابط الاصلي للموضوع :http://coeia.edu.sa/index.php/ar/asu...ity-holes.html
وقمت بننقلة في القسم العام لان الموضوع يشمل جميع المطورين باتجاهاتهم البرمجية المتنوعة وليس لغة برمجة واحدة.

ثقافة الحماية لدي المطورين : أهم الثغرات الأمنية


لو طلب من أحد من المبرمجين أن يعرف متى تنتهي مهمة المبرمج(المطور) ؟ لقال عندما يحقق البرنامج جميع المتطلبات المحددة و يعمل بدون أخطاء . قد يكون هذا التعريف مقبول سابقاً، لكن بالتأكيد ليس اليوم في مثل هذا العالم الذي كثرت فيه الاختراقات الأمنية . على سبيل المثال في السابق تنتهي مهمة المبرمج(المطور) بمجرد أن ينهي مجموعة الدوال التي تشكل البرنامج ثم يختبرها ويحصل على النتائج المتوقعة . فلو كان متطلب برمجة دالة لإيجاد حاصل ضرب عددين لأدخل عددين 3*6 فإذا كان الناتج 18 تنتهي مهمته؛ وإلا لاحتاج إلى إعادة النظر مرة أخرى بالدالة واختبرها . ومما يجدر الإشارة إليه أن كثير من المطورين يكون محور اهتمامهم فقط كتابة كود برمجي يمكن تشغيله بدون أخطاء، وقد يغيب عن البعض أهمية التأكد واختبار متانة البرنامج من جانب الحماية والثغرات الأمنية . وقد يقول معظم المطورين أن مهمة الحماية للبرنامج منوطة بشخص متخصص بالحماية وليس وظيفة المبرمجين حيث أني لا أملك خلفية متينة عن الثغرات الأمنية . وهنا تكمن المشكلة ، فالواقع يبين لنا أن السبب وراء أي ثغرة أمنية هو ضعف الكود البرمجي . بمعنى آخر عدم مبالاة المبرمجين عند كتابة الكود إلى احتمالية مهاجمة الكود بهجمات معروفة .

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

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

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







أولا Buffer overflow () [1]:

ويمكن تعريفة أن عندما يرسل المعالج كمية أكبر من البيانات إلي المكان المحجوز لها بالذاكرة ، فعلي سبيل المثال تخيل لو أن لدينا كوب من الماء يتسع300 ملم (الذاكرة) ، ثم ملائناهة ب400 ملم . بالتأكيد سيحصل طفح وسنخسر 100 ملم (بيانات). و يعتبر من أخطر التهديدات الأمنية للبرامج حيث أنة يجعل البرنامج بحالة غير مستقرة أو قد يؤدي إلي توقف البرنامج عن العمل كليا . ومن ناحية أمنية يمكن أن يستغل المخترق هذه الحالة بالذاكرة إلي جعل مؤشر الذاكرة يقرأ من كود المخترق الذي خزنة بالذاكرة مسبقا ؛ ويتحيل الفرصة المناسبة لجعل المعالج يشير إليه ويبدأ بتنفيذه . مما يعرف باسم stack –smashing attacks . أو قد يقوم المخترق بتغير بعض البيانات مما يسمح بدخول بدون المرور بعملية التأكد من اسم المستخدم وكلمة المرور. ويمكن القول أن هناك عدة أساليب للحماية من هذا التهديد الأمني .

أولا يجب على المبرمجين الحذر والانتباه أثناء كتابة أي كود يتعامل بشكل مباشر مع الذاكرة مثل دالة النسخ strcpy(). حيث يجب التأكد من عدم إرسال قيمة أكبر للذاكرة المحجوزة وذلك باستخدام الجمل الشرطية مثلا . أو استخدام الدوال التي لديها حدود للنسخ مثلا بلغة C strncpy() بدلا من strcpy(). وكذلك استخدام بعض لغات البرمجة التي لديها خاصية التأكد الآلي وملائمة مساحة الذاكرة مع البيانات المراد كتابتها عند عملية النسخ مثل جافا. وأخيرا استخدام بعض الدوال التي تجعل عملية متابعة العناوين بالذاكرة مهمة صعبة التنفيذ[1][1]


http://coeia.edu.sa/images/stories/p...r-overflow.jpg


ثانيا : Race Condition [2]

يعرف بأنه عندما يقوم المعالج بتنفيذ دالتين بنفس الوقت ، وكان يتوجب أن تنفذ بشكل متتالي مما يؤدي إلي نتائج غير مقبولة . فعلي سبيل المثال لدينا عمليتنا نريد تنفيذهما على نفس المتغير بالذاكرة X،

وليكن القيمة الابتدائية للمتغير 0 و نريد إضافة متغيرات أخرا . فنجد العديد من النتائج التي ممكن الحصول عليها ، وليست النتيجة المرادة مثلا ..


http://coeia.edu.sa/images/stories/p...-Condition.jpg

http://coeia.edu.sa/images/stories/p...Condition1.jpg


من ناحية أمنية ما يهمنا هو احتمالية وقوع اختراق أمني Time-of-check, time-of-use (TOCTTOU) مما يسمح للمخترق للدخول للملف قبل التحقق من هوية المستخدم . فل نفرض بالمثال السابق إن دالة التأكد من هوية المستخدم هي مكان X لاستطاع المخترق الدخول والوصول للملف (السطر الثالث) دون التأكد من الهوية لأنة سوف يتم فتح الملف قبل المرور بدالة التحقق من الهوية . والكود بالأسفل يبين ذلك .


http://coeia.edu.sa/images/stories/p...Condition2.jpg

ويمكن الحماية من هذا الاختراق بعدة طرق و أهمها هو عند كتابة الكود يجب إبقاء الملف مغلق حتى الانتهاء من الكتابة أو القراءة بحيث يمنع عملية التزامن . أو يمكن استخدام خاصية المزامنة بالجافا Synchronized Objects in Java[3[2]]


ثالثا : [4] Code Injection



وهو أن يقوم المخترق بإدخال قيم (كود برمجية) بدلا من القيم المتوقعة للبرنامج مما يؤدي إلي توقف البرنامج في بعض الأحيان أو الحصول على نتائج غير متوقعة. ويعتبر هذا التهديد الأمني له عدة أشكل منها SQL injection, Script injection, URL injection, , فمثلا عندما يواجه المخترق شاشة مرور وتطلب من إدخال اسم مستخدم وكلمة مرور ، فيقوم المخترق بكتابة “password OR 1=1” بدلا من إن يدخل كلمة المرور. لأنة إما أن يكون اسم المستخدم صحيح أو أن يكون ناتج الجملة 1=1” صحيح ، فبالتالي ناتج الجملة دوما يكون صحيح . فيسمح للمستخدم بالدخول ، والكود بالأسفل يوضح جملة SQL تحاول استرجاع بيانات والتأكد منها


http://coeia.edu.sa/images/stories/p...-Injection.jpg


وهناك عدة وسائل للحماية من هذا الاختراق مثل فلتره المدخلات وعدم السماح بإدخال الرموز التي تستخدم باللغات البرمجية مثل ":و;< || ، #، &&" . وكذلك استخدام بعض الأدوات الاختبار التي تبين مثل هذه الثغرات. ويعتبر من أشهر الأنواع التهديدات Cross-Site Scripting (XSS) حيث تشير الإحصائيات إلي أن 80% من المواقع عانت من مشاكل أثر هذا النوع في عام 2007. وذلك لسهولة إضافة <JavaScript> داخل أي خانة إدخال بيانات ، ويتم تنفيذها بشكل مباشر . ولذلك تجدر الإشارة لوعي المطورين لمثل هذه الثغرات .



رابعا: Format String

مثل هذا التهديد بالحقيقة هو دالة داخل لغات البرمجة ، بمعنى أخر يستطيع المخترق الاستفادة منه ولتتضح الصورة انظر للكودين بالأسفل :

http://coeia.edu.sa/images/stories/p...mat-String.jpg


نجد الفرق الوحيد بينهما printf(“%s”, p); أي كلا الكودين يعمل بشكل ممتاز إلا أن الكود الأول كان المبرمج متكاسل لإضافة أوسمة الدالة الإضافية وهنا تكمن الخطورة ، حيث يمكن أن يدخل المخترق هذه الأوسمة ويسترجع جميع البيانات فالذاكرة . ولتفادي مثل هذه التهديدات ينصح دوماً بملء أي خيارات إضافية مع الدوال حسب ما يراه المبرمج مناسب ليخدم صالح البرنامج . أو سيأخذ المخترق هذه الفراغات ويملأها بما يناسبه لعملية الاختراق.

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



المراجع :


1- J. Viega and G. Mcgraw, Building Secure Software: How to Avoid Security Problems the Right Way (Addison-Wesley Professional Computing Series). Addison-Wesley Professional, October 2001.
2- http://www.owasp.org/index.php/Revie...ace_Conditions.
3- The Java Tutorials: Intrinsic Locks and Synchronization,
http://java.sun.com/docs/books/tutor.../locksync.html
4- http://www.owasp.org/index.php/Code_Injection

--------------------------------------------------------------------------------

[1] ] J. Viega and G. Mcgraw, Building Secure Software: How to Avoid Security Problems the Right Way (Addison-Wesley Professional Computing Series). Addison-Wesley Professional, October 2001.

-------------
اننتها النقل


واخيرا ان اصبت خيرا في نقلي فمن الله وحدة ونا اصبت خطاء فمن نفسي والشيطان