كيف يحمي APISIX من أهم 10 تهديدات أمان API وفقًا لـ OWASP
October 6, 2023
مع زيادة استخدام واعتماد واجهات برمجة التطبيقات (APIs) في المشهد الرقمي المتصل اليوم، تزايدت أيضًا التهديدات الأمنية التي تستهدفها على مر السنين. في عام 2023، حدد مشروع أمان تطبيقات الويب المفتوحة (OWASP) أهم 10 تهديدات لأمان واجهات برمجة التطبيقات. في هذه المقالة، سنستكشف كل تهديد ونعرف كيف يمكن لـ APISIX الحماية منها مع أمثلة.
OWASP هي مجتمع معترف به عالميًا ينشر أبحاثًا متعلقة بالأمن السيبراني بشكل دوري.
إليك قائمة بالمخاطر الأمنية التي ذكرها OWASP:
- تفويض الكائن المكسور (Broken Object Level Authorization)
- المصادقة المكسورة (Broken Authentication)
- تفويض خاصية الكائن المكسور (Broken Object Property Level Authorization)
- استهلاك الموارد غير المقيد (Unrestricted Resource Consumption)
- تفويض الوظيفة المكسور (Broken Function Level Authorization)
- الوصول غير المقيد إلى تدفقات الأعمال الحساسة (Unrestricted Access to Sensitive Business Flows)
- تزوير الطلبات من جانب الخادم (Server-Side Request Forgery)
- التكوين الأمني الخاطئ (Security Misconfiguration)
- إدارة المخزون غير السليمة (Improper Inventory Management)
- الاستهلاك غير الآمن لواجهات برمجة التطبيقات (Unsafe Consumption of APIs)
1. تفويض الكائن المكسور (Broken Object Level Authorization)
التهديد: غالبًا ما تعرض واجهات برمجة التطبيقات نقاط نهاية تتعامل مع معرفات الكائنات، مما قد يؤدي إلى مشاكل في التحكم في الوصول على مستوى الكائن. يمكن للمهاجمين استغلال هذه الثغرات للوصول غير المصرح به إلى البيانات.
مثال: تقدم مؤسسة رعاية صحية بوابة إلكترونية للمرضى. بسبب عيب في تصميم البوابة، بمجرد أن يتم مصادقة المريض، يمكنه تعديل عنوان URL أو معلمات الطلب للوصول إلى السجلات الطبية المرتبطة بمعرف مريض مختلف. على سبيل المثال، يقوم المريض ستيف بتسجيل الدخول إلى البوابة لعرض سجلاته الطبية. يمكن الوصول إلى سجلاته عبر الرابط https://healthportal.com/patient/123. بدافع الفضول، يقوم ستيف بتغيير الرابط إلى https://healthportal.com/patient/124 ويكتشف أنه يمكنه الآن عرض السجلات الطبية لمريض آخر. هذا يكشف عن انتهاك كبير للخصوصية وينتهك لوائح مثل قانون نقل التأمين الصحي والمساءلة (HIPAA).
التوصية: قم بتنفيذ آلية تفويض مناسبة تعتمد على سياسات المستخدم والتسلسل الهرمي. تدعم بوابة APISIX تدفقات التفويض القائمة على OAuth2 أو JWT باستخدام الإضافات. يمكنك استخدام سياسة OAuth2 للتحقق من الرمز المميز في كل طلب.
استخدم التحكم في الوصول الدقيق من خلال نظام التحكم في الوصول القائم على الأدوار (RBAC) في APISIX عن طريق التكامل مع Open Policy Agent (OPA). من خلال إعداد أدوار وأذونات محددة في APISIX وربط هذه الأدوار بمستخدمين أو رموز مميزة محددة، يمكنك التأكد من أن الطلبات إلى نقاط النهاية الحساسة مصرح بها بشكل صحيح.
2. المصادقة المكسورة (Broken Authentication)
التهديد: يمكن لآليات المصادقة المطبقة بشكل غير صحيح أن تسمح للمهاجمين باختراق الرموز المميزة للمصادقة أو ببساطة يمكن للمهاجم تنفيذ هجمات القوة الغاشمة على نقاط نهاية تسجيل الدخول بسبب عدم وجود تحديد لمعدل الطلبات.
مثال: قام نظام مصرفي بتنفيذ آلية مصادقة مخصصة. ومع ذلك، بسبب نقص المراجعة الأمنية والاختبار المناسبين، كانت هناك ثغرة في تدفق المصادقة. على وجه التحديد، بعد أن يدخل المستخدم اسم المستخدم وكلمة المرور، يقوم النظام بإنشاء رمز جلسة يمكن التنبؤ به، مثل مزيج من اسم المستخدم والطابع الزمني. يمكن للمهاجم، الذي يعرف هذا العيب، أن يتنبأ بسهولة برمز جلسة مستخدم آخر.
التوصية: أولاً، افهم جميع تدفقات المصادقة الممكنة لواجهة برمجة التطبيقات، ولا تعيد اختراع العجلة في المصادقة! تدعم APISIX تدفق التفويض القياسي OpenID Connect (OIDC). بدلاً من الرموز المميزة للجلسة التي يمكن التنبؤ بها، يمكن لـ APISIX التكامل مع مزودي الهوية الخارجيين مثل Keycloak أو أنظمة إدارة الجلسات باستخدام الإضافات لضمان أن الرموز المميزة للجلسة عشوائية ومشفرة ولها عمر محدود.
لمنع هجمات القوة الغاشمة على حسابات المستخدمين، يمكن استخدام إضافة تحديد معدل الطلبات في APISIX. هذا يضمن أنه إذا كانت هناك محاولات تسجيل دخول فاشلة متعددة في فترة زمنية قصيرة، يتم حظر عنوان IP أو المستخدم مؤقتًا. لضمان خصوصية وسلامة البيانات، تدعم APISIX التشفير SSL/TLS. هذا يضمن أن بيانات اعتماد المستخدم والبيانات الحساسة الأخرى مشفرة أثناء النقل.
3. تفويض خاصية الكائن المكسور (Broken Object Property Level Authorization)
التهديد: ينشأ هذا التهديد من عدم وجود أو عدم تطبيق التحقق من التفويض على مستوى خاصية الكائن، مما يؤدي إلى الكشف غير المصرح به عن المعلومات أو التلاعب بها.
مثال: تسمح واجهة برمجة التطبيقات لمنصة تسوق عبر الإنترنت للمستخدمين المسجلين بتحديث تفاصيل ملفاتهم الشخصية مثل الاسم والبريد الإلكتروني وعنوان الشحن وتفاصيل الدفع. بالإضافة إلى ذلك، يحتوي كل ملف تعريف مستخدم على خاصية تسمى userType، والتي يمكن أن تكون إما regular أو admin. بسبب مشكلة في تصميم واجهة برمجة التطبيقات، يمكن للمستخدمين أيضًا تعديل خاصية userType في طلبات تحديث ملفاتهم الشخصية. لنفترض أن أليس، وهي مستخدمة عادية، اكتشفت هذا العيب عندما قامت بفحص طلبات واجهة برمجة التطبيقات باستخدام أدوات المطور في متصفحها. لاحظت أنه عند تحديث ملفها الشخصي، يتم إرسال حمولة JSON إلى الخادم. قامت أليس بتعديل قيمة userType إلى admin وأرسلت الطلب. لدهشتها، تم تحديث ملفها الشخصي، وأصبح لديها الآن صلاحيات إدارية على المنصة، مما يسمح لها بالوصول إلى البيانات الحساسة وتعديل قوائم المنتجات وحتى عرض سجلات طلبات المستخدمين الآخرين.
التوصية: تأكد من أن خصائص الكائن المعروضة يمكن الوصول إليها من قبل المستخدم واحتفظ بهياكل البيانات المرتجعة بحد أدنى، بناءً على متطلبات العمل. لتحقيق ذلك، يمكنك استخدام إضافة التحقق من الطلبات في APISIX التي يمكنها التحقق من الطلبات الواردة مقابل مخطط مسبق. أو استخدم نظام RBAC في APISIX لإعداد أدوار للمستخدمين العاديين والمسؤولين. لإزالة البيانات غير الضرورية التي يتم عرضها للعميل، توفر APISIX إضافة إعادة كتابة الاستجابة التي يمكنها تعديل استجابة واجهة برمجة التطبيقات على الفور.
4. استهلاك الموارد غير المقيد (Unrestricted Resource Consumption)
التهديد: يمكن للمهاجمين استغلال واجهات برمجة التطبيقات لاستهلاك الموارد بشكل مفرط، مما يؤدي إلى هجمات حجب الخدمة أو زيادة التكاليف التشغيلية.
مثال: تسمح خدمة تخزين ملفات قائمة على السحابة للمستخدمين بتحميل الملفات وتخزينها ومشاركتها مع الآخرين والوصول إليها من أي مكان. لا توجد أي قيود على عدد الملفات التي يمكن للمستخدم تحميلها في وقت واحد أو حجم كل ملف. نتيجة لذلك، يمكن لمستخدم خبيث أو برنامج نصي تحميل عدد هائل من الملفات الكبيرة جدًا بسرعة، مما يستهلك كمية كبيرة من موارد الخادم. يمكن أن يؤدي هذا إلى أوقات استجابة أبطأ للمستخدمين الآخرين، وتعطل الخادم المحتمل، وزيادة تكاليف البنية التحتية لمزود الخدمة.
التوصية:
- حدد وفرض الحد الأقصى لأحجام البيانات لجميع المعلمات والحمولات الواردة. استخدم إضافة التحكم في العميل لتعيين الحد الأقصى لحجم جسم الطلب حتى لا يتمكن المستخدمون من تحميل ملفات كبيرة بشكل مفرط. أو استخدم إضافة التحقق من الطلبات للتحقق من سلاسل الاستعلام، خاصة تلك التي تتحكم في عدد السجلات المرتجعة. لحظر برنامج نصي أو وكيل مستخدم من إرسال بيانات غير مرغوب فيها، يمكنك الاستفادة من إضافة تقييد وكيل المستخدم.
- نفذ تحديد معدل الطلبات بناءً على احتياجات العمل. توفر APISIX إضافات limit-req، limit-conn، و limit-count التي يمكنها تقييد المعدل الذي يمكن لمستخدم أو عنوان IP معين تقديم الطلبات به. هذا يضمن أن المستخدمين لا يمكنهم إغراق النظام بعدد كبير من الطلبات السريعة.
5. تفويض الوظيفة المكسور (Broken Function Level Authorization)
التهديد: تكون سياسات التحكم في الوصول أحيانًا معقدة للغاية، مع مستويات ومجموعات وأدوار مختلفة، وتمييز غير واضح بين الوظائف الإدارية والقياسية، مما يؤدي غالبًا إلى ثغرات في الأذونات. يمكن للمهاجمين الاستفادة من هذه الثغرات للوصول إلى موارد مستخدمين آخرين أو الوظائف الإدارية.
مثال: تقدم منصة تعليم عبر الإنترنت دورات مختلفة للطلاب. مع وجود مشاكل في تصميم المنصة، يمكن للطلاب الوصول إلى الوظائف المخصصة للمدرسين عن طريق التلاعب بعناوين URL أو نقاط نهاية واجهات برمجة التطبيقات. على سبيل المثال، قد يكتشف الطالب أنه عن طريق تغيير الرابط من /student/dashboard إلى /instructor/dashboard، يمكنه الوصول إلى لوحة تحكم المدرس، مما يسمح له بتعديل محتوى الدورة، وتقييم الواجبات، أو حتى إضافة/إزالة الدورات.
التوصية:
- ارفض جميع الوصول بشكل افتراضي واطلب منحًا صريحة لأدوار محددة. باستخدام APISIX، يمكنك إنشاء مستهلك أو مجموعة من المستهلكين لمنح تحكم مختلف في الوصول للمستخدمين. ثم يمكن تكوين إضافة مصادقة JWT لتضمين معلومات الدور في رمز JWT. عندما يقوم المستخدم بتسجيل الدخول، سيتلقى رمز JWT يحتوي على دوره (
studentأوinstructor). يمكن لـ APISIX بعد ذلك التحقق من دور المستخدم من رمز JWT قبل منح الوصول إلى وظائف محددة. - تأكد من أن وحدات التحكم الإدارية ترث من وحدة تحكم تنفذ فحوصات التفويض بناءً على أدوار المستخدم. إذا كنت تستخدم API7 Enterprise، فإنه يسمح للمسؤولين بتقييد وصول واجهات برمجة التطبيقات لمستخدمين/مجموعات معينة ويمكنك إعداد الوصول على أساس كل طلب وكل مستخدم.
6. الوصول غير المقيد إلى تدفقات الأعمال الحساسة (Unrestricted Access to Sensitive Business Flows)
التهديد: يتم الكشف عن تدفقات الأعمال الحساسة دون تقييم المخاطر لكيفية يمكن أن تضر هذه الوظيفة بالعمل إذا تم استخدامها بشكل تلقائي ومفرط.
مثال: باستخدام مجموعة من البروكسيات والنصوص البرمجية التلقائية (bots)، يحاكي المهاجم عدة مستخدمين حقيقيين يقومون بعمليات شراء. يقوم البرنامج النصي بإضافة المنتج إلى السلة بسرعة وإكمال عملية الدفع، مما يؤدي إلى نفاد المخزون قبل أن يتمكن العملاء الحقيقيون من إجراء عملية شراء. ثم يقوم المهاجم بإعادة بيع هذه المنتجات بسعر أعلى على منصات أخرى. تخسر منصة البائع الإيرادات المحتملة حيث لا يمكنها بيع المنتجات للعملاء الحقيقيين بالسعر المطلوب.
التوصية:
- نفذ بصمة الجهاز لرفض الخدمة للأجهزة غير المتوقعة. يمكن لـ APISIX التكامل مع منصات إدارة الهوية والوصول مثل Auth0، Authgear، وغيرها لتمكين آليات مصادقة مختلفة بما في ذلك ميزات تسجيل الدخول البيومترية على الأجهزة.
- استخدم آليات الكشف عن البشر مثل الكابتشا أو الحلول البيومترية المتقدمة. نفس ما سبق.
- قم بتحليل تدفق المستخدم لاكتشاف الأنماط غير البشرية. يمكنك استخدام API7 Enterprise لفرض عوامل إضافية للمصادقة عندما يكون الطلب مرتبطًا بأنماط غير بشرية، مثل السرعات العالية بين مواقع تسجيل الدخول المختلفة أو اكتشاف البرامج النصية.
- حظر عناوين IP للمصادر المعروفة بأنها خبيثة. لدى APISIX إضافة تقييد IP لحظر الوصول من عناوين IP فردية أو متعددة.
7. تزوير الطلبات من جانب الخادم (Server Side Request Forgery - SSRF)
التهديد: تسمح هجمات SSRF للمهاجم بإجراء طلبات إلى الموارد الداخلية للخادم، مما قد يؤدي إلى الوصول إلى الشبكات الداخلية أو أنظمة الملفات أو حتى تنفيذ الأوامر. يحدث هذا عندما تقبل نقطة نهاية واجهة برمجة التطبيقات عنوان URL أو جزء منه كمدخلات وتقوم بجلبها دون التحقق المناسب.
مثال: تقبل نقطة نهاية واجهة برمجة التطبيقات عنوان URL لجلب صورة من الإنترنت. يقوم مستخدم خبيث بإرسال عنوان URL مثل http://169.254.169.254/latest/meta-data/ (نقطة نهاية بيانات وصفية نموذجية في البيئات السحابية). تقوم الخدمة بجلب عنوان URL، معتقدة أنها صورة، ولكن بدلاً من ذلك تقوم باسترداد بيانات حساسة مثل أدوار IAM أو المفاتيح السرية أو تفاصيل التكوين الداخلية الأخرى. يستخدم المهاجم هذه المعلومات بعد ذلك لمزيد من الهجمات، مثل تصعيد الامتيازات أو انتهاكات البيانات.
التوصية:
- التحقق من المدخلات - تحقق دائمًا من المدخلات وقم بتنظيفها. تجنب قبول عناوين URL كاملة من مصادر غير موثوقة. باستخدام APISIX، يمكنك إعداد إضافة حظر URI لتطبيق قواعد الحظر على الموارد الداخلية.
- القائمة البيضاء - اسمح فقط بالاتصالات إلى النطاقات أو عناوين IP المعروفة والموثوقة. يمكنك استخدام إضافة تقييد IP في APISIX أو تمكين تقييد المرجع لقائمة بيضاء من النطاقات أو أنماط عناوين URL المقبولة. يتم رفض أي عنوان URL لا يتطابق مع القائمة البيضاء.
- تجزئة الشبكة - تأكد من أن خوادمك مجزأة وأن الموارد الداخلية الحساسة ليست قابلة للوصول مباشرة.
8. التكوين الأمني الخاطئ (Security Misconfiguration)
التهديد: يحدث هذا عندما لا يتم تكوين واجهة برمجة التطبيقات بشكل آمن، مما قد يؤدي إلى الكشف عن معلومات حساسة أو منح أذونات غير ضرورية. تشمل الأمثلة تسجيل رسائل الخطأ التي تكشف تفاصيل الخادم، أو تمكين طرق HTTP غير ضرورية، أو ترك بيانات الاعتماد الافتراضية دون تغيير.
مثال: يمكن أن يكون مثال بسيط هو تعرض واجهة برمجة التطبيقات عن غير قصد لدليل .git، مما يكشف عن الكود المصدري وسجل الالتزامات. مثال آخر، أثناء استخدام المنصة، يواجه مستخدم خبيث رسالة خطأ. بدلاً من رسالة خطأ عامة، يرى تتبعًا تفصيليًا يكشف عن بنية قاعدة البيانات وإصدارات البرامج ومسارات الملفات. باستخدام هذه المعلومات، يحدد الثغرات المحتملة في المنصة. بالإضافة إلى ذلك، عند البحث عن التكوينات الخاطئة الشائعة لمثل هذه المنصات، يحاول تسجيل الدخول باستخدام حساب اختبار ويتمكن من ذلك، مما يمنحه وصولًا إداريًا.
التوصية:
- المراجعات الدورية - راجع التكوينات وقم بتحديثها بانتظام. استخدم الأدوات الآلية للبحث عن التكوينات الخاطئة الشائعة. باستخدام إضافات التسجيل في APISIX، يتم تسجيل جميع أنشطة الوصول والأنشطة النظامية. يمكن الإبلاغ عن أي نشاط غير عادي، مثل محاولات تسجيل الدخول الفاشلة المتكررة أو الوصول إلى نقاط نهاية مقيدة، للمراجعة.
- مبدأ أقل امتياز - امنح فقط الأذونات الضرورية وتجنب استخدام الإعدادات المفرطة في الصلاحيات.
- رؤوس الأمان الافتراضية - تطبق APISIX إعدادات أمان افتراضية مع رؤوس أمان أساسية، مثل سياسة أمان المحتوى (CSP) وأمان نقل HTTP الصارم (HSTS)، والتي يتم تعيينها. هذا يقلل من خطر بعض الهجمات القائمة على الويب.
- إخفاء الأخطاء - تأكد من أن رسائل الخطأ عامة ولا تكشف عن معلومات حساسة. يمكن تكوين APISIX لإخفاء رسائل الخطأ التفصيلية باستخدام إضافة إعادة كتابة الاستجابة أو إضافة إخفاء البيانات المخصصة.
9. إدارة المخزون غير السليمة (Improper Inventory Management)
التهديد: مع نمو المنظمات، غالبًا ما تفقد تتبع جميع واجهات برمجة التطبيقات الخاصة بها، خاصة إذا لم يكن هناك إدارة مركزية. يمكن أن يؤدي هذا إلى نسيان واجهات برمجة التطبيقات القديمة أو غير المحمية التي يمكن استغلالها.
مثال: من الشائع ترك إصدارات متعددة من واجهات برمجة التطبيقات دون مراقبة. قد يستهدف المهاجمون إصدارات واجهات برمجة التطبيقات القديمة أو نقاط الوصول غير المحدثة. يمكنهم أيضًا الحصول على وصول غير مصرح به من خلال الثغرات في الاتصالات الخارجية.
التوصية: استخدم واجهة برمجة التطبيقات الإدارية في APISIX لمراجعة وتعطيل المسارات التي لم تعد هناك حاجة إليها بانتظام ولتتبع جميع إصدارات واجهات برمجة التطبيقات دون تعطيل التطبيقات العميلة. يوفر بوابة API7 لوحة تحكم مركزية حيث يمكن مراقبة وإدارة جميع واجهات برمجة التطبيقات. قد يكون إصدار قديم من واجهة برمجة التطبيقات لا يزال يعمل ولم يعد مستخدمًا. من خلال لوحة التحكم، يمكن تحديد هذه الواجهة وإيقافها دون أي تغيير في الكود في الخدمة الخلفية نفسها.
10. الاستهلاك غير الآمن لواجهات برمجة التطبيقات (Unsafe Consumption of APIs)
التهديد: عند دمج واجهات برمجة التطبيقات الخارجية أو حتى استهلاك واجهات برمجة التطبيقات الداخلية، إذا لم يتم ذلك بشكل آمن، يمكن أن يعرض التطبيق للثغرات الموجودة في واجهات برمجة التطبيقات العلوية.
مثال: لنفكر في تطبيق جوال يسمح للمستخدمين بمراقبة مقاييس صحتهم، مثل معدل ضربات القلب وأنماط النشاط البدني. لا يحتوي التطبيق على تحقق صارم وفحوصات أمنية عند استهلاك واجهات برمجة التطبيقات الخارجية هذه. يحدد المهاجم أن إحدى واجهات برمجة التطبيقات المتكاملة لتتبع التغذية معرضة للخطر ويمكن أن تعيد بيانات خبيثة. عندما يقوم التطبيق بجلب اقتراحات خطط الوجبات من هذه الواجهة، فإنه يسترد ويعالج حمولات خبيثة دون قصد، مما يؤدي إلى انتهاكات محتملة للبيانات أو تعطل التطبيق.
التوصية: قبل دمج واجهة برمجة التطبيقات الخارجية، تحقق مما إذا كانت من مصدر موثوق وقد خضعت لتقييمات أمنية.
- معالجة الأخطاء - تعامل مع الاستجابات أو السلوكيات غير المتوقعة من واجهات برمجة التطبيقات المستهلكة دون الكشف عن الثغرات.
- التحقق من البيانات - تحقق دائمًا من البيانات المستلمة من واجهات برمجة التطبيقات الخارجية وقم بتنظيفها. يمكن لـ APISIX التكامل مع جدران حماية تطبيقات الويب (WAF) لفحص البيانات الواردة من واجهات برمجة التطبيقات الخارجية وتصفيتها. يمكن أن تكتشف هذه الأنماط أو الحمولات الخبيثة المعروفة وتمنعها. يمكنك أيضًا تفعيل TLS/mTLS للخدمات العلوية لضمان أمان حركة المرور أثناء انتقالها عبر الشبكة الداخلية.
الخلاصة
تطبيق الإرشادات الأمنية المقترحة من OWASP API 2023 يوفر نقطة بداية أساسية لحماية واجهات برمجة التطبيقات. استخدام ميزات بوابة APISIX يبسط هذه العملية ويقلل بشكل كبير من تكلفة تنفيذ آليات الوقاية الموصى بها من OWASP.