أدوات اختبار أمان API: أربع فئات ومهام مختلفة

أدوات اختبار أمان API: الفئات الأربع

أما الفئة الرابعة فهي التحقق السلوكي: هل يرفض API ما يجب أن يرفضه. الاستدعاءات غير المصادَق عليها، والوصول عبر الحسابات، وحدود الأدوار، والرموز منتهية الصلاحية. لا يستطيع أي ماسح التحقق من هذه الأمور لأنها تعتمد على ما يعنيه منتجك بالصلاحية.

الثغرة التي تعاني منها معظم الفرق

عادةً ما يكون لدى الفرق ماسح ضمن مسار التسليم واختبار اختراق مرة واحدة في السنة. وكلاهما مفيد. لكن أيًّا منهما لا يتحقق من أن نقطة النهاية التي أُطلقت الثلاثاء الماضي تفرض التخويل على مستوى الكائن، وهو أكثر الخلل استغلالًا في واجهات API الحقيقية.

وسبب بقائه دون فحص تنظيمي لا تقني. فهو يبدو كأنه شأن أمني، فينتظر المسار الأمني الذي يجري كل ثلاثة أشهر. وهو في الحقيقة فحص سلوكي مكانه مجموعة الاختبارات التي تُشغَّل مع كل تغيير.

كيف تعرف أي ثغرة تخصّك

• هل تستطيع تحديد آخر مرة تحقق فيها أحدهم من أن المستخدم A لا يستطيع قراءة بيانات المستخدم B؟ إذا كان الجواب هو اختبار الاختراق السنوي، فتلك نافذة مدتها اثنا عشر شهرًا على أرجح خلل لديك.

• هل تحصل نقطة النهاية الجديدة على فحص للصلاحيات تلقائيًا؟ إذا كان الأمر متوقفًا على تذكّر كاتبها، فسيضيع.

• هل تُفرز نتائج الماسح أم تتراكم؟ ماسح ينتج نتائج لا يقرأها أحد أسوأ من غياب الماسح، لأنه يبدو كأنه تغطية.

سدّ الثغرة السلوكية

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

الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل ألا تثبّت شيئًا محليًا. أما بقية واجهة CLI فتجدها في مستودع CLI.

تفاصيل الآلية موجودة في توثيق اختبار API.

الفرز، أو لماذا لم يعد الماسح مهمًّا

تفشل الماسحات بطريقة محددة وشائعة: تواصل عملها ويتوقف الجميع عن قراءتها. ويستحق الأمر أن يُفهم لأنه ليس مشكلة أدوات.

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

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

ماذا تُشغّل وأين

الفحوص السلوكية مع كل طلب سحب. والماسحات وفق جدول زمني. والوكلاء وأدوات الـ Fuzzing بين يدي شخص يقوم بعمل مركّز. واختبار الاختراق عندما يتغيّر نموذج التهديد، لا عندما يحلّ موعده في التقويم.

إذا كان مسار التسليم تابعًا لفريق آخر، فإن GitHub App هو أقل الطرق مقاومة: فهو webhook لا يغيّر شيئًا في مستودعك، وينطلق عندما تعلن عملية البناء لديك أن الإصدار الجديد صار حيًّا. وإذا كنت تريد أن يكون الفحص ظاهرًا داخل المستودع بدلًا من ذلك، فإن خطوة في GitHub Actions كفيلة بذلك.

ما يقدّمه TestSprite في الفئة الرابعة

التحقق السلوكي: هل يرفض API ما يجب أن يرفضه. تتضمن الخطط المولَّدة فئتي التخويل والحدود، فتُفحص كل نقطة نهاية بحثًا عن الوصول دون مصادقة، والقراءات عبر الحسابات، وحدود الأدوار، وبيانات الاعتماد منتهية الصلاحية، مع كل تغيير.

يعمل على الخدمة قيد التشغيل عبر واجهتها، مستعينًا بجولة اكتشاف إلى جانب مواصفاتك لمعرفة ما هو موجود. يحافظ Auto-Authentication على بقاء الجلسات حيّة طوال التشغيل، وتنقل Dynamic Variables القيم بين الاستدعاءات، وتستنتج Dependency Chains ترتيب التنفيذ مما تحتاجه كل حالة وما تنتجه، ويزيل Auto-Cleanup بالضبط ما أنشأه التشغيل.

والمكسب أن التخويل على مستوى الكائن يتوقف عن الاعتماد على تذكّر أحدهم. فيبقى ماسحك يتولى فئات التبعيات والحقن، ويبقى اختبار الاختراق يتولى إساءة الاستخدام الإبداعية، وتكفّ الفئة الواقعة بينهما عن كونها مسؤولية لا أحد.