السلامة مع أمثلة الحياة الحقيقية هي دائما أكثر إثارة للاهتمام.
كاختبار للاختراق ، أحب عندما تأتي المشروعات القائمة على أطر تطوير Rapid ، مثل Ruby-on-Rails و Django و AdonisJs و Express وما إلى ذلك. إنها تتيح لك إنشاء نظام بسرعة كبيرة نظرًا لأن نماذج الأعمال تتخطى على الفور جميع المستويات ، بما في ذلك متصفح العميل. النماذج (نماذج من كائنات الأعمال في قاعدة البيانات) و ViewModel (عقد للتفاعل مع العملاء) غالباً ما يتم دمج هذه الأُطُر معًا لتجنب التحول غير الضروري من النموذج إلى ViewModel والعكس صحيح ، يتم إنشاء خدمات REST تلقائيًا. من وجهة نظر التطوير ، يمكنك ببساطة تطوير نموذج أعمال على الخادم ، ثم استخدامه فورًا على العميل ، مما يؤدي بلا شك إلى زيادة سرعة التطوير.
مرة أخرى ، أنا لا أقول أن الأطر المذكورة أعلاه سيئة ، أو أن هناك شيئًا ما خاطئًا لديهم ، ولديهم وسائل وأدوات الحماية المناسبة ، بل إن المطورين يرتكبون معظم الأخطاء معهم. شوهد هذا أيضًا في مشروع ASP.NET MVC واحد ، حيث قام المطورون بعمل نفس الثغرات الأمنية عن طريق فضح النماذج بدلاً من ViewModels ...
الثغرة الأمنية: نظرًا لضعف التحقق من صحة حقول النماذج الواردة من العميل ، يمكنك حقن الحقول التي لا توفرها الوظيفة ، ولكن في نموذج الأعمال. على سبيل المثال ، هناك طريقة تسمح لك بتغيير اسم المستخدم فقط وإرجاع كائن ملف تعريف المستخدم. ماذا لو قمت بنسخ الكائن المرتجع ، وتغيير جميع الخصائص الموجودة فيه وإرساله مرة أخرى إلى الإدخال؟ قد يتضح أنه يمكنك تغيير أي خاصية للكائن (كلمة المرور ، الدور) ، متجاوزة سير العمل القياسي.
من بين المشروعات المختلفة التي اختبرناها للأمان ، سأقدم أمثلة حقيقية. تم إصلاح جميع مناطق المشكلات هذه ، ويتم إخفاء أي معلومات إضافية في لقطات الشاشة.
النظام 1على هذا النظام ، يمكن تغيير اسم المستخدم فقط في ملف التعريف. لكن باستبدال بريد إلكتروني آخر ، تمكنت من تغيير تسجيل دخول المستخدم. علاوة على ذلك ، دعوات للمستخدمين الآخرين تركت هذا الصابون الآن.
النظام 2في هذا المثال ، تمكن مستخدم بسيط من تغيير الدور إلى المسؤول عن طريق إضافة حقل الأدوار ، وبواسطة url / admin ، افتح لوحة مسؤول النظام بكل المعاملات والمستخدمين والتقارير وما إلى ذلك.
نظام 3في هذا النظام ، كان من الممكن تجديد اشتراك مجاني لفترة غير محددة. من الواضح أن النهج القياسي يتطلب أن يكون هناك دفع.
يبدو أن طريقة الإدخال ستتخذ فقط اللون المحدد وفقًا للعلامة التجارية لمساحة العمل ، وتعيد كائن مساحة العمل بالكامل ، بما في ذلك تفريغ كامل لعنصر StripeCustomer ، مما يعكس الدفع. كان من الممكن إدراج ليس فقط حقلًا ، ولكن أيضًا كائنًا فرعيًا ضخمًا StripeCustomer ، وكنتيجة لذلك ، دفع مرة واحدة ، أو من مستخدم آخر لالتقاط هذا الكائن ، وتكراره في جميع مساحات العمل الخاصة به.
النظام 4وأخيرا. واجه هذا النظام نفس المشكلة: كان من الممكن تغيير كلمة المرور ومفتاح المرور لتجاوز مسار العمل الذي تم اختراعه. أدى عدم وجود حماية ضد CSRF وتخزين ملفات تعريف ارتباط المصادقة لفترة طويلة إلى زيادة خطر التعرض لهذه الجنة. يمكن لمستخدم ضار وضع نص برمجي على مورد شائع مع طلب تغيير كلمة مرور المستخدم الحالي لهذا النظام ، ويفقد جميع المستخدمين الذين سيفتحون هذا المورد الوصول إلى النظام.
إخفاء رمز الخادم في البيانات الوصفية لهذا الحقل ، مما مكن من عدم إعادة هذا الحقل إلى العميل في الاستجابة ، ولكن في بيانات الإدخال تمت معالجة هذا الحقل دون مشاكل.
الرسالة:- لا تثق أبدًا في البيانات الواردة من المستخدمين ، بل يمكنهم القيام بأي شيء معهم
- كن حذرا مع الأنظمة التي لا تحتوي على طبقة ViewModel منفصلة ، والعمل مباشرة مع النماذج الأساسية
- استكشف بمزيد من التفصيل الحماية التي يوفرها إطارك.
يتم توفير المعلومات المذكورة أعلاه فقط للأغراض التعليمية والتعليمية ، وكيفية القيام بأنظمتها ليست ضرورية.
دينيس كولوشكو ، اختبار الاختراق ، CISSP