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

API1:2019 خلل التفويض والصلاحيات

عوامل التهديد/ الاستغلال نقاط الضعف التأثير
خصائص API : قابلية الاستغلال 3 الانتشار 3 : قابلية الاكتشاف 2 التأثر التقني 3 : تأثر الأعمال
يستطيع المهاجم استغلال نقاط الضعف في مصادر البيانات Endpoint المتأثرة بخلل في الصلاحيات من خلال التلاعب او التغير بالمعرف الفريد عند ارسال الطلبات. قد يؤدي كذلك الى الوصول غير المصرح به الى البيانات الحساسة. وتعتبر خلل تفويض الصلاحيات مشكلة شائعة جداً في التطبيقات بسبب عدم إمكانية الخوادم من تتبع العمليات التي يقوم بها المستخدم بشكل كامل. وحيث انه يعتمد بشكل كامل على إيصال كل معرف فريد لمصدر البيانات الذي يطلب منه. يعتبر هذا الهجوم هو الأكثر شيوعاً على واجهات برمجة التطبيقات API. حيث ان استخدام مثل هذه الاليات شائعة جداً في التطبيقات الحديثة وواسعة الانتشار. حتى وان كانت صلاحيات الوصول في البنية التحتية للتطبيق مبنيه بشكل سليم، فقد ينسى المطورون استخدام تلك الصلاحيات في الوصول الى البيانات الحساسة وقد لا يتم اكتشاف نقاط الضعف المبنية على خلل صلاحيات الوصول من خلال عمليات المسح للبحث عن الثغرات بشكل آلي. يمكن أن يؤدي الوصول غير المصرح به إلى الكشف عن البيانات لأطراف غير مصرح لها أو فقدان البيانات أو التلاعب بها وكذلك يمكن أن يؤدي الوصول غير المصرح به إلى إلى الاستيلاء الكامل على الحساب.

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

ان عمليات إدارة صلاحيات الوصول والتحكم بها عادة يبنى من خلال كتابة الاكواد البرمجية في المقام الأول بشكل سليم بحيث يستطيع المستخدم الوصول الى البيانات المسموح له بالوصول لها. ان جميع مصادر البيانات الخاصة بـ API لها معرف وكائن وصلاحيات خاص ومرتبطة بها، وعند وجود أي اجراء على تلك المصادر او الكائنات يجب ان يتم استخدام تلك التصاريح. حيث يتم التحقق من صلاحيات المستخدم الذي قام بعملية تسجيل الدخول ومعرفة إذا كان لدية حق الوصول لأجراء او استعراض او تعديل البيانات. وعادة ما يؤدي الفشل في التحقق من هذه الالية الى الكشف والتعديل عن معلومات وبيانات الغير مصرح به.

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

السيناريو الاول

توفر منصة التجارة الالكترونية مواقع عبر الانترنت (عبارة عن متاجر الالكترونية) خدمة مصادر الربح الخاصة بالمتاجر المستضاف على المنصة، حيث يستطيع المهاجم من خلال عرض مصدر الصفحة معرفة API الذي قام بجلب تلك المعلومات ومعرفة مصدرها على سبيل المثال : /shops/{shopName}/revenue_data.json ومن خلال تلك الطريقة يستطيع المهاجم من الحصول على بيانات الربح لجميع المتاجر المتسضافة في المنصة من خلال تغير {shopName} في عنوان URL بطريقة غير مصرح بها.

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

اثناء فحص حركة مرور البيانات من قبل المهاجم، قام بإرسال طلب من نوع PATCH من خلال بروتوكول HTTP لاختبار وفحص جميع الردود من قبل الخادم، وبعد عمليات متعددة قام المهاجم بإرسال طلب من نوع PATCH وهو احد الطلبات المتعارف عليها في برتوكول HTTP. تتضمن الترويسة الافتراضية التي يستخدمها الطلب هي header X-User-Id: 54796 مما لفت انتباه المهاجم الى تغيرها لي header X-User-Id: 54795 مما سمح للمهاجم بالوصول/و التعديل الغير مصرح به لبيانات مستخدمين اخرين.

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

  • الاعتماد على سياسة و آلية تخويل لصلاحيات تعتمد على سياسة الاستخدام المقبول والتسلسل الهرمي السهل الواضح.
  • استخدام آلية لتحقق من صلاحيات المستخدم الذي قام بتسجيل الدخول وهل لديه الحق في تنفيذ الإجراءات على السجلات في كل سجل على حدة وبشكل مستقل.
  • يفضل استخدام قيم عشوائية وغير قابلة لتخمين في استخدام GUIDs في السجلات
  • يفضل كتابة معايير لاختبار مدى نضج التفويض والصلاحيات و عدم القيام باى تغييرات قد تؤدى الى وجود ثغرات حتى لا يتم كسر المعايير التى تم كتابتها

المراجع

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