أهم 10 مخاطر لأمن واجهات API حسب OWASP: ما تفرضه البوابة، وما يجب إصلاحه في الشيفرة

اقرؤوا القائمة على أنها أسئلة تُطرح على كل واجهة، لا عشرة منتجات تشترونها. أربعة من العشرة تخص الصلاحيات والتحقق من الهوية، ومنها تبدأ أغلب الحوادث الفعلية. وثلاثة تخص الحدود وإساءة الاستخدام. والثلاثة الأخيرة تخص البيئة كلها: الإعدادات، والجرد، وواجهات الأطراف الأخرى التي تستدعيها خدماتكم. وللاطلاع على جدول واحد يلخص من يتعامل مع كل خطر وقائمة تحقق للإصدار، راجعوا صفحتنا عن أمن واجهات API؛ أما هذه الصفحة فتتعمق في كل خطر.

خلل التحقق من الهوية

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

خلل الصلاحية على مستوى خصائص الكائن

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

خلل الصلاحية على مستوى الوظيفة

مستخدم عادي يستدعي نقطة إدارية، أو يرسل DELETE حيث كان المقصود GET فقط، فتنفّذه الخدمة. البوابة: تحصر المسارات والطرق الإدارية في مجموعات مستهلكين مسمّاة، وتُبقي واجهات الإدارة خارج المسارات العامة. إصلاح الشيفرة: تحققوا من دور المستدعي داخل كل وظيفة أيضًا، لأن قاعدة المسار لا تحمي إلا المسارات التي تعرفها.

الوصول غير المقيّد إلى مسارات العمل الحساسة

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

تزوير الطلبات من جهة الخادم (SSRF)

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

الخطأ في الإعدادات الأمنية

رسائل أخطاء تكشف التفاصيل، وإعدادات CORS متساهلة، واتصالات داخلية بلا TLS، وإعدادات افتراضية لم تتغير، ونقاط تصحيح ما زالت مفتوحة. البوابة: مكان واحد لإعدادات TLS وCORS وترويسات الاستجابة، تُدار إعداداتٍ خاضعة للمراجعة ومحفوظة في نظام إدارة الإصدارات. إصلاح الشيفرة: تقوية الخدمات والمنصات خلف البوابة، ومراجعة إعدادات البوابة نفسها كما تُراجع أي شيفرة.

سوء إدارة جرد الواجهات

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

الاستهلاك غير الآمن لواجهات الأطراف الأخرى

تثق خدمتكم بما تعيده واجهة شريك أو طرف آخر أكثر مما تثق بالمستخدم، فتمرره مباشرة إلى قاعدة بيانات أو شاشة. البوابة: دورها محدود؛ فالخطر في الاستدعاءات الخارجة منكم. إصلاح الشيفرة: تحققوا من استجابات الأطراف الأخرى بالصرامة نفسها التي تتحققون بها من مدخلات المستخدم، واستخدموا TLS في كل استدعاء خارج، وقيّدوا إعادة التوجيه. والفكرة نفسها تنطبق على النماذج اللغوية التي تستدعيها خدماتكم؛ راجعوا ما تمنعه بوابة الذكاء الاصطناعي وما لا تمنعه.

وأين لا يناسب؟ لا يعرف Kong من يملك الطلب 1002، ولا أي الخصائص يحق لموظف الدعم رؤيتها، ولا ما تفعله خدمتكم بعنوان أرسله المستخدم. هذه إصلاحات في شيفرة كل خدمة، والبوابة لا تغني عن منطق الصلاحيات ولا عن الاختبار ولا عن الاختبار الأمني المستقل. وإن كانت بيئتكم بضع واجهات خلف تطبيق واحد له فحوص صلاحيات خاصة به، فقد لا تكون البوابة أول ما تشترونه، وسنقول لكم ذلك.