أمن الواجهات البرمجية: الباب الخلفي الذي يفحصه قليلون

المصادقة والتفويض

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

والفحص يكون في مستوى الاستعلام: اجلب هذا السجل بشرط أنه يخص هذا المستخدم — لا اجلبه ثم تحقق.

التسريب في الاستجابات

• إعادة كائن قاعدة البيانات كاملا يسرب حقولا داخلية لم يطلبها أحد.
• رسائل الخطأ التفصيلية تكشف بنية النظام وتساعد المهاجم.
• اختلاف الاستجابة بين حساب موجود وغير موجود يتيح تعداد الحسابات.
• الحقول الحساسة في الاستجابة حتى لو لم تعرضها الواجهة — فالمستهلك يراها.

حدود الاستهلاك

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

التحقق من المدخلات

1. تحقق من المخطط: الحقول المسموحة وأنواعها وحدودها، وارفض ما زاد.
2. حدد أقصى حجم للطلب لمنع استنزاف الموارد.
3. تحقق من المعرفات: هل هي بالصيغة المتوقعة وهل تخص هذا المستهلك.
4. لا تثق بحقول التحكم القادمة من العميل كالدور أو السعر أو الحالة.

الواجهات المنسية

أخطر ما في الواجهات هو ما لا تعرف بوجوده: نسخة قديمة ما زالت تعمل، ونقطة نهاية بنيت لاختبار ونسيت، وواجهة داخلية صارت متاحة بعد تغيير في الشبكة. واجرد واجهاتك دوريا من الخارج كما يراها المهاجم لا من وثائقك.

أسئلة شائعة

هل مفتاح الواجهة يكفي؟

المفتاح يحدد الهوية ولا يكفي وحده: يجب أن يقترن بصلاحيات محددة، ومدة صلاحية، وإمكان الإبطال، وتقييد بالنطاق أو المصدر حيث أمكن. والمفتاح الدائم مفتوح الصلاحية مخاطرة كبيرة.

كيف نحمي واجهات التطبيقات المحمولة؟

بافتراض أن كل ما في التطبيق مكشوف: لا أسرار في الكود، والتحقق كله في الخادم. وأدوات مثل تثبيت الشهادات ترفع الصعوبة ولا تلغي المبدأ.

هل نوثق واجهاتنا علنا؟

التوثيق لا يضعف الأمان إن كان التصميم سليما، وإخفاؤه ليس حماية. والأمان بالغموض ينهار عند أول من يفحص الحركة من تطبيقك نفسه.