أمن تطبيقات الويب 5: API Security وكيف تختبر واجهات برمجة التطبيقات
في الأجزاء السابقة من سلسلة أمن تطبيقات الويب تعرّفنا على أساسيات حماية تطبيقات الويب، وكيف تحدث بعض الهجمات والثغرات الشائعة.
لكن أغلب التطبيقات الحديثة لم تعد تعتمد فقط على صفحات الويب التقليدية؛ بل أصبحت تعتمد بشكل كبير على واجهات برمجة التطبيقات API للتواصل بين الموقع والتطبيقات وقواعد البيانات والخدمات المختلفة.
وهنا تظهر مشكلة مهمة:
«قد يكون الموقع محميًا بشكل جيد، لكن الـ API الموجود خلفه يحتوي على ثغرة خطيرة.»
لذلك في هذا الجزء سنتعرف على API Security وكيف يمكن فحص واجهات API بطريقة آمنة وقانونية.
---
🔹 ما هي API؟
API اختصار لـ Application Programming Interface، وهي الواجهة التي تسمح للبرامج المختلفة بالتواصل مع بعضها.
على سبيل المثال، عندما تفتح تطبيقًا على هاتفك وتطلب بيانات حسابك، قد يرسل التطبيق طلبًا إلى API مثل:
GET /api/user/profile
ويرجع الخادم استجابة تحتوي على البيانات:
{
"id": 1024,
"username": "abdullah",
"role": "user"
}
المستخدم لا يرى هذه العملية بشكل مباشر، لكنها تحدث في الخلفية باستمرار.
---
🔹 لماذا تعتبر API هدفًا مهمًا؟
لأن الـ API يتعامل مباشرة مع البيانات والوظائف الموجودة داخل التطبيق.
فإذا كانت هناك مشكلة في التحقق من الصلاحيات، فقد يستطيع مستخدم عادي الوصول إلى بيانات لا تخصه.
مثلاً، لديك:
GET /api/users/100
ثم تغيّر الرقم إلى:
GET /api/users/101
إذا أعاد الخادم بيانات المستخدم الآخر بدون التأكد من أن لديك صلاحية للوصول إليها، فقد تكون هناك مشكلة في Broken Access Control.
وهذا النوع من المشاكل يُعرف غالبًا باسم:
BOLA — Broken Object Level Authorization
وهو من أهم الأشياء التي يجب الانتباه إليها عند اختبار API.
---
🔹 أهم الأشياء التي تفحصها في API
عند اختبار API بشكل قانوني، لا تركز فقط على معرفة المنافذ أو الخدمات، بل افحص طريقة تعامل الـ API مع الطلبات والصلاحيات.
1️⃣ Authentication — المصادقة
هل الـ API يتأكد أصلًا من هو المستخدم؟
جرب بشكل آمن، داخل بيئة اختبار تملكها، إرسال طلب بدون بيانات المصادقة:
GET /api/profile
إذا حصلت على بيانات خاصة رغم عدم وجود جلسة أو Token، فهذه علامة تستحق التحقيق.
---
2️⃣ Authorization — الصلاحيات
وجود تسجيل دخول لا يعني أن المستخدم يستطيع الوصول إلى كل شيء.
مثلاً:
GET /api/admin/users
إذا كان الحساب مستخدمًا عاديًا، فيجب أن يرفض الخادم الطلب.
الاختبار هنا هو التأكد من أن الصلاحيات يتم التحقق منها على الخادم، وليس الاعتماد على واجهة التطبيق فقط.
---
3️⃣ تغيير الـ ID
من الاختبارات المهمة:
GET /api/account/100
ثم:
GET /api/account/101
في بيئة اختبار مصرح بها.
إذا كان بإمكان المستخدم الوصول إلى موارد مستخدم آخر بمجرد تغيير رقم المعرف، فهذه مشكلة خطيرة في التحكم بالوصول.
---
🔹 لا تنسَ الـ HTTP Methods
واجهات API تستخدم عادةً عدة طرق:
GET
POST
PUT
PATCH
DELETE
كل واحدة لها وظيفة مختلفة.
مثلاً:
GET /api/profile
لجلب البيانات.
بينما:
DELETE /api/profile
قد تستخدم لحذف الحساب.
لذلك يجب التأكد من أن الخادم لا يسمح للمستخدم بتنفيذ عمليات لا يمتلك صلاحيتها.
---
🔹 اختبار الـ API باستخدام Burp Suite
من أشهر الأدوات المستخدمة في اختبار تطبيقات الويب وواجهات API:
Burp Suite
الفكرة بسيطة:
1. افتح التطبيق في بيئة الاختبار.
2. اجعل الطلبات تمر عبر Burp.
3. راقب طلبات API.
4. افحص الـ Headers والـ Parameters والـ Body.
5. أعد إرسال الطلب باستخدام Repeater.
6. غيّر قيمة واحدة في كل مرة.
7. راقب كيف يتغير رد الخادم.
مثلاً قد ترى:
POST /api/login
Content-Type: application/json
{
"username": "test",
"password": "password123"
}
وهنا تستطيع دراسة طريقة تعامل الخادم مع البيانات، بدون محاولة اختراق أنظمة لا تملك تصريحًا لاختبارها.
---
🔹 ماذا عن الـ API Keys والـ Tokens؟
أحيانًا تستخدم التطبيقات:
Authorization: Bearer <token>
هذا الـ Token يمثل هوية أو جلسة المستخدم.
لذلك يجب عدم نشره أو مشاركته، كما يجب على المطورين التأكد من:
- انتهاء صلاحية الـ Token.
- عدم قبول Tokens غير صحيحة.
- عدم وضع الأسرار داخل JavaScript أو المستودعات العامة.
- استخدام HTTPS لحماية البيانات أثناء النقل.
---
🔹 خطأ شائع جدًا
بعض المطورين يعتقدون أن إخفاء زر معين من واجهة التطبيق يعني أن الوظيفة أصبحت محمية.
مثلاً:
المستخدم العادي لا يرى زر:
Delete User
لكن إذا كان Endpoint موجودًا:
DELETE /api/users/102
وكان الخادم لا يتحقق من الصلاحيات، فإن إخفاء الزر لا يحل المشكلة.
الأمان الحقيقي يجب أن يكون على الخادم.
---
🔹 كيف تبدأ اختبار API بشكل صحيح؟
إذا كنت تتعلم الأمن السيبراني، لا تبدأ باختبار مواقع عشوائية على الإنترنت.
استخدم بيئات تدريب قانونية مثل:
- تطبيق محلي على جهازك.
- مختبرات CTF.
- تطبيقات تدريبية متعمدة الضعف.
- نظام لديك تصريح صريح لاختباره.
وابدأ بهذا التسلسل:
اكتشاف الـ API
↓
فهم الـ Endpoints
↓
فهم Authentication
↓
اختبار Authorization
↓
فحص Parameters
↓
تحليل Responses
↓
توثيق النتائج
---
🔥 الخلاصة
أمن الـ API أصبح جزءًا أساسيًا من أمن تطبيقات الويب الحديثة.
وأهم شيء تتذكره:
Authentication ≠ Authorization
المصادقة تجيب عن سؤال:
«من أنت؟»
أما الصلاحيات فتجيب:
«ماذا يُسمح لك أن تفعل؟»
وقد يكون المستخدم مسجل الدخول بشكل صحيح، ومع ذلك يستطيع الوصول إلى بيانات أو وظائف لا يجب أن يصل إليها.
وهنا تبدأ واحدة من أهم مهارات اختبار الاختراق: فهم منطق التطبيق، وليس مجرد تشغيل الأدوات.
في الجزء القادم سنتعمق أكثر في Broken Access Control وIDOR/BOLA، وكيف يمكن اكتشاف هذه المشاكل وتحليلها داخل بيئة اختبار آمنة.
تعليقات