درس 29: أمن واجهات البرمجة API — الثغرات والحماية

ماذا ستتعلم في هذا الدرس

• فهم بنية واجهات REST API وكيف تعمل في الأنظمة المصرفية
• التعرف على أخطر 10 ثغرات في واجهات API وفق OWASP API Security Top 10 (2023)
• تنفيذ اختبارات عملية لاكتشاف ثغرات API باستخدام أدوات مثل Burp Suite و Postman
• تطبيق ضوابط الحماية المطلوبة وفق متطلبات SAMA CSCC و NCA ECC

لماذا أصبحت واجهات API الهدف الأول للمهاجمين

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

وفق تقرير Gartner، أصبحت واجهات API أكبر سطح هجوم في تطبيقات الويب منذ 2023. السبب بسيط: واجهات API مصممة لتكون مفتوحة ومتاحة بطبيعتها — فهي نقطة التكامل بين الأنظمة. هذا الانفتاح، إذا لم يُدار بضوابط صارمة، يتحول إلى ثغرة كارثية. الفرق بين API آمنة وأخرى مخترقة قد يكون سطراً واحداً في كود التحقق من الصلاحيات.

OWASP API Security Top 10: الثغرات التي يجب أن تعرفها

أصدرت OWASP قائمة محدثة في 2023 تحدد أخطر عشر ثغرات تصيب واجهات API. لن نسرد القائمة كاملة بشكل نظري، بل سنركز على الثغرات الأكثر شيوعاً في بيئة المؤسسات المالية مع أمثلة عملية لكل منها.

1. Broken Object Level Authorization (BOLA)

الأخطر والأكثر شيوعاً. تحدث عندما يستطيع المستخدم الوصول لبيانات مستخدم آخر بمجرد تغيير معرّف الكائن (Object ID) في الطلب. تخيّل واجهة API لعرض كشف حساب بنكي:

GET /api/v1/accounts/7001234/statements
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

# المهاجم يغيّر رقم الحساب فقط:
GET /api/v1/accounts/7001235/statements
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...  ← نفس التوكن!

إذا أعاد الخادم كشف حساب العميل الآخر، فالنظام مصاب بثغرة BOLA. الحل: يجب أن يتحقق الخادم من أن التوكن ينتمي فعلاً لصاحب الحساب المطلوب، وليس فقط أن التوكن صالح.

2. Broken Authentication

ضعف في آليات المصادقة على واجهة API. يشمل: توكنات JWT بدون تحقق من التوقيع، مفاتيح API مكشوفة في الكود المصدري، عدم تطبيق Rate Limiting على محاولات تسجيل الدخول، وتوكنات لا تنتهي صلاحيتها.

3. Broken Object Property Level Authorization

عندما تكشف واجهة API حقولاً أكثر مما يحتاجه العميل. مثلاً، واجهة تعرض بيانات العميل تُرجع رقم الهوية الوطنية ورقم الحساب البنكي الكامل (IBAN) في الاستجابة، بينما التطبيق يحتاج فقط الاسم والأحرف الأربعة الأخيرة من الحساب.

4. Unrestricted Resource Consumption

غياب حدود على حجم الطلبات أو عددها. مهاجم يرسل طلباً واحداً يطلب فيه مليون سجل، أو يرسل آلاف الطلبات في الثانية لاستنزاف موارد الخادم.

مثال عملي: في أحد اختبارات الاختراق لتطبيق مصرفي سعودي، اكتشف الفريق أن واجهة API الخاصة بالبحث عن العملاء لا تطبق أي حد على عدد النتائج. طلب واحد بمعامل limit=999999 أعاد قاعدة بيانات العملاء بالكامل — أسماء وأرقام هويات وأرقام هواتف. الإصلاح كان بسيطاً: فرض حد أقصى 50 سجلاً لكل طلب مع تطبيق Pagination إجبارية وتسجيل كل طلب يتجاوز الحدود الطبيعية في نظام SIEM.

اختبار أمن API عملياً — الأدوات والخطوات

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

الخطوة 1: جمع وتوثيق واجهات API

ابدأ بجمع كل واجهات API المتاحة. استخدم ملفات Swagger/OpenAPI إن وُجدت، وإلا استخدم أدوات الاستكشاف:

# استخدام كracker للبحث عن نقاط API المخفية
ffuf -u https://api.target.com/FUZZ -w /usr/share/wordlists/api-endpoints.txt \
     -mc 200,201,401,403 -H "Authorization: Bearer TOKEN"

# تحليل حركة التطبيق عبر Burp Suite Proxy
# 1. اضبط Burp كـ Proxy للتطبيق
# 2. استخدم التطبيق بشكل طبيعي
# 3. راجع تبويب HTTP History لرؤية كل استدعاءات API
# 4. صدّر القائمة إلى Postman Collection

الخطوة 2: اختبار BOLA

لكل واجهة تستقبل معرّف كائن (ID)، جرّب تغييره:

# سجّل دخول كـ User A واحصل على التوكن
TOKEN_A="eyJhbGciOiJSUzI1NiIs..."

# حاول الوصول لبيانات User B باستخدام توكن User A
curl -s -H "Authorization: Bearer $TOKEN_A" \
     https://api.target.com/v1/users/USER_B_ID/profile

# جرّب أيضاً المعرفات التسلسلية
for id in $(seq 1000 1010); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer $TOKEN_A" \
    "https://api.target.com/v1/transactions/$id")
  echo "ID: $id → HTTP $STATUS"
done

الخطوة 3: اختبار Rate Limiting

# اختبار حد الطلبات على نقطة تسجيل الدخول
for i in $(seq 1 100); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://api.target.com/v1/auth/login \
    -H "Content-Type: application/json" \
    -d '{"username":"test","password":"wrong'$i'"}')
  echo "Attempt $i → HTTP $STATUS"
done
# إذا لم تحصل على 429 (Too Many Requests) بعد 10 محاولات، هناك مشكلة

الخطوة 4: فحص استجابات API بحثاً عن تسرب البيانات

# استخدم jq لتحليل الاستجابات والبحث عن حقول حساسة
curl -s -H "Authorization: Bearer $TOKEN" \
  https://api.target.com/v1/users/me | \
  jq 'keys' 
# ابحث عن: password, secret, token, ssn, national_id, 
# full_iban, credit_card, internal_id

ضوابط حماية واجهات API — خطة التطبيق

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

المصادقة والتفويض: استخدم OAuth 2.0 مع PKCE لتطبيقات الجوال. طبّق JWT موقعة بخوارزمية RS256 (وليس HS256) مع صلاحية قصيرة لا تتجاوز 15 دقيقة. نفّذ التحقق من الصلاحيات على مستوى كل كائن في طبقة الـ Middleware وليس في كل Controller بشكل منفصل.

التحكم في المدخلات والمخرجات: طبّق Schema Validation لكل طلب وارد باستخدام مكتبات مثل Joi أو Pydantic. حدد بدقة الحقول المسموح إرجاعها في كل استجابة — لا تعتمد على إرجاع الكائن كاملاً من قاعدة البيانات. استخدم نمط DTO (Data Transfer Object) لفصل بنية قاعدة البيانات عن بنية الاستجابة.

التحكم في الاستهلاك: طبّق Rate Limiting على ثلاثة مستويات: لكل مستخدم (مثلاً 100 طلب/دقيقة)، لكل عنوان IP (500 طلب/دقيقة)، ولكل واجهة حساسة (مثل تسجيل الدخول: 5 محاولات/دقيقة). استخدم API Gateway مثل Kong أو AWS API Gateway لإدارة هذه الحدود مركزياً.

التسجيل والمراقبة: سجّل كل استدعاء API مع: هوية المستدعي، الواجهة المطلوبة، المعاملات، رمز الاستجابة، وزمن المعالجة. أرسل هذه السجلات إلى نظام SIEM وأنشئ قواعد تنبيه لأنماط مشبوهة مثل: عدد كبير من أخطاء 401/403 من مستخدم واحد، أو وصول تسلسلي لمعرفات متتالية.

الربط بالواقع السعودي

يُلزم إطار SAMA CSCC في مجال "أمن التطبيقات" المؤسسات المالية بتطبيق ضوابط محددة على واجهات API تشمل المصادقة القوية وتسجيل كل الأنشطة. كذلك تشترط ضوابط NCA ECC اختبار أمن واجهات API كجزء من اختبارات الاختراق الدورية. نظام PDPL يفرض حماية البيانات الشخصية أثناء النقل عبر واجهات API، ما يعني أن كشف بيانات عميل عبر ثغرة BOLA قد يُعتبر انتهاكاً يستوجب الإبلاغ خلال 72 ساعة. مبادرة Open Banking من البنك المركزي السعودي تضع معايير أمنية صارمة لواجهات API المشتركة بين البنوك وشركات التقنية المالية، تشمل استخدام mTLS وتوكنات محدودة النطاق.

أخطاء شائعة يجب تجنبها

• الاعتماد على API Key وحده للمصادقة: مفتاح API هو معرّف وليس آلية مصادقة كاملة. استخدمه مع OAuth 2.0 لتحقيق مصادقة وتفويض حقيقيين. كثير من المؤسسات تكتفي بمفتاح API ثابت لا يُجدد ولا يُربط بصلاحيات محددة.
• تطبيق الأمن في طبقة API Gateway فقط: الـ Gateway يحمي المدخل، لكن الثغرات المنطقية مثل BOLA تحتاج حماية على مستوى كود التطبيق. لا تعتمد على طبقة واحدة — طبّق Defense in Depth على مستوى API أيضاً.
• عدم إدارة إصدارات API بشكل آمن: إبقاء إصدارات قديمة من API (مثل /v1/) نشطة بعد إطلاق /v2/ يعني أن الثغرات المُصلحة في الإصدار الجديد لا تزال قابلة للاستغلال عبر الإصدار القديم. ضع خطة إيقاف واضحة لكل إصدار مع إعلام المطورين مسبقاً.

ملخص الدرس

• واجهات API هي أكبر سطح هجوم في التطبيقات الحديثة، وثغرة BOLA تتصدر القائمة — التحقق من الصلاحيات على مستوى الكائن ليس اختيارياً
• اختبار أمن API يتطلب منهجية منظمة: جمع النقاط، اختبار التفويض، فحص المدخلات والمخرجات، واختبار حدود الاستهلاك
• الحماية الفعالة تجمع بين OAuth 2.0 مع JWT قصيرة الصلاحية، Schema Validation، Rate Limiting على عدة مستويات، وتسجيل شامل متصل بنظام SIEM

الدرس القادم

في الدرس التالي سنتناول: مركز العمليات الأمنية SOC — البناء والتشغيل — ستتعلم كيف تصمم وتبني SOC فعّال لمؤسستك، من اختيار الأدوات وبناء الفريق إلى تصميم قواعد الكشف وإجراءات الاستجابة وفق متطلبات SAMA و NCA.

هل تريد تطبيق ما تعلمته على مؤسستك؟ تواصل مع فريق فنترالينك للحصول على تقييم مجاني لمدى النضج السيبراني وفق SAMA CSCC.