Home أمن المعلومات هل تهتم لحماية التطبيق قبل أو بعد الانتهاء من البرمجة ؟
هل تهتم لحماية التطبيق قبل أو بعد الانتهاء من البرمجة ؟

هل تهتم لحماية التطبيق قبل أو بعد الانتهاء من البرمجة ؟

179
1

كنت في مناقشة مع أحد المطورين حول تطوير برنامج مختص بال Authentication يعمل على الاندرويد، وبما أن البرنامج يصنف تحت برامج الحماية Security Applications فقد أفترضت أن صديقنا سوف يراعي كل ال Standards المستخدمة في تطوير الأنظمة الأمنة (استخدام مثلاً RSA  بمفاتيح كبيرة مثلاً 2048  على الأقل، استخدام الشهادات الرقمية  Certificates الخ..) ولكن صدمت عندما وجدت ان التشفير في برنامجه هو عباره عن عملية حساب لل Hash فقط (تحقق من البيانات اي بعباره اخرى فحص للIntegrity للبيانات) وهل تغيرت أم لأ.

لننسى نقطة ان Data Integrity هي ليست الا فائده أولى من فوائد التوقيع الرقمي Digital Signature، ولننسى نقطة أن أغلب المواقع العربية ما زالت تسمي الـ Hash بالتشفير Encryption  ، ولنركز حول أخر فقرة في النقاش وهي بعدما عرف ان هذا لن يكون برنامج جيد لأنه بلا اي حماية وقابل للاختراقات، بأنه سوف يقوم فيما بعد باستخدام خوارزمية تشفير بمفتاح واحد Symmetric Key (مثل AES) ويقوم بعمل مفتاح واحد وينشره بين مستخدمين البرنامج، لأنه برنامج محدد للأقارب مثلاً وبالتالي الجميع يعرف ويثق الآخر.

لذلك السؤال المطروح: هل تقوم بعمل الحمايه في تطبيقات الحماية قبل أو بعد الانتهاء من المشروع (هل تتبع Designing in Security أو لا تتبعها).

ال Designing-In Security يعني أنك ستدخل مسائل التحقق والتشفير والbackup وكل جوانب الحماية في كل مرحلة من مراحل التطوير سواء كانت في مرحلة متطلبات المشروع Requirement أو كانت في مرحلة وضع هيكله المشروع، ولا يجب بالبدء البرمجة وبعد ذلك تفكر باضافة طبقة الحمايه لاحقا.

لماذا؟ لن أقول لك لماذا ، ولكن دع التاريخ يسرد نفسه ويريك الحقائق…

نظام ويندوز 98:

windows98

بسبب تم دعم نافذه السؤال عن اسم المستخدم والباسورد password dialog بعد صدور نسخ الويندوز الأولى، فمن خلال ال Safe Mode (عند اقلاع الجهاز بعد الضغط على F8) يمكن تجاوز هذه النافذه والدخول مباشرة للنظام. هذا بسبب أن هذه الحماية الأولى لم تكن في التصاميم الأولية للنظام Initial Design والا فكان المفترض ان يتم السؤال عن تلك المعلومات حتى اثناء الدخول في ال Safe Mode.

 هذا مثال واحد على ان اضافة الSecurity كLayer جديدة في النظام قد لا تنفع.

الإنترنت Internet:

internet

أحد الأمثلة الأخرى التي تبين لنا مدى صعوبة ادخال ال Security بعد اطلاق الأنظمة هو الأنترنت، فعندما صممت هذه الشبكة كانت كل الأجهزة التي تتصل ببعضها موثوقه لأنها كل كانت تتبع لجهات عسكرية أو جامعات. وبعد ذلك في منتصف التسعينيات عندما توسعت الشبكة ودخلت كثير من أجهزة الشركات والأفراد الشبكة  بدئت بعض الجهات باستخدام ال Firewalls للحماية. ال Firewall يقوم بايقاف كل البيانات التي لا تريدها من اي مصدر تقوم بتحديده، لكن المشكلة التي حدثت هو أنك يمكن أن تتلاعب في الباكت نفسه IP Packet وتقوم بتغيير عنوان المرسل في الباكت الخارج منك الى عنوان B وترسله الى الجهاز A والذي يثق فيه وسيتم دخول الباكت بواسطة الFirewall والسبب أنه يسمح لB بالتعامل معه لأنه موثوق.

spoofing

هذه كانت من احدى مشاكل التصاميم الأولية لشبكة الانترنت وبالتحديد TCP/IP ويمكنك قرائه الورقة العملية التي تصف المشكلة بالتفصيل:

https://www.cs.columbia.edu/~smb/papers/ipext.pdf

أو قرائه هذه المقالة من سميانتيك: IP Spoofing: An Introduction

ولو تم تصميم البرتوكول منذ الأول على اساس عدم الوثوقية والحماية لكن الأمر مختلف الآن.

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

أتمنى من الصديق قرائه هذه المقالة

(179)

وجدي عصام مهندس برمجيات مهتم بعلوم الحاسب وبالأخص مجال الخوارزميات وهندسة البرمجيات وحماية التطبيقات،

Comment(1)

LEAVE YOUR COMMENT

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

مشاركة