Skip to content

API10_Unsafe_Consumption_of_APIs.md

Latest commit

 

History

History
193 lines (108 loc) · 17.1 KB

API10_Unsafe_Consumption_of_APIs.md

File metadata and controls

193 lines (108 loc) · 17.1 KB
Raw

🔗 API10:2023 — Unsafe Consumption of APIs

📌 1. التعريف (Definition)

ثغرة Unsafe Consumption of APIs (الاستهلاك غير الآمن للـ APIs) تحدث عندما يثق الـ API الخاص بك بشكل "أعمى" في البيانات القادمة من APIs أخرى (سواء كانت تابعة لجهات خارجية مثل Google وStripe، أو حتى APIs داخلية في شركتك).

في العادة، يبذل المطورون جهداً كبيراً لتنقية البيانات التي يدخلها "المستخدم"، لكنهم يفترضون أن البيانات القادمة من "API آخر موثوق" هي دائماً آمنة وسليمة. هذا الافتراض هو الثغرة بعينها.

🧠 Real-World Analogy (المثل الواقعي)

تخيل أنك تمتلك مطاعماً فاخراً، وأنت حريص جداً على نظافة مطبخك وتفحص كل زبون يدخل من الباب.

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

  2. المشكلة (ثغرة Unsafe Consumption): أنت تتعامل مع مورّد لحوم شهير وموثوق جداً منذ سنوات. وبسبب هذه الثقة، قررت أن اللحوم التي تأتي من هذا المورّد تدخل "مباشرة" إلى القِدْر وتُطبخ وتُقدم للزبائن دون فحص.

  3. السيناريو الخبيث: في أحد الأيام، تعرض مخزن هذا المورّد للتلوث، أو قام شخص خبيث باستبدال الشحنة بلحوم فاسدة.

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

👉 في عالم الـ API:

  • المطعم: هو الـ API الخاص بك.
  • المورّد الموثوق: هو خدمة خارجية (مثل API الطقس، أو بوابة دفع مثل Stripe، أو حتى خدمة داخلية في شركتك).
  • اللحم الفاسد: هو استجابة (Response) خبيثة تحتوي على كود حقن (Injection) أو روابط ضارة.
  • التسمم: هو اختراق نظامك لأنك عالجت بيانات الـ API الخارجي وكأنها بيانات آمنة 100%.

🧩 2. أنواع الثغرة (Unsafe Consumption Types)

1. الوثوق في روابط التوجيه (Trusting Redirects/URIs) 🔗

هذا النوع يحدث عندما يطلب الـ API الخاص بك بيانات من خدمة خارجية، وتتضمن الاستجابة "رابطاً" (URL) يُفترض أن يزوره نظامك.

  • المشكلة: إذا تم اختراق الخدمة الخارجية، قد ترسل لك رابطاً خبيثاً.
  • الخطر: قد يقوم نظامك بزيارة الرابط تلقائياً (SSRF) أو تحميل ملف ضار من ذلك الرابط ومعالجته داخل سيرفراتك الخاصة، مما يفتح باباً للمخترق داخل شبكتك الداخلية.

2. غياب تنقية البيانات (Missing Input Validation) 🧼

المطورون يفحصون البيانات القادمة من المتصفح، لكنهم ينسون فحص البيانات القادمة من الـ API الصديق.

  • المشكلة: استلام بيانات نصية (String) من API خارجي ووضعها مباشرة في استعلام قاعدة بيانات (SQL Query) أو عرضها في صفحة ويب (HTML).
  • الخطر: إذا أرسل الـ API الخارجي نصاً مثل ' OR 1=1 -- أو سكربت خبيث <script>alert(1)</script>، فسيتم تنفيذه في نظامك وكأنه هجوم مباشر، ولكن مصدره هذه المرة "صديقك الموثوق".

3. الوثوق في إعدادات الأمان (Trusting Security Configurations) 🛡️

في بعض الأحيان، يعتمد الـ API الخاص بك على "قرار" أمني اتخذه API آخر.

  • مثال: الـ API الخاص بك يسأل خدمة الهوية (Identity Provider): "هل هذا المستخدم مسؤول (Admin)؟". إذا ردت الخدمة بـ "نعم"، يتم منحه الصلاحيات فوراً.
  • الخطر: إذا تم التلاعب بالاستجابة أو كان هناك ضعف في خدمة الهوية، سيحصل المخترق على صلاحيات كاملة في نظامك لأنك لم تقم بـ "التحقق المزدوج" (Double Check).

4. استهلاك خدمات غير مشفرة (Insecure Transport) 📡

  • المشكلة: التواصل مع API خارجي عبر HTTP بدلاً من HTTPS.
  • الخطر: هجوم Man-in-the-Middle (MitM). يمكن للمخترق الموجود في المنتصف تعديل البيانات القادمة من الـ API الخارجي وحقن أكواد خبيثة فيها قبل أن تصل إلى نظامك، وأنت ستتعامل معها بصفتها بيانات سليمة قادمة من المصدر.

🔥 3. Impact (خطورة الثغرة)

1. تنفيذ أوامر عن بُعد (Remote Code Execution - RCE) 💻

هذا هو الخطر الأكبر. إذا كان الـ API الخاص بك يستقبل بيانات من طرف ثالث ويقوم بمعالجتها باستخدام دالات غير آمنة (مثل eval() في JavaScript أو دالات معالجة النصوص في PHP).

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

2. طلبات التزوير من جهة السيرفر (SSRF) 🛰️

كما ذكرنا في الأمثلة السابقة، إذا كنت تثق في الروابط (URLs) القادمة من الـ API الخارجي.

  • الأثر: يمكن للمخترق إجبار السيرفر الخاص بك على مهاجمة نفسه أو مهاجمة سيرفرات داخلية في شبكتك الخاصة لا تظهر للإنترنت، مثل لوحات تحكم السحابة (Metadata) أو قواعد البيانات الداخلية.

3. حقن البيانات وتدمير قواعد البيانات (Injection Attacks) 💉

المخترق قد يرسل بيانات خبيثة عبر الـ API الخارجي مصممة خصيصاً لقاعدة بياناتك أنت.

  • الأثر: تنفيذ هجمات SQL Injection أو NoSQL Injection. بما أن الـ API الخاص بك "يثق" بالخدمة الخارجية، فقد يتخطى فلاتر الحماية، مما يؤدي لتسريب بيانات المستخدمين أو حذف الجداول بالكامل.

4. تعطيل الخدمة (Denial of Service - DoS) 🛑

إذا كانت الخدمة الخارجية ترسل كميات هائلة من البيانات أو بيانات مصممة لاستهلاك موارد النظام (مثل قنابل الـ XML أو ملفات ضخمة جداً).

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

5. خرق الخصوصية والالتزام (Privacy & Compliance Breaches) 📋

  • الأثر: إذا قام الـ API الخارجي بتغيير نوع البيانات التي يرسلها (مثلاً بدأ يرسل بيانات حساسة لا يفترض بك تخزينها) وقمت أنت بحفظها "تلقائياً"، فقد تجد نفسك فجأة خارقاً لقوانين حماية البيانات مثل GDPR، مما يعرضك لمساءلة قانونية ضخمة.

🛠️ 4. Discovery (كيف تكتشفها؟)

1. رسم خريطة الـ API (Dependencies Mapping) 🗺️

أول خطوة هي معرفة من هم "أصدقاء" الـ API الخاص بك.

  • التجربة: ابحث في الكود عن أي دالات تقوم بعمل طلبات خارجية (مثل fetch, axios, curl, requests.get).
  • ماذا تبحث عنه: هل يتصل التطبيق بخدمة طقس؟ بوابة دفع؟ خدمة توليد ملفات PDF؟ خدمة توثيق (OAuth)؟ كل نقطة اتصال هي هدف محتمل.

2. فحص بروتوكولات الاتصال (Transport Layer Check) 📡

  • التجربة: راقب حركة المرور الصادرة من السيرفر (Outbound Traffic).
  • ماذا تبحث عنه: هل هناك أي اتصالات تتم عبر http:// بدلاً من https://؟ أي اتصال غير مشفر يعني أنك عرضة لهجوم Man-in-the-Middle الذي قد يحقن بيانات خبيثة في استجابة الطرف الثالث.

3. التلاعب بالاستجابات (Response Man-in-the-Middle) 🎭

هذه هي الطريقة الأكثر فعالية إذا كنت تملك بيئة اختبار.

  • التجربة: استخدم أداة مثل Burp Suite أو محاكي للـ API (Mock Server) لاعتراض الاستجابة القادمة من الطرف الثالث "قبل" أن تصل إلى الـ API الخاص بك.
  • المحاولة: قم بتغيير البيانات القادمة من الطرف الثالث إلى قيم خبيثة:
    • بدل اسم المستخدم، ضع: <script>alert('XSS')</script>.
    • بدل رقم التعريف، ضع: ' OR 1=1 --.
    • بدل رابط الصورة، ضع رابطاً لسيرفر داخلي: http://localhost:8080/admin.
  • الاكتشاف: إذا قام الـ API الخاص بك بتنفيذ السكربت، أو حدث خطأ في قاعدة البيانات، أو حاول السيرفر الاتصال بالرابط الداخلي، فقد وجدت الثغرة!

4. فحص الروابط المعاد توجيهها (Redirect Follow-up) 🔄

  • التجربة: ابحث عن أي استجابة من طرف ثالث تحتوي على روابط (URLs) يتم معالجتها لاحقاً.
  • ماذا تبحث عنه: هل يقوم الـ API الخاص بك بتحميل ملفات من هذه الروابط تلقائياً؟ هل يقوم بزيارتها لجلب معلومات؟ إذا كان يتبع الروابط دون فحص "النطاق" (Domain) المسموح به، فهذا مؤشر قوي على وجود ثغرة SSRF.

5. تحليل تكامل الهوية (OAuth & Webhooks Check) 🔑

  • التجربة: إذا كان تطبيقك يستقبل Webhooks (تنبيهات تلقائية من خدمة خارجية مثل GitHub أو Stripe).
  • ماذا تبحث عنه: هل يتأكد الـ API الخاص بك من "توقيع" الطلب (Signature Verification)؟ إذا كان يقبل الـ Webhook دون التأكد من أنه قادم فعلاً من الخدمة الأصلية، يمكن للمخترق إرسال Webhook مزيف يحتوي على بيانات خبيثة.

🛡️ 5. Remediation (كيف تُصلح؟)

1. تطبيق فلترة صارمة (Strict Input Validation) 🧼

لا تكتفِ بفحص مدخلات المستخدم؛ بل قم بفحص كل "استجابة" (Response) تأتي من API خارجي.

  • الإجراء: تأكد من أن البيانات تطابق التنسيق المتوقع (Schema). إذا كنت تتوقع "رقم تعريف"، فتأكد أنه رقم وليس نصاً يحتوي على أوامر SQL.
  • القاعدة: استخدم مكتبات مثل Joi أو Zod لفرض بنية محددة للبيانات القادمة من الخارج.

2. فرض التشفير والتحقق من الشهادات (Enforce TLS/SSL) 🔐

  • الإجراء: لا تسمح للـ API الخاص بك بالاتصال بأي خدمة خارجية عبر HTTP. استخدم HTTPS دائماً.
  • الإجراء المتقدم: قم بعمل Certificate Pinning إذا كان ذلك ممكناً، لضمان أنك تتحدث فعلياً مع السيرفر الأصلي وليس مهاجماً في المنتصف.

3. القائمة البيضاء للروابط (URL Whitelisting) ⚪

إذا كان الـ API الخارجي يرسل لك روابط (URLs) لتحميل ملفات أو جلب بيانات.

  • الإجراء: لا تتبع الرابط مباشرة. قارن "النطاق" (Domain) الموجود في الرابط بقائمة بيضاء مخزنة لديك مسبقاً.
  • مثال: إذا كنت تتوقع صوراً من Amazon S3، فارفض أي رابط لا ينتهي بـ s3.amazonaws.com.

4. التحقق من التواقيع الرقمية (Verify Signatures) ✍️

عند استقبال تنبيهات (Webhooks) من خدمات مثل Stripe أو PayPal.

  • الإجراء: استخدم "المفتاح السري للـ Webhook" للتحقق من التوقيع الرقمي الموجود في رأس الطلب (Header). هذا يضمن أن الطلب جاء فعلاً من الشركة المعنية ولم يتم تزويره من قبل مخترق.

5. عزل المعالجة (Isolation & Sandboxing) 🏗️

إذا كان الـ API الخاص بك يستهلك بيانات معقدة (مثل ملفات XML أو ملفات تنفيذية) من طرف ثالث.

  • الإجراء: قم بمعالجة هذه البيانات في بيئة معزولة (Sandbox) أو حاوية (Container) محدودة الصلاحيات، بحيث لو كانت البيانات خبيثة، لن تستطيع الوصول إلى ملفات النظام الرئيسية أو قاعدة البيانات.

6. استخدام الـ Timeouts والـ Rate Limiting الصادر ⏳

  • الإجراء: لا تترك اتصالك بالطرف الثالث مفتوحاً للأبد. ضع حداً زمنياً (Timeout) قصيراً. أيضاً، حدد عدد الطلبات التي يمكن للطرف الثالث إرسالها إليك (إذا كنت تستقبل بيانات منه)، لمنع هجمات تعطيل الخدمة (DoS).

🧠 6. Attacker Mindset (اسأل نفسك كمخترق)

1. "من هو الصديق الضعيف لهذا الـ API؟" 🤝

"هذا الموقع محمي جداً، لكنني أرى أنه يجلب حالة الطقس من خدمة WeatherFreeAPI.com. ماذا لو كان هذا الموقع الخارجي ضعيفاً؟ سأحاول اختراق خدمة الطقس أو عمل (Man-in-the-Middle) على اتصالها. إذا نجحت في تغيير استجابة الطقس إلى كود خبيث، فهل سيقوم الـ API الرئيسي بتنفيذه؟"

2. "هل يثق السيرفر بالروابط التي يرسلها الآخرون؟" 🔗

"التطبيق يستلم رابط 'صورة الملف الشخصي' من Google. ماذا لو قمت بالتلاعب بطلب الـ OAuth وجعلت الرابط يشير إلى http://169.254.169.254/latest/meta-data/؟ إذا كان الـ API يتبع الروابط بشكل أعمى لتحميل الصورة، فقد يسرب لي مفاتيح الوصول الخاصة بالسحابة (AWS/Azure) عبر هجوم SSRF."

3. "ماذا لو أرسلت 'قنبلة بيانات' عبر الطرف الثالث؟" 💣

"الـ API يعالج ملفات XML أو JSON ضخمة قادمة من خدمة شحن. سأحاول إرسال ملف يحتوي على (Entity Expansion) أو حجم هائل. هل سيحاول الـ API معالجتها حتى ينهار السيرفر (DoS)؟ المطور غالباً لا يضع قيوداً (Rate Limits) على الخدمات 'الموثوقة' كما يفعل مع المستخدمين العاديين."

4. "هل يقرأ السيرفر التوقيع أم يكتفي بالرسالة؟" ✍️

"عندما يرسل Stripe تنبيهاً (Webhook) بنجاح عملية الدفع، هل يتأكد الـ API من التوقيع الرقمي فعلاً؟ سأحاول إرسال طلب Webhook مزيف من جهازي يخبر السيرفر بأنني دفعت 1000 دولار. إذا صدقني السيرفر دون التحقق من التوقيع، فقد حصلت على الخدمة مجاناً!"

5. "هل يتحدثون بخصوصية أم في العلن؟" 🗣️

"سأفحص الروابط الخارجية التي يتصل بها السيرفر. هل هناك اتصال يتم عبر http؟ إذا وجدته، سأقوم بحقن كود (SQL Injection) في وسط البيانات المنتقلة. المطور يظن أن البيانات آمنة لأنها قادمة من 'سيرفر معروف'، لكنه لا يعلم أنني أتحكم في الطريق بينهما."