عادة يركز مطور البرمجيات على المهام الوظيفية لل Task بتاعته فى انها تطلع المطلوب منها وبس بغض النظر عن الجوانب الاخري اما عن ضيق الوقت او محاولة انجاز اكبر قدر ممكن من Tasks لذلك هنحاول نوضح الصورة الكبيرة وهنركز على security فى المقال ده
لكل تطبيق [software] جانبين للمتطلبات :
- متطلبات وظيفية [Functional Requirements]
اختصارا ده الحاجة الاساسية اللى البرنامج بيقدمها مثال : موقع تسوق يبقى عندي سلة اقدر احط فيها المنتج وبعدين اختار وسيلة الدفع واطلب المنتج
- متطلبات غير وظيفية [Non-Functional Requirements]
- القابلية للنقل (Portability)
- الأمان (Security)
- سهولة الصيانة (Maintainability)
- الموثوقية (Reliability)
- التوسعية (Scalability)
- الأداء (Performance)
فى كثير من الاحيان بتكون المتطلبات الغير وظيفية مهمة وبتتحول ل متطلبات وظيفية مثل
- انطمة البنوك هنا ال Security متطلب اساسي ووظيفى
- الانطمة الطبية هنا هيكون Performance مهم واساسي
فى المقال ده هنركز على Security ولحسن الحظ فيه دليل على اكثر الاخطاء او الثغرات حدوثا عشان نتعلم منها وهي
OWASP TOP 10 Open Web Application Security Project
- Broken Access Control
اخطاء فى ضبط الصلاحيات وحماية البيانات مما يتيح لغير المصرح لهم الوصول او تعديل البيانات
مثال : تخزين البيانات على AWS S3 وترك الملفات متاحة للجميع ظنا منك انه لايمكن لاحد تخمين الرابط المؤدي لهذه الملفات
مثال : انك تكون بتجرب ال code بتاعك local على الجهاز بتاعك وتخلي ال code من غير Authentication وتنسي تشيلها وده ممكن نمنعه ب code review
او ِArchitecture test
وممكن تشوفها هنا https://www.youtube.com/playlist?list=PLSscGdsqWz_KK4QQkoVzefcli60y2q9ED
- Cryptographic Failures
اخطاء فى التشفير او لا يوجد تشفير على الاطلاق ينبغى ان يتم تشفير البيانات الحساسة كل الباسورد – رقم الحساب – رقم البطاقات فى جميع حالاتها rest and transit بمعني انها خلال النقل او متخزنة فى قاعدة بيانات او ملف
فى الحقيقة هنا بتيجى اسئلة كتيرة زي مين ليه صلاحية انه يشوف data دي اصلا مين يقدر يفتح databaseمن غير باسورد وهنا محتاجك تجاوب على الاسئلة دي
- هتعمل ايه لو حد قدر يحصل على نسخة من database ؟
- لو حد قدر يبقى فى النص بينك وبين اليورز man in the middle attack
- لو موظف مش امين او غاضب وقرر الانتقام
- Injection
عملية ادخال بيانات غير صحيحة او ضارة وهنا الثغرة دي فى الغالب بيتم استخدامها فى الحصول على البيانات او ادخال اكواد بتم استخدامها فى ثغرات اخري واكبر مثال علي الثغرة دي هو SQL Injection
txtUserId = getRequestString(“UserId”);
txtSQL = “SELECT * FROM Users WHERE UserId = ” + txtUserId;
دلوقني لو غيرنا ال UserId ل 105 OR 1=1 هيكون ساعتها جزء من sql وهيرجع بكل ال data عشان ال condition OR هيتحقق ويجيب كل الداتا
المثال التاني انه يقدر يخزن اكواد على سبيل المثال Cross-Site Scripting (XSS) لما ترجع لمستخدم تاني تنفذ الاكواد دي عنده
وللحماية من الهجمات دي بنحتاج حاجتين input validation واستخدام ORM وهنوضح ده ف الاخر ان شاء الله
- Insecure Design
تصميم غير امن وده مشكلة فى التصميم للتطبيق ككل ومش على مستوي ال task بتاعتك
مثال على ده ممكن يكون على مستوي network او ازاي المكونات للتطبيق بتكلم بعض او على مستوي architect مفيش فصل مابين مديرين التطبيق و مستخدميه وهكذا
وللحماية من الثغرات دي لازم ولابد اشراك عناصر الخبرة و المهندسين الامنين security engineers فى مرحلة التصميم والمراحل الاوليه
- Security Misconfiguration
تكوين امني خاطي وهي اعدادات خاطئ او افتراضية لم يتم ضبطها بالشكل الصحيح او عدم التحديث المستمر للنطام
ولذلك يجب محاولة استخدام “best practices” لضبط الاعدادت واستخدام برامج للكشف عن الاعدادات غير الصحيحة
- Vulnerable and Outdated Components
فى اغلب التطبيقات احنا مش هنعيد اختراع العجلة فى بستخدم اكواد جاهزة عشان كده محتاج يكون متابع كل المكونات المستخدمة وتحدثها فى حالة انها بيكون فيها ثغرات وللاسف الجزء ده بيتنسي مع الوقت عشان كده انت هاتكون محتاج اداة static code analysis tools تساعدك فى انها تكشف لك ده وتمنعك فى حالة انك نسيت وكمان ممكن تدمجها فى ال pipeline بتاعك وبترفع من جودة المطورين معاك مثال ال sonarcloud
- Identification and Authentication Failures
فشل التحقق من الهوية والمصادقة وده ممكن يحصل لو مقدرتش افرق مابين المستخدم صاحب الباسورد و اي حد تاني قدر يحصل عليها اما بالتخمين او التصيد (Phishing) او اي وسيلة اخري
وهنا عشان اتجنب المشكلة دي محتاج احط سياسات policies الزاميه زي الباسورد لازم يكون معقد التحقق الثنائي Multi- Factor Authentication استخدام ال OAuth أو OpenID
- Software and Data Integrity Failures
فشل أمان البرمجيات والبيانات وهو ادخال كود او بيانات للنطام بسببها يا المخرجات بتاعت التطبيق غلط او التطبيق هو نفسه بشتغل غلط
مثال على ده برامج الفدية وفقدان البيانات او التلاعب فى التطبيق الاصلي والمستخدمين بيستخدمه التطبيق ده
- Security Logging and Monitoring Failures
فشل تسجيل ومراقبة الأمان وهو عدم تسجيل البيانات والمعلومات الكافية للكشف عن اختراقات وهنا النوع ده مهم لان المخترق بيقدر يمسح اي حاجة بتدل عليه كمان لو حصل عندك اختراق هتحتاج تتصرف بناء على المعطيات دي
هنا بنحتاج ادوات نسجل عليها كل العمليات ف النظام وهي بتنبهنا وتبعت اشعارات لاي انشطة غير طبيعية
- Server-Side Request Forgery (SSRF)
تزوير الطلبات من جانب الخادم وهي ان يتم تزوير الطلبات داخل network هنفترض ان فيه عندك اكتر من service ف التطبيق بيخدموا ال frontend بتاعك ف ال request بيجي يعدي على gateway لل authentication بعد كده ال gateway بتروح تكلم order service وبعد كده تكلم ال shipping service لو قدر ال attacker انه يحصل على ثغرة فى order service ممكن يطلع request يبان انه طالع من ال gateway وينفذ actions مش مسموحة
بعد ما اتعرفنا على الاخطاء و الثغرات الاكثر حدوثا محتاجين نعرف ازاي اقدر امنعها على قدر الامكان
- فى مرحلة التصميم
- فى مرحلة التنفيذ
- فى مرحلة مابعد التنفيذ
- فى مرحلة التصميم
- فى مرحلة التنفيذ
- المراجعة من خلال seniors and leaders وذوي الخبرة
- استخدام ادوات الفحص static code analysis tools
- ادوات فحص والبحث عن الكلمات المخزنة والمثبتة فى الكود
- فى مرحلة مابعد التنفيذ
- Penetration testing
- Vulnerability Scanner tools
نضائح عامة لتجنب الاخطاء والثغرات
- Input Validation
زي ما وضحنا قبل كده ان ده هايمنع ال Injection و هيأدي ل Data integrity
ال validation بيكون نوعين النوع : نوع بيخدم ال business requirement
ونوع بيخدم ال security بالنسبه لل security بيكون اسمه تطهير sanitizationبيتم ب 3 طرق و مهم يكون موجد backend and frontend
- Blacklist
رفض اي مدخل فيه حروف او رمز غير مسموح
- Whitelist
السماح ب حروف او رمز معينة
- Escaping
قبول اي مدخل مع تنظيفه ومسح اي من الحروف والرمز غير المرغوبة
- استخدام التطبيقات و الحلول الامنية المبنية من الخبراء وتجنب اختراع العجلة خصوصا فيما يتعلق ب authentication and authorization
- لو بتعمل تطبيق للموبايل او ال desktop هتحتاج نوع من الحماية ضد الهندسة العكسية reverse engineering ذي ال obfuscations
- استخدم برامج الحماية على الاجهزة المستخدمة
- استخدم الادوات اللى بتعمل فحص فى مرحلة الكود و مرحلة النهائية
- استخدام سياسات لتغيير الباسورد ومنح الاذونات المهمة فى النظام وينبغي تدريب وكتابة تلك السياسات
- مراجعة الاكواد بواسطة العناصر الخبرة
- ادخال security engineers فى مراحل التصميم
- خليك على علم بالتغييرات اول باول
- خلى المكتبات المستخدمة لاخر نسخة مستقرة
- استخدم مكان امن لحفظ الكلمات السرية زي AWS Secret manager و اوعي تخزن باسورد فى الكود او على ال source control
- تشفير البيانات المهمة بشكل مشفر واستخدام تشفير امن وصعب الكسر
- اضافة ال headers المهمة للمتصفح ده بيوفر لك نوع من الحماية ذي
- X-XSS-Protection
- X-Content-Type-Options
- Referrer-Policy
- Strict-Transport-Security (HSTS)
- Content-Security-Policy (CSP)
- Access-Control-Allow-Origin
- Cross-Origin-Resource-Policy (CORP)
- Content-Type
- X-Frame-Options
ازالة ال headers اللي بتكشف معلومات عن ال server
X-Powered-By
Server
X-AspNet-Version
X-AspNetMvc-Version
- استخدام ORM هيمنع ال sql injection عشان بيستخدم ال parametrized query وده بيخليه يتعامل مع اي input كا string مش جزء من ال Query بس خلي بالك معظم ال ORMs بتديك امكانيه انك تكتب SQL Query بايدك ف ده ممكن يخليك تتعرض ل SQL injection
