انتقل إلى المحتوى

API8:2019 الحقن

عوامل التهديد/ الاستغلال نقاط الضعف التأثير
خصائص API : قابلية الاستغلال 3 الانتشار 2 : قابلية الاكتشاف 3 التأثر التقني 3 : تأثر الأعمال
يقوم المهاجمون بإرسال بيانات ضارة من خلال واجهة برمجة التطبيقات API وذلك من خلال حقنها بأي طريقة ممكنة ( مثل الإدخال المباشر و التعليمات البرمجية و طرق ربط الخدمات ...الخ) على أمل إرسالها إلى المفسر. تعتبر ثغرات الحقن منشرة وشائعة في استعلامات SQL و LDAP و NoSQL وأوامر أنظمة التشغيل و XML parsers و ORM. واكتشاف هذه الثغرات يعتبر سهل عن مراجعة الشفرة المصدرية. بإمكان المهاجمين استخدام أدوات الفحص. يمكن أن يؤدي الحقن إلى إفشاء المعلومات أو مسح وفقدان البيانات. كما يمكن أن يودي إلى حجب الخدمة DoS، أو اختراق كامل للنظام.

هل أنا معرض لهذه الثغرة؟

قد تكون واجهة برمجة التطبيقات API معرضة للاستغلال بمثل هذه الهجمات عندما :

  • لا يتم تصفية البيانات أو التحقق منها في حال كانت مقدمة من المستخدمين من طريق واجهة برمجة التطبيقات.
  • يتم استخدام البيانات بشكل مباشر مع SQL/NoSQL/LDAP queries, OS commands, XML parsers.
  • لا يتم التحقق من صحة البيانات الواردة من أنظمة خارجية مثل (الأنظمة المرتبطة بالخادم) أو تصفيتها أو التحقق منها من قبل واجهة برمجة التطبيقات API قبل عملية استخدامها

أمثلة على سيناريوهات الهجوم:

السيناريو الأول:

يقوم نظام جهاز التحكم الأبوي باستخدام المسار /api/CONFIG/restoreوالذي يتوقع أن يستقبل معرف التطبيق appId في أجزاء متعددة. فباستخدام برنامج فك وتحويل الشفرات البرمجية(decompile)، يجد المهاجم أن المعرف appId يتم تمريره مباشرة للنظام ومن غير عوامل التصفية المقترحة:

snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
         "/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);

يسمح الأمر التالي للمهاجم بإغلاق أي جهاز مصاب بتلك الثغرة البرمجية

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'

السيناريو الثاني :

لدينا تطبيق قائم على وظائف CRUD للتعامل مع الحجوزات، تمكن مهاجم من التعرف على إمكانية حقن NoSQL من خلال الاستعلام بالمعرف الفريد للحجوزات bookingId وطلب الحذف بأمر كالتالي: DELETE /api/bookings?bookingId=678

خادم واجهة برمجة التطبيقات (API Server) يستخدم الدالة التالية للتعامل مع طلبات الحذف:

router.delete('/bookings', async function (req, res, next) {
  try {
      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
      res.status(200);
  } catch (err) {
     res.status(400).json({error: 'Unexpected error occured while processing a request'});
  }
});

قام المهاجم باعتراض الطلبات الخاصة بالمعرف الفريد bookingIdوقام بتغير أمر الاستعلام كما هو معروض بالأسفل مما أدى إلى حذف حجز يعود لمستخدم آخر:

DELETE /api/bookings?bookingId[$ne]=678

كيف أمنع هذه الثغرة؟

لمنع عمليات الحقن انت بحاجة إلى فصل الأوامر والتعليمات البرمجية عن الاستعلامات بشكل صحيح و امن.

  • قم بإجراء التحقق من صحة البيانات المدخلة باستخدام مكتبة موحدة وامنه وموثوقة ويتم صيانتها بشكل دوري.
  • تحقق من صحة جميع البيانات المقدمة من المستخدم أو غيرها من البيانات الواردة من الأنظمة المتكاملة وتصفيتها.
  • يجب التعامل مع الأحرف والرموز الخاصة باستخدام الصيغة المحددة للمفسر المستهدف.
  • استخدم واجهة برمجة تطبيقات آمنة (safe API) ذات استعلامات واضحة.
  • ضع حداً لعدد السجلات التي يتم إرجاعها لمنع تسريب البيانات بشكل كبير في حالة نجاح عملية الحقن.
  • تحقق من صحة البيانات الواردة باستخدام عوامل تصفية كافية للسماح فقط بالقيم الصالحة لكل استعلام تم إدخاله.
  • عرف بشكل واضح ومحدد الانماط و أنواع البيانات المستخدمة في الاستعلامات

المراجع

مصادر خارجية :