API6:2019 التعيين الجماعي
| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
|---|---|---|
| خصائص API : قابلية الاستغلال 2 | الانتشار 2 : قابلية الاكتشاف 2 | التأثر التقني 2 : تأثر الأعمال |
| يتطلب الاستغلال عادةً فهم منطق آلية العمل وعلاقة الكائنات ببعضها وهيكل واجهة برمجة التطبيقات API. حيث يعد استغلال التعيين الجماعي أسهل في واجهات برمجة التطبيقاتAPI ، حيث أنها تفصح عن أجزاء من بنية التطبيق ومسميات خصائصه. | تشجع الأطر الحديثة في البرمجة المطورين على استخدام الدوال التي تربط بشكل الأوتوماتيكي المدخلات من المستخدم مع المتغيرات البرمجية ومكونات التطبيق الداخلية. يستطيع المهاجم استخدام هذه الخاصية لتحديث أو تغيير بعض الخصائص الحساسة لمكونات التطبيق التي لم ينوى المطور السماح بها. | قد يؤدي هذا الاستغلال إلى تصعيد الصلاحيات والتلاعب بالبيانات وتجاوز آليات الأمان وغير ذلك. |
هل أنا معرض لهذه الثغرة؟
تحتوي بعض التطبيقات الحديثة على العديد من الخصائص وبعض تلك الخصائص يجب تحديثها بواسطة المستخدمين على سبيل المثال user.first_name أو user.address وبعض الخصائص لا يسمح للمستخدمين بتعديلها على سبيل المثال user.is_vip.
تكون واجهة برمجة التطبيقات API ومصادر البيانات عرضة للاختراق إذا تم استخدام مدخلات المستخدم ككائنات داخلية، من دون مراعاة لمستوى حساسية وخطورة تلك الكائنات. وها قد يسمح للمهاجم بتحديث خصائص الكائنات التي لا يجب أو غير مصرح له بالوصول إليها.
أمثلة على بعض الخصائص الحساسة:
- التعديل في بعض الخواص: مثل
user.is_admin,user.is_vipيجب أن تكون فقط لأصحاب الصلاحيات الإدارية. - الخواص المعتدة على العمليات: مثل
user.cashيجب أن يتم التحقق داخلياً بعد التأكد من عملية الدفع. - الخواص الداخلية: على سبيل المثال
article.created_timeيجب أن يكون داخلياً وبواسطة التطبيق فقط.
أمثلة على سيناريوهات الهجوم:
السيناريو الأول
تطبيق مخصص لرحلات يوفر للمستخدم خيار تعديل البيانات والمعلومات الأساسية للملف الشخصي من خلال إرسال طلب بواسطة برمجة واجهة التطبيقات API التالي /api/v1/users/me بواسطة طلب PUT باستخدامJSON بالشكل التالي:
{"user_name":"inons","age":24}
يتضمن الطلب GET للمسار التالي /api/v1/users/me مع خاصية معرفة الرصيد الائتمانية:
{"user_name":"inons","age":24,"credit_balance":10}
حيث قام المهاجم باعتراض الطلب وتغيره إلى التالي:
{"user_name":"attacker","age":60,"credit_balance":99999}
ونظراً لان مصادر البيانات مصابة بخلل في التعيين والتعديل قام المهاجم بالحصول على مبالغ مالية من دون دفع أي مبلغ حقيقي.
السيناريو الثاني:
تتيح منصة مشاركة ملفات الفيديو تحميل ورفع وتنزيل الملفات بتنسيقات وامتدادات مختلفة. حيث لاحظ المهاجم أن واجهة برمجة التطبيقات والتي تستطيع الوصول لها من خلال طلب GET على المسار التالي /api/v1/videos/{video_id}/meta_data انه يستطيع الحصول على ملف JSON يحتوي على خصائص ملفات الفيديو. على سبيل المثال mp4_conversion_params":"-v codec h264 مما يوضح أن التطبيق يستخدم أوامر Shell لعملية تحويل الفيديو.
وجد المهاجم احد مصادر البيانات مصابة بالثغرة التي تسمح له بالتعديل والتعين فقام بإرسال تعليمات برمجية ضارة باستخدام واجهة برمجة التطبيقات API مع طلب POST من خلال المسار التالي /api/v1/videos/new حيث قام بتعين القيمة التالية مع العملية mp4_conversion_params":"-v codec h264 && format C:/ والتي سمحت للمهاجم بتنفيذ التعليمات من خلال أوامر Shell بعد إرساله لطلب تنزيل ملف الفيديو.
كيف أمنع هذه الثغرة؟
- تجنب بقدر ما يمكن استخدام الوظائف التي تتطلب من المستخدم إدخال بعض المتغيرات في الاكواد الداخلية.
- أضف الخصائص التي يتوجب على المستخدم إدخالها إلى قائمة بيضاء محددة.
- استخدام الطرق والأساليب التي تمنع المستخدم من الاطلاع أو الوصول غير المصرح به إلى المصادر أو الخصائص.
- إذا كان من الممكن فرض سياسة استخدام مدخلات محددة في البيانات عند عمليات الرفع أو التنزيل.