مساء الخير أيها القراء الأعزاء. اسمي فيكتور بوروف ، وأنا مطور في ISPsystem. في آخر مشاركة تحدثت فيها عن
أداة إنشاء الاختبارات التلقائية ،
سأشارك اليوم تجربتي في أتمتة اختبار الأمان.
في البداية ، تم البحث عن نقاط الضعف في المنتجات من قبل موظف منفصل. استغرق الاختبار اليدوي الكثير من الوقت ولم يضمن العثور على جميع الثغرات الأمنية. بعد التأكد من القوانين الأساسية للاختبار ، توصلنا إلى استنتاج أنه يمكن أتمتة. ثم قررنا كتابة أداة من شأنها تسهيل عمر المختبر ، وتوفير وقته والسماح لك بفحص المنتجات بعد كل تغيير. نظرًا لأن المختبر كان يدعى Lida ، قمنا بتسمية التطبيق الجديد على شرفها. بشكل عام ، أصبح في شركتنا تقليدًا لاستدعاء أدوات الاختبار بأسماء المختبرين.
بعد تحليل أدوات البحث عن الثغرات الأمنية ، توصلت إلى استنتاج مفاده أنهم جميعًا بحاجة إلى تحديد الوظائف التي يجب الاتصال بها والمعلمات المستخدمة. قررنا مرة أخرى الاستفادة من الواجهة الموحدة وصياغة متطلبات ليدا.
متطلبات بدء التشغيل:
- إنشاء قوائم الوظائف تلقائيًا.
- خيارات الإكمال التلقائي.
- عمل طلبات API.
- تحليل إخراج البيانات بعد أداء الوظائف.
- ابحث عن نقاط الضعف في البيانات.
- تشكيل التقارير.
- إعدادات مرنة.
لتحقيق كل هذا لم يكن سهلا.
التنفيذ
النماذج والقوائم الالتفافية
للعثور على الثغرات الأمنية في وظيفة ما ، يجب تنفيذها بتمرير المعلمات الضرورية. تم بناء واجهتنا على أساس القوائم والنماذج ، بحيث يمكنك أتمتة جمع البيانات عن طريق معالجة مستندات xml التي تصف هيكل عناصر الواجهة.
قررت بدء الزحف من القائمة الرئيسية ، والذهاب بشكل متكرر إلى جميع القوائم المتداخلة. تفتح "ليدا" قائمة المستوى الأول. كقاعدة عامة ، يحتوي على العديد من الأزرار التي تستدعي بعض الوظائف.
إذا فتح الزر النموذج ، فستكون نتيجة الاستدعاء عبارة عن مستند xml يحتوي على عقد تحتوي على معلومات حول الحقول: الاسم ، المدقق ، نطاق القيم الصالحة. بناءً على هذه المعلومات ، يتم إنشاء قيم الحقول. على سبيل المثال ، سيتم إنشاء رقم لـ int. إذا لم يكن هناك مدقق ، يتم إنشاء سلسلة عشوائية. بعد ملء جميع حقول النموذج ، يتم إرسال الطلب.
إذا كانت الوظيفة قائمة ، فسيتم فتحها وسيتم استدعاء الوظائف المرتبطة بالأزرار لعناصرها.
عند التحقق من القوائم ، تنشأ مشكلة - يجب أن تحتوي جميع القوائم على مجموعة من السجلات التي تضمن أن جميع الأزرار في القائمة قابلة للنقر.
البحث عن حقن SQL
ربما يكون إدخال SQL من أكثر المشاكل شيوعًا للتطبيقات ، بما في ذلك تطبيقاتنا. تقوم العديد من استدعاءات الوظائف بإنشاء استعلامات DBMS مختلفة. يحدث خطأ عندما يتم استبدال المعلمات التي تأتي من الخارج في نص الطلب "كما هي". يمكن أن تكون عواقب مثل هذه الأخطاء محزنة: من الاستلام غير المصرح به للبيانات إلى حذف الجداول.
لبدء البحث عن حقن SQL ، قمت بتنظيم إخراج كافة استعلامات SQL إلى ملف. بعد تنفيذ الوظيفة ، يبحث التطبيق عن قيم المعلمات التي تم تمريرها في استعلامات SQL الناتجة.
يمكنك استخدام سجل خادم SQL نفسه. ولكن في حالتنا ، هناك طريقة واحدة فقط لتنفيذ الاستعلامات وإضافة تسجيل الدخول لم يكن صعبًا. بفضل هذا ، نعرف بالضبط ما هو التحدي الذي نتج عن هذا الطلب أو ذاك.عند العثور على قيمة المعلمة التي تم تمريرها ، تقوم الأداة المساعدة بتمرير قيمة تحتوي على اقتباس واحد لهذه المعلمة. إذا تم العثور على الاقتباس في نفس التسلسل ، فلن يتم تجاوز المعلمة - وجدنا مكانًا لإدخال SQL.
تحليل مكالمات النظام
تحدث مشكلة مشابهة عندما نجري أي مكالمات نظام. قررت أن أبحث عنها بصرامة واخترت معلمات الإطلاق المثالية لها. مثال على بدء ISPmanager:
strace -f -s 1024 -e trace=file,process bin/core ispmgr
بالإضافة إلى عمليات حقن SQL ، تؤدي Lida وظيفة وتحلل الإخراج المتسلل لتحديد ما إذا تم تضمين قيم المعلمات التي تم تمريرها
للفتح أو إلغاء الربط أو rmdir أو chmod أو chflags أو mknod أو mkfifo أو fcntl أو symlink أو link أو execve أو mkdir .
إذا تم العثور على المعلمة ، تمرر الأداة المساعدة قيمة تحتوي عليها ، على سبيل المثال ، مسار مع الانتقال إلى الدليل أعلاه. إذا كان الأمر كما هو ، فسيتم العثور على ثغرة محتملة.
تبين أن تحليل وظيفة execve مفيد للغاية. يسمح لك بتحديد الوسيطات الوظيفية لتشغيل الملفات القابلة للتنفيذ التي لا يتم تجاوزها. هذا الخطأ مكلف للغاية ، لأنه من خلاله يمكنك الحصول على وصول الجذر إلى الخادم ببساطة عن طريق تغيير كلمة المرور.
عندما يجد المستخدمون ثغرة في منتجاتنا ، تدفع الشركة مكافأة نقدية ، يعتمد مقدارها على فئة الثغرة. يمكن أن يكون هذا النهج أرخص من البحث عن الأخطاء بنفسك (قد لا يجد المختبر الخطأ ويحصل على راتب).
اختبار آخر مثير للاهتمام: التحقق من ترتيب استدعاء وظائف القانون الأساسي وغيرها. في كثير من الأحيان ، يتم التحقق من الوصول أولاً من خلال القانون الأساسي ، ثم بعض الإجراءات غير الآمنة ، مما يترك فرصة الاستبدال. لكننا لم نقم بأتمتة هذا.التحقق من الوصول إلى الأجسام الغريبة
نتحقق من الوصول إلى كائنات غريبة من تحت المستخدم لكيانات مستخدم ومسؤول آخر. في هذا الوضع ، نتحقق من القدرة على قراءة وتعديل وعرض قوائم عناصر المستخدم الأجنبي.
تتخطى Lida جميع الوظائف المتاحة بالنيابة عن المالك أو المسؤول وتتذكر عناصرها. ثم يقوم باستدعاء نفس الوظائف مع عناصر من مستخدم آخر. في الوضع المثالي ، يجب أن تكون الإجابة خطأ مثل Access أو Missed. إذا لم يتم تلقي مثل هذا الخطأ ، فمن المحتمل جدًا أنه يمكنك قراءة بيانات مستخدم شخص آخر.
في بعض الحالات ، لا يعني عدم وجود خطأ أنه يمكنك الوصول مباشرة إلى كائنات المستخدم الآخر. في بداية هذه الوظائف ، نضيف فحص أذونات العنصر. لا يتحقق ذلك من الأمان فحسب ، بل يتحقق أيضًا من صحة استجابات الخادم.
التحقق من واجهة برمجة التطبيقات
التحقق من واجهة برمجة التطبيقات لدينا هو مكافأة إضافية لوظائف التحقق من الثغرات الأمنية. من خلال تحليل التقارير حول عمل Lida ، تعلمنا إعادة الأنواع الصحيحة من الأخطاء ، مما جعل واجهة برمجة التطبيقات الخاصة بنا أكثر ملاءمة ومنطقية. ونتيجة لذلك ، كما هو الحال مع مسجل الأشرطة ، لم نتلقَ فقط فحصًا أمنيًا ، ولكن أيضًا فحصنا مرة أخرى API من أجل "الاتساق".
الصعوبات
الإيجابيات الكاذبة
يمكن أن تعمل الأداة المساعدة مع جميع منتجاتنا ، وبالتالي ، فإنها تتحقق من العديد من الوظائف المختلفة. في الأساس ، ظهرت الإيجابيات الكاذبة في وضع التحقق من الوصول إلى الأشياء الغريبة. هذا يرجع إلى ميزات الأزرار والوظائف.
كانت الإيجابيات الكاذبة أكبر مشكلة ليدا. يبدو أنه تم تصحيحه بالكامل ، ولكن عند التحقق من لوحات مختلفة ، ظهرت إيجابيات كاذبة جديدة. ونتيجة لذلك ، كانت هناك عدة مراحل لتصحيحها.
إنشاء الكيان
يتم تنفيذ معظم الإجراءات في اللوحة على أي كيان (اسم النطاق ، قاعدة البيانات ، إلخ). لتحقيق أقصى قدر من الأتمتة ، كان على Lida إنشاء هذه الكيانات تلقائيًا. لكن من الناحية العملية تبين أن هذا صعب التنفيذ. في بعض الأحيان يتم إجراء التحقق في التعليمات البرمجية ، لذلك ليس من الممكن دائمًا استبدال قيمة المعلمة تلقائيًا. السبب الثاني هو الكيانات التابعة. على سبيل المثال ، لإنشاء صندوق بريد ، تحتاج إلى إنشاء مجال بريد.
لذلك ، قررنا عدم القتال من أجل الأتمتة الكاملة. قبل البدء ، ينشئ المختبر الكيانات يدويًا ويأخذ لقطة من الجهاز ، حيث سيتم تغيير الكيانات بعد التحقق. هذا يسمح لك بعدم تخطي التحقق من مجموعة من الوظائف في حالة إنشاء كيان غير ناجح.
استدعاء وظائف مدمرة
تحتوي كل قائمة تقريبًا على وظائف لحذف أو إيقاف تشغيل كيان ما. إذا قمت بتنفيذها بالتسلسل ، فسيتم حذف الكيان قبل أداء وظائف أخرى. أحدد مثل هذه الوظائف وأؤدي بعد الآخرين. بالإضافة إلى إضافة مفتاح يحظر تنفيذ مثل هذه الوظائف.
تقوم بعض الوظائف بإعادة تشغيل الخادم. يجب تعقبهم وإضافتهم إلى قائمة المتجاهلين.
نظرًا لطبيعة منطق التشغيل ، تقوم بعض الوظائف بإعادة تشغيل اللوحة. أثناء اختبار الأمان ، يؤدي ذلك إلى بدء تشغيل اللوحة بدون تتبع استعلامات SQL أو الركود - يصبح التحقق الإضافي بلا معنى. يجب عليك تتبع هذا وإعادة تشغيل اللوحة في وضع التتبع.
التحقق من المعلمات التابعة
في النماذج ، توجد حقول لإدخال النص وخانات الاختيار والقوائم المنسدلة ، على القيم التي يعتمد عليها توفر قيم الحقول الأخرى. قد تحتوي كل قيمة للحقل التابع على قسم منفصل من التعليمات البرمجية ، لذلك ، قد تظل الأجزاء التي لم يتم التحقق منها.
لحل هذه المشكلة ، أضفت خوارزميات لتحليل الحقول التابعة والتحقق من جميع مجموعات عناصر التحكم التابعة.
التحقق من الميزات غير متوفرة في الواجهة
وظائف الخدمة غير متاحة للانتقال ، ولكنها قد تحتوي على نقاط ضعف. لتحديدها والتحقق منها ، لدينا وظيفة خاصة تقوم بإرجاع قائمة بجميع الوظائف المسجلة. قارنا هذه القائمة مع قائمة الوظائف المختبرة. لا توجد بيانات وصفية لوظائف الخدمة ، لذلك من المستحيل التحقق من المعلمات التي تتم معالجتها بداخلها.
الخلاصة
قمنا بتضمين Lida في كل ليلة في Jenkins. بناءً على نتائج عمله ، يتم إنشاء تقرير التحقق ، ويتم عرض معلومات حول الوظيفة المشبوهة فيه مع جميع المعلمات.
لم يتم فحص المهمة التي أغلقها المطور الآن بواسطة المختبر فقط ، ولكن أيضًا بواسطة Lida. يقوم المختبر بمعالجة التقرير المستلم: نسخ معلمات الوظيفة المشبوهة إلى المستعرض وتحليل السلوك ولوحة السجل. إذا تم تأكيد الثغرة الأمنية ، فسيتم تسجيل الخطأ للمطور.