OWASP API Security Top 10: 0xa4 lack of resources and rate limiting

# API4:2019 ضعف في البنية التحتية و حد محاولات الطلبات


| عوامل التهديد/ الاستغلال                                                                                                                                                                     | نقاط الضعف	                                                                                                                   | التأثير	                                                                                                  |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
| خصائص API : قابلية الاستغلال **2**	                                                                                                                                                                | الانتشار **3** : قابلية الاكتشاف  **3**	                                                                                             | التأثر التقني **2** : تأثر الأعمال                                                                           |
| ان عملية الاختراق في بعض الاحيان عملية غير معقدة حيث لا يستلزم الا طلب بسيط للـAPI ومن غير عملية مصادقة كذلك وقد يتم ارسال طلب من خلال جهاز واحد او أجهزة متعددة او أجهزة الخدمات السحابية.	 | من الاخطاء الشائعة والمنتشرة هو عدم وضع معدل لطلبات او لم يتم اختيار الموصفات المناسبة عند تنصيب واجهات برمجة التطبيقات API.	 | قد يؤدي الاستغلال الى هجمات حجب الخدمة DOS مما يجعل واجهة برمجة التطبيقات API غير مستجيبة او خارج الخدمة. |


  

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

تستهلك واجهة برمجة التطبيقات API المصادر والأصول من شبكات ووحدات المعالجة وكذلك وسائط التخزين حيث يعتمد بشكل كبير مقدرة تعامل البنية التحتية حسب طلبات ومدخلات المستخدم لمصادر البيانات. وضع في الاعتبار ان طلبات واجهة برمجة التطبيقات API التي تفوق قدرات البنية التحتية تعرضها للخطر بشكل كبير اذا لم يتم تداركها و وضع معدل لمستوى ومحتوى تلك الطلبات ومنها:

*  مدة حياة الطلب
*  اعلى حد من استخدام الذاكرة العشوائية لكل طلب
* عدد الملفات وطرق وصفها وحفظها وعرضها 
*  عدد العمليات
* عدد وحجم البياتات عند رفعها
* عدد الطلبات لكل مستخدم 
* عدد الصفحات التي يتم عرضها في كل طلب و استجابة لصفحة الواحدة.


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

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

يقوم المهاجم برفع صورة كبيرة الحجم والابعاد عن طريق طلب POST  الى `/api/v1/images` وعند اكتمال عملية الرفع يقوم الخادم باستعراض الصور المتبقية على هيئة ايقونات مصغرة بسبب الابعاد والحجم الذي قد يستغرق الموارد وقد يؤدي الى عدم واجهة برمجة التطبيقات API.
    
## السيناريو الثاني :

 يقوم التطبيق بعرض المستخدمين بحد اقصى 200 مستخدم في كل صفحة من خلال ارسال طلب الى `/api/users?page=1&size=200`، مما قد يمكن المهاجم من تغير القيمة الى 200000 في عدد أسماء المستخدمين المعروضة في صفحة واحد مما يسبب في حدوث مشكلات في أداة قاعدة البيانات وفي الوقت نفسة تصبح واجهة برمجة التطبيقات غير متاحة وغير قادرة على التعامل مع الطلبات الأخرى ( هجمة حجب الخدمة DOS ) ويمكن استخدام نفس السيناريو لاستعراض الأخطاء او لاستغلال بعض عمليات Integer Overflow  او Buffer Overflow.

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

* استخدم  منصة Docker مما يجعل الامر في غاية البساطة في التحكم في الذاكرة العشوائية او وحدات المعالجة و التخزين 
* ضع معدل محدد لعدد الطلبات التي يقوم بطلبها المستخدم خلال اطار زمني معين
* اخطار المستخدم عند تجازو المعدل المحدد في الاطار الزمني المعين 
* قم باضافة بعض آليات التحقق من جانب الخادم في عمليات الطلبات او حتى التحقق من النصوص او العمليات او الطلبات وتحديداً في تلك العمليات التي تتطلب عدد من السجلات يتم استرجاعها من العميل.
* تحديد وفرض الحد الاعلى لحجم وابعاد الطلبات المرفوعة مثل الحد الاقصى لعدد الجمل او الحد الاعلى لعدد الاسطر

### المراجع : 

* [Blocking Brute Force Attacks][5]
* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors,
  processes, restarts)][6]
* [REST Assessment Cheat Sheet][7]

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

* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8]
* [CWE-770: Allocation of Resources Without Limits or Throttling][9]
* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based
  Application Systems][10], NIST

[1]: https://docs.docker.com/config/containers/resource_constraints/#memory
[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu
[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart
[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit
[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts
[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md
[8]: https://cwe.mitre.org/data/definitions/307.html
[9]: https://cwe.mitre.org/data/definitions/770.html
[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf