‫أهم عشرة مخاطر أمنية تستهدف واجهة برمجة‬‫التطبيقات (‪)API‬‬‫جدول المحتويات‬‫عن منظمة أواسب‬‫هو مشروع‪/‬مجتمع ألمن تطبيقات الويب مفتوح المصدر‬‫يهدف إلى تمكين المؤسسات من تطوير أو شراء أو‬‫صيانة تطبيقاتها بشكل آمن و موثوق‬‫في مجتمع ‪ OWASP‬ستجد ‪:‬‬‫•‬

‫معايير و أدوات التطبيقات اآلمنة‬‫•‬‫كتب ومراجع كاملة عن اختبار تطبيقات الويب و‬‫التطوير اآلمن ومراجعة الشفرة المصدرية‬‫•‬‫العروض التقديمية‬‫•‬‫ملخصات في العديد من المواضيع‬‫•‬‫مكتبة المعايير األمنية والضوابط‬‫•‬‫الفروع المحلية حول العالم‬‫•‬‫البحوث‬‫•‬‫المؤتمرات حول العالم‬‫•‬‫القائمة البريدية‬‫لالستزداة تفضل ‪https://www.owasp.org‬‬‫إن جميع األدوات والوثائق والمنتديات والمنظمات‬‫الفرعية لمنظمة (أواسب) هي مجانية ومفتوحة لجميع‬‫المهتمين بتطوير أمن التطبيقات‪ .‬نقدم أمن التطبيقات‬‫كمشكلة تتضمن العامل البشري‪ ،‬واإلجراءات‪ ،‬والتقنية؛‬‫وذلك ألن أفضل األساليب فعالية في أمن التطبيقات‬‫تتطلب تحسين جميع هذه المجاالت الثالثة‪.‬‬‫جدول المحتويات‬‫جدول المحتويات‪2.........................................................‬‬‫مقدمة ‪3.........................................................................‬‬‫مدخل ‪4..........................................................................‬‬‫مالحظات عن اإلصدار‪5..................................................‬‬‫مخاطر برمجة واجهة التطبيقات‪6..................................‬‬‫أهم عشرة مخاطر امنية تستهدف واجهة برمجة‬‫التطبيقات (‪7............................................................)API‬‬‫‪ API1:2019‬خلل التفويض والصالحيات ‪8..........................‬‬‫‪ API2:2019‬خلل في صالحيات المستخدم‪10...................‬‬‫‪ API3:2019‬خلل في استعراض البيانات‪12......................‬‬‫‪ API4:2019‬ضعف في البنية التحتية و حد محاوالت‬‫الطلبات‪14......................................................................‬‬‫‪ API5:2019‬ضعف في التحقق من الهوية وادارة‬‫التفويض والصالحيات‪16..................................................‬‬‫‪ API6:2019‬خلل في التعيين او التعديل ‪18.......................‬‬‫‪ API7:2019‬االعداد الخاطئ‪20........................................‬‬‫‪ API8:2019‬الحقن ‪22......................................................‬‬‫‪ API9:2019‬خلل في ادارة االصول‪24..............................‬‬‫‪ API10:2019‬خلل في طريقة تسجيل االحداث والمراقبة ‪.‬‬‫‪26‬‬‫ما التالي للمطورين؟‪28.................................................‬‬‫ما التالي لمطوري الممارسات االمنية في التطبيقات؟‪..‬‬‫‪29‬‬‫المنهجية والبيانات ‪30.....................................................‬‬‫اإلقرار ‪31.......................................................................‬‬‫(أواسب) هي منظمة فريدة من نوعها‪ .‬حريتنا من‬‫الضغوط التجارية تسمح لنا بتقديم معلومات عن أمن‬‫التطبيقات غير متحيزة وعملية وفعالة من ناحية التكلفة‪.‬‬‫إن (أواسب) ال تتبع أي شركة تجارية‪ ،‬مع أننا ندعم‬‫االستخدام الواعي للتقنيات األمنية التجارية‪ .‬على غرار‬‫الكثير من مشاريع البرمجيات مفتوحة المصدر‪ ،‬فإن‬‫(أواسب) تقدم أنواع كثيرة من المواد بشكل تعاوني‬‫ومفتوح‪.‬‬‫مؤسسة (أواسب) هي منشأة غير ربحية تضمن النجاح‬‫المستمر للمشروع‪ .‬تقريبًا‪ ،‬جميع المنتسبين إلى‬‫(أواسب) هم من المتطوعين بمن فيهم أعضاء المجلس‪،‬‬‫هذا العمل يخضع لترخيص‬‫‪Creative Commons Attribution ShareAlike 4.0 International License‬‬‫‪https://owasp.org‬‬‫مقدمة‬‫واللجان العالمية‪ ،‬وقادة المنظمات الفرعية‪ ،‬وقادة المشاريع وأعضائها‪ .‬نحن ندعم األبحاث األمنية اإلبداعية بالمنح‬‫وتوفير البنية التحتية‪.‬‬‫إنضم إلينا‬‫مؤسسة (أواسب) هي منشأة غير ربحية تضمن النجاح المستمر للمشروع‪ .‬تقريبًا‪ ،‬جميع المنتسبين إلى (أواسب) هم‬‫من المتطوعين بمن فيهم أعضاء المجلس‪ ،‬واللجان العالمية‪ ،‬وقادة المنظمات الفرعية‪ ،‬وقادة المشاريع وأعضائها‪.‬‬‫نحن ندعم األبحاث األمنية اإلبداعية بالمنح وتوفير البنية التحتية‪.‬‬‫وألن طبيعة عمل واجهة برمجة التطبيقات (‪ )API‬يؤدي الستعراض بعض المعلومات الحساسة أو الشخصية‪ ،‬نجد أنها‬‫تعتبر هدف أساسي للمهاجمين وبشكل متزايد‪ .‬لذلك عدم تأمين البيئة الخاصة بواجهة برمجة التطبيقات ( ‪)API‬‬‫سيؤدي إلى الحد من التطوير السريع للبرمجيات‪.‬‬‫على الرغم من وجود مخاطر متعددة على تطبيقات الويب والتي تم نشرها في وثيقة مستقلة بعنوان أعلى عشر‬‫مخاطر (‪ )OWASP TOP 10‬تستهدف لتطبيقات الويب‪ ،‬وباإلضافة لذلك فإن المخاطر التي تستهدف واجهة برمجة‬‫تطبيقات الويب (‪) API‬ال تقل أهمية عنها بل يستوجب علينا التركيز عليها إليجاد حلول استراتيجية مستدامة من شأنها‬‫تخفيف المخاطر ونقاط الضعف المرتبطة مع واجهة برمجة التطبيقات‪.‬‬‫إذا كنت معتادًا على مشروع ‪ ،OWASP Top 10‬فستالحظ أوجه التشابه بين كال المستندين‪ :‬إنهما مخصصان للقراء‬‫واالعتماد‪ .‬أما إذا كنت جديدًا في سلسلة ‪ ،OWASP Top 10‬فقد يكون من األفضل لك قراءة أقسام مخاطر األما‬‫والمنهجية والبيانات الخاصة بواجهة برمجة التطبيقات (‪ )API‬قبل االنتقال إلى قائمة المخاطر ‪ 10‬هنا‪.‬‬‫يمكنك المساهمة في ‪ OWASP API Security Top 10‬بأسئلتك وتعليقاتك وأفكارك في مستودع مشروع ‪:GitHub‬‬‫•‬‫‪https://github.com/OWASP/API-Security/issues‬‬‫•‬‫‪https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md‬‬‫تستطيع الوصول إلى الوثيقة ‪ OWASP API Security Top 10‬من هنا‪:‬‬‫•‬‫‪https://www.owasp.org/index.php/OWASP_API_Security_Project‬‬‫•‬‫‪https://github.com/OWASP/API-Security‬‬‫نود أن نشكر جميع المساهمين الذين جعلوا هذا المشروع متوفر لكم على جهودهم ومساهماتهم‪ ،‬حيث تم سردها‬‫جميعًا في قسم الشكر والتقدير‪.‬‬‫شكرا لكم!‬‫مدخل‬‫مرحبا ً بك في أهم عشرة مخاطر امنية تستهدف واجهة برمجة التطبيقات (‪)API‬‬‫مرحبًا بك في اإلصدار األول من ‪ .OWASP API Security Top 10‬إذا كنت على دراية بسلسلة ‪ ،OWASP Top 10‬ستالحظ‬‫أوجه التشابه بينهم‪ :‬حيث نوصي بقراءة ‪ OWASP Top 10‬قبل الشروع في قراءة هذا المحتوى‪.‬‬‫ما جدًا في هندسة التطبيقات الحديثة‪ .‬وعلى الرغم من أن رفع الوعي‬‫تلعب واجهات برمجة التطبيقات (‪)API‬‬‫دورا مه ً‬‫ً‬‫ألمني في البرمجة اآلمنة واالبتكار لهما خطوات مهمة ومختلفة‪ ،‬فمن المهم التركيز على نقاط الضعف األمنية‬‫الشائعة لواجهة برمجة التطبيقات (‪.)API‬‬‫الهدف األساسي من وثيقة أهم عشرة مخاطر تستهدف واجهات برمجة التطبيقات ‪ ،API‬هو زيادة الوعي للمشاركين‬‫في تطوير صيانة واجهة برمجة التطبيقات ‪ API‬كالمطورين‪ ،‬المصممين‪ ،‬مهندسي البنية التحتية‪ ،‬المدراء و‬‫المؤسسات‪.‬‬‫في قسم المنهجية والبيانات ‪ ،‬يمكنك قراءة المزيد حول كيفية إنشاء اإلصدار األول وما هو المتوقع من اإلصدارات‬‫المستقبلية‪ ،‬حيث نهدف إلى تمكين صناعة األمن في برمجة واجهة التطبيقات ‪ ،API‬كما نشجع الجميع على‬‫المساهمة في طرح األسئلة والتعليقات واألفكار من خالل مخزننا على ‪ GitHub‬أو القائمة البريدية‪.‬‬‫مالحظات عن اإلصدار‬‫هذا هو اإلصدار األول من ‪ ،OWASP API Security Top 10‬والذي نخطط لتحديثه بشكل دوري كل ثالث أو أربع سنوات‪.‬‬‫على عكس هذا اإلصدار‪ ،‬في اإلصدارات المستقبلية سنقوم بدعوة عامة للمشاركة في هذا التحديث لتمكين صناعة‬‫تطبيقات منة بجهود مشتركة‪ .‬في قسم المنهجية والبيانات ستجد المزيد من التفاصيل حول طريقة كتابة هذا‬‫اإلصدار‪ .‬لمزيد من لتفاصيل حول مخاطر األمان‪ ،‬يرجى الرجوع إلى قسم مخاطر أمان واجهة برمجة التطبيقات (‬‫‪.)API‬‬‫من المهم أن ندرك بأنه على مدى السنوات القليلة الماضية قد تغيرت بنية التطبيقات بشكل كبير‪ .‬حيث تلعب‬‫م ا للغاية في هذه البنية الجديدة للخدمات المصغرة‬‫واجهات رمجة التطبيقات (‪ )API‬في الوقت الحالي‬‫دورا مه ً‬‫ً‬‫وتطبيقات لدخول ذات الصفحة الواحدة (‪ )SPA‬وتطبيقات األجهزة المحمولة وإنترنت األشياء وما إلى ذلك‪.‬‬‫إن بناء ‪ OWASP API Security Top 10‬يحتاج إلى جهد كبير بهدف خلق الوعي حول مشكالت أمان ‪ API‬الحديثة‪ .‬نكرر‬‫لشكر لجميع المتطوعين في إنشاء هذه الوثيقةوالذين تم إدراجهم في قسم الشكر والتقدير‪.‬‬‫شكرا لك!‬‫ً‬‫مخاطر برمجة واجهة التطبيقات‬‫تم استخدام نموذج تقييم المخاطر الخاص بـ ‪ OWASP‬وذلك بهدف تحليل المخاطر‪.‬‬‫يلخص الجدول أدناه المصطلحات المرتبطة بدرجة المخاطر‪.‬‬‫عوامل التهديد‬‫االستغالل‬‫نقاط الضعف‬‫االمنية‬‫خصائص ‪API‬‬‫بسيط ‪3‬‬‫منتشر ‪4‬‬‫خصائص ‪API‬‬‫متوسط ‪2‬‬‫عام ‪2‬‬‫خصائص ‪API‬‬‫صعب ‪1‬‬‫صعب ‪1‬‬‫التأثيرات‬‫اكتشاف‬‫التأثيرات‬‫على‬‫الضعف‬‫التقنية‬‫االعمال‬‫االمني‬‫تحديد‬‫حرج ‪3‬‬‫بسيط ‪3‬‬‫االعمال‬‫تحديد‬‫متوسط ‪ 2‬متوسط ‪2‬‬‫االعمال‬‫تحديد‬‫منخفض‬‫صعب ‪1‬‬‫االعمال‬‫مالحظة‪:‬‬‫هذا النهج ال يأخذ في االعتبار احتمال وجود عامل التهديد‪ ،‬كما أنه ال يأخذ في الحسبان أيًا من التفاصيل الفنية‬‫المختلفة المرتبطة بتطبيقك‪ .‬يمكن ألي من هذه العوامل أن تؤثر بشكل كبير على االحتمالية اإلجمالية للمهاجم‬‫للعثور على ثغرة أمنية معينة واستغاللها‪ .‬ال يأخذ هذا التصنيف في االعتبار التأثير الفعلي على عملك‪ ،‬سيتعين على‬‫مؤسستك تحديد مقدار المخاطر األمنية من التطبيقات وواجهات برمجة التطبيقات التي ترغب المؤسسة في قبولها‬‫في ضوء البيئة التنظيمية‪ .‬الغرض من ‪ OWASP API Security Top 10‬ليس القيام بتحليل المخاطره نيابة عنك‬‫المراجع ‪:‬‬‫•‬‫‪OWASP Risk Rating Methodology‬‬‫•‬‫‪Article on Threat/Risk Modeling‬‬‫مصادر خارجية‪:‬‬‫•‬‫‪ISO 31000: Risk Management Std‬‬‫•‬‫‪ISO 27001: ISMS‬‬‫•‬‫)‪NIST Cyber Framework (US‬‬‫•‬‫)‪ASD Strategic Mitigations (AU‬‬‫•‬‫‪NIST CVSS 3.0‬‬‫•‬‫‪Microsoft Threat Modeling Tool‬‬‫أهم عشرة مخاطر امنية تستهدف واجهة برمجة التطبيقات (‪)API‬‬‫‪ API1:2019‬خلل التفويض والصالحيات‬‫تقوم واجهة برمجة التطبيقات ‪ API‬الى كشف بعض المعلومات عن مصدر‬‫التعامل مع الطلبات وهو بالعادة يكون (‪ )endpoints‬التي تتعامل مع‬‫الطلبات الناشئة مما قد يؤدي الى مشكلة في التحكم في مستوى‬‫صالحيات الوصول ‪ ،‬حيث يجب ان يكون هناك مستوى صالحيات محدد‬‫ومعرف ومحدود لكل طلب يتم ارساله الى مصدر البيانات بواسطة‬‫المستخدمين‪.‬‬‫‪ API2:2019‬خلل في صالحيات‬‫المستخدم‬‫غالب ًا ما يتم تنفيذ آليات المصادقة بشكل غير صحيح ‪ ،‬مما يسمح‬‫للمهاجمين باختراق معايير المصادقة أو استغالل الثغرات المنطقية في‬‫آلية عمل التطبيق مما تسمح له بانتحال هويات المستخدمين االخرين‬‫بشكل مؤقت أو دائم‪ .‬حيث ان اختراق النظام او آلية تحديد هوية‬‫المستخدم هو خطر على ‪ API‬بشكل عام‪.‬‬‫ان تنصيب التقنيات بدون مراعات تغير االعدادت االفتراضية التي قد تودي‬‫‪ API3:2019‬خلل في استعراض البيانات الى الكشف عن خصائص ومعلومات وبيانات هامة وال يجب االعتماد باي‬‫شكل من االشكال على عوامل التصفية لدى المستخدم قبل عرضها‪.‬‬‫‪ API4:2019‬ضعف في البنية التحتية و‬‫حد محاوالت الطلبات‬‫في كثير من األحيان ‪ ،‬ال تفرض واجهات برمجة التطبيقات أي قيود على‬‫حجم أو عدد الموارد التي يمكن أن يطلبها العميل ‪ /‬المستخدم‪ .‬ليس فقط‬‫يمكن لهذا تأثير على أداء الخادم ‪ ،API‬بل قد يؤدي إلى هجمات حجب‬‫الخدمة (‪ ،)DoS‬وكذلك يمكن المهاجم من استخدام هجمة كسر كلمات‬‫المرور‪.‬‬‫‪ API5:2019‬ضعف في التحقق من‬‫الهوية وادارة الصالحيات و التفويض‬‫تميل سياسات التحكم في الوصول المعقد ذات المجموعات واألدوار‬‫المختلفة ‪ ،‬والفصل غير الواضح بينهم في الصالحيات اإلدارية والعادية ‪،‬‬‫إلى عيوب في التفويض والصالحيات‪ .‬والتي تمكن المهاجم من استغالل‬‫هذا الضعف في الوصول إلى المستخدمين اآلخرين و تصعيد الصالحيات‬‫الى صالحيات إدارية‪.‬‬‫‪ API6:2019‬خلل في التعين او التعديل‬‫يؤدي ادخال البيانات المقدمة من المستخدم على سبيل المثال ادخال‬‫البيانات في ملف (‪ )Json‬دون عوامل تصفية او قوائم فلترة خاصة مبنية‬‫على قوائم بيضاء الى خلل في التعديل او التعين والذي يسمح للمهاجمين‬‫بقراءة بيانات او طلب معلومات غير مصرح بها‪.‬‬‫‪ API7:2019‬االعداد الخاطئ‬‫عادة ما يكون االعدادت الخاطئة او االعتماد على االعدادات االفتراضية او‬‫االعدادات و التغيرات الغير مخطط لها مسبقا ً او البيانات السحابية الغير‬‫مؤمنه او االخطاء في اعدادات طلبات بروتوكول ‪ HTTP‬او مشاركة الموارد‬‫(‪ )CORS‬او رسائل الخطأ التفصيلية التي تحتوي على معلومات حساسة‪.‬‬‫‪ API8:2019‬الحقن‬‫تحدث عمليات استغالل الحقن ‪ SQL، NoSQL‬و ‪ ..Command Injection‬الخ‬‫عند ارسال معلومات او بيانات او طلبات او اوامر الى المفسر حيث يتم‬‫خداع المفسر لطلب وتنفيذ تعليمات او الحصول على بيانات غير مصرح‬‫باستخدامها‪.‬‬‫‪ API9:2019‬خلل في ادارة االصول‬‫تميل واجهات برمجة التطبيقات ‪ API‬الى الكشف عن مصادر البيانات (‬‫‪ )Endpoints‬مما يجعل عمليات التوثيق في المستندات لجميع التغيرات في‬‫غاية االهمية ويجب الحذر عند اجراءها‪ ،‬حيث ان اعدادت وتنصيب الخوادم‬‫بشكل صحيح عند تثبيت ‪ API‬مهم جدا ً في تقليل االخطاء التي قد تؤدي الى‬‫الكشف عن البيانات على سبيل المثال االصدار الخاص بـ‪ API‬او واجهة‬‫معالج االخطاء الخاصة به‪.‬‬‫‪ API10:2019‬خلل في طريقة تسجيل‬‫االحداث والمراقبة‬‫ان التسجيل الغير صحيح لالحداث و المراقبة لها يؤدي الى ضعف عملية‬‫االستجابة للحوادث‪ ،‬مما يسمح للمهاجم بالعودة مره اخرى او حتى البقاء‬‫داخل الشبكة او التنقل داخل الشبكة او االطالع و التالعب و تسريب‬‫البيانات حيث تٌظهر معظم الدراسات ان الوقت الالزم الكتشاف‬‫‪ API1:2019‬خلل التفويض والصالحيات‬‫التهديد‬‫اسلوب‬‫الهجوم‬‫االختراقات يزيد عن ‪ 200‬يوم وعادة ما يتم اكتشاف تلك االختراقات من‬‫نقاط الضعف‬‫التأثير‬‫اطراف خارجية بدال ً من المراقبة بسبب ضعفها‪.‬‬‫‪ API1:2019‬خلل التفويض والصالحيات‬‫خصائص ‪API‬‬‫قابلية‬‫االستغالل‪3 :‬‬‫االنتشار ‪3 :‬‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪2 :‬‬‫االعمال‪3 :‬‬‫يستطيع المهاجم استغالل نقاط‬‫الضعف في مصادر البيانات‬‫ً‬‫يعتبر هذا الهجوم هو األكثر شيوعا على‬‫‪ Endpoint‬المتأثرة بخلل في‬‫الصالحيات من خالل التالعب او واجهات برمجة التطبيقات ‪ .API‬حيث ان‬‫استخدام مثل هذه االليات شائعة جدا ً في‬‫التغير بالمعرف الفريد عند‬‫ارسال الطلبات‪ .‬قد يؤدي كذلك التطبيقات الحديثة وواسعة االنتشار‪ .‬حتى‬‫الى الوصول غير المصرح به الى وان كانت صالحيات الوصول في البنية‬‫التحتية للتطبيق مبنيه بشكل سليم‪ ،‬فقد‬‫البيانات الحساسة‪ .‬وتعتبر خلل‬‫تفويض الصالحيات مشكلة شائعة ينسى المطورون استخدام تلك الصالحيات‬‫في الوصول الى البيانات الحساسة وقد ال‬‫جدا ً في التطبيقات بسبب عدم‬‫إمكانية الخوادم من تتبع العمليات يتم اكتشاف نقاط الضعف المبنية على خلل‬‫التي يقوم بها المستخدم بشكل صالحيات الوصول من خالل عمليات المسح‬‫للبحث عن الثغرات بشكل آلي‪.‬‬‫كامل‪ .‬وحيث انه يعتمد بشكل‬‫كامل على إيصال كل معرف فريد‬‫لمصدر البيانات الذي يطلب منه‪.‬‬‫خصائص ‪API‬‬‫يمكن أن يؤدي الوصول غير‬‫المصرح به إلى الكشف عن‬‫البيانات ألطراف غير مصرح لها أو‬‫فقدان البيانات أو التالعب بها‬‫وكذلك يمكن أن يؤدي الوصول غير‬‫المصرح به إلى إلى االستيالء‬‫الكامل على الحساب‪.‬‬‫هل واجهة برمجة التطبيقات (‪ )API‬مصابة ؟‬‫ان عمليات إدارة صالحيات الوصول والتحكم بها عادة يبنى من خالل كتابة االكواد البرمجية في المقام األول بشكل‬‫سليم بحيث يستطيع المستخدم الوصول الى البيانات المسموح له بالوصول لها‪ .‬ان جميع مصادر البيانات الخاصة بـ‬‫‪ API‬لها معرف وكائن وصالحيات خاص ومرتبطة بها‪ ،‬وعند وجود أي اجراء على تلك المصادر او الكائنات يجب ان يتم‬‫استخدام تلك التصاريح‪ .‬حيث يتم التحقق من صالحيات المستخدم الذي قام بعملية تسجيل الدخول ومعرفة إذا كان‬‫لدية حق الوصول ألجراء او استعراض او تعديل البيانات‪ .‬وعادة ما يؤدي الفشل في التحقق من هذه االلية الى‬‫الكشف والتعديل عن معلومات وبيانات الغير مصرح به‪.‬‬‫امثلة على سيناريوهات الهجوم‪:‬‬‫السيناريو االول‪:‬‬‫توفر منصة التجارة االلكترونية مواقع عبر االنترنت (عبارة عن متاجر االلكترونية) خدمة مصادر الربح الخاصة‬‫بالمتاجر المستضاف على المنصة‪ ،‬حيث يستطيع المهاجم من خالل عرض مصدر الصفحة معرفة ‪ API‬الذي قام‬‫بجلب تلك المعلومات ومعرفة مصدرها على سبيل المثال ‪ shops/{shopName}/revenue_data.json/ :‬ومن خالل‬‫تلك الطريقة يستطيع المهاجم من الحصول على بيانات الربح لجميع المتاجر المتسضافة في المنصة من خالل تغير‬‫{‪ }shopName‬في عنوان ‪ URL‬بطريقة غير مصرح بها‪.‬‬‫السيناريو الثاني ‪:‬‬
‫اثناء فحص حركة مرور البيانات من قبل المهاجم‪ ،‬قام بإرسال طلب من نوع ‪ PATCH‬من خالل بروتوكول ‪HTTP‬‬‫الختبار وفحص جميع الردود من قبل الخادم‪ ،‬وبعد عمليات متعددة قام المهاجم بإرسال طلب من نوع ‪ PATCH‬وهو‬‫احد الطلبات المتعارف عليها في برتوكول ‪ .HTTP‬تتضمن الترويسة االفتراضية التي يستخدمها الطلب هي ‪header X-‬‬‫‪ User-Id: 54796‬مما لفت انتباه المهاجم الى تغيرها لي ‪ header X-User-Id: 54795‬مما سمح للمهاجم بالوصول‪/‬و‬‫التعديل الغير مصرح به لبيانات مستخدمين اخرين‪.‬‬‫‪ API1:2019‬خلل التفويض والصالحيات‬‫التهديد‬‫اسلوب‬‫الهجوم‬‫نقاط الضعف‬‫التأثير‬‫‪ API1:2019‬خلل التفويض والصالحيات‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫االعتماد على سياسة و آلية تخويل لصالحيات تعتمد على سياسة االستخدام المقبول والتسلسل الهرمي‬‫السهل الواضح‪.‬‬‫استخدام آلية لتحقق من صالحيات المستخدم الذي قام بتسجيل الدخول وهل لديه الحق في تنفيذ‬‫اإلجراءات على السجالت في كل سجل على حدة وبشكل مستقل‪.‬‬‫•‬‫يفضل استخدام قيم عشوائية وغير قابلة لتخمين في استخدام ‪ GUIDs‬في السجالت‬‫•‬‫يفضل كتابة معايير الختبار مدى نضج التفويض والصالحيات و عدم القيام باى تغييرات قد تؤدى الى وجود‬‫ثغرات حتى ال يتم كسر المعايير التى تم كتابتها‬‫•‬‫المراجع ‪:‬‬
‫مصادر الخارجية ‪:‬‬‫•‪CWE-284: Improper Access Control‬‬‫•‪CWE-285: Improper Authorization‬‬‫• ‪CWE-639: Authorization Bypass Through User-Controlled Key‬‬‫‪ API2:2019‬خلل في صالحيات المستخدم‬‫التهديد‬‫خصائص ‪API‬‬‫اسلوب‬‫الهجوم‬‫قابلية‬‫االستغالل‪3 :‬‬‫نقاط الضعف‬‫االنتشار ‪2 :‬‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪2 :‬‬‫االعمال‪3 :‬‬‫التأثير‬‫خصائص ‪API‬‬‫المصادقة في واجهات برمجة‬‫هناك مسألتان فرعيتان‪ .1 :‬محدودية آليات‬‫التطبيقات ‪ API‬هي آلية معقدة‬‫الحماية‪ :‬يجب التعامل مع مصادر البيانات‬‫وصعبة الفهم وقد يكون لدى‬‫يمكن للمهاجمين التحكم في‬‫الخاصة بواجهات برمجة التطبيقات ‪API‬‬‫مهندسي البرمجيات ومهندس امن‬‫والمسؤولة عن المصادقة بشكل مختلف حسابات المستخدمين اآلخرين في‬‫المعلومات بعض المفاهيم الخاطئة‬‫النظام ‪ ،‬وقراءة بياناتهم‬‫عن المصادر االخرى وتأمين طبقات‬‫حول حدود المصادقة وكيفية‬‫إضافية من الحماية ‪ .2‬سوء تنفيذ اآللية‪ :‬يتم الشخصية ‪ ،‬وتنفيذ إجراءات‬‫تنفيذها بشكل صحيح‪ .‬باإلضافة إلى‬‫ً استخدام ‪ /‬تنفيذ اآللية دون مراعاة طرق حساسة نيابة عنهم ‪ ،‬مثل‬‫ذلك‪ ،‬تعد آلية المصادقة هدفًا سهال‬‫االستغالل الهجوم‪ ،‬أو أنها تبني بشكل غير المعامالت المالية وإرسال‬‫نظرا ألنها متاحة‬‫للمهاجمين ‪،‬‬‫ً‬‫صحيح (على سبيل المثال‪ ،‬قد ال تتناسب الرسائل الشخصية‪.‬‬‫للجميع‪ .‬تجعل هاتان النقطتان‬‫آلية المصادقة المصممة ألجهزة إنترنت‬‫مكون المصادقة عرضة للعديد من‬‫األشياء مع تطبيقات الويب)‪.‬‬‫عمليات االستغالل‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫مصادر البيانات وآلية عملها واالصول الخاصة بها تحتاج إلى الحماية‪ .‬حيث يجب معاملة "نسيت كلمة المرور ‪ /‬إعادة‬‫تعيين كلمة المرور" بنفس طريقة آليات المصادقة‪.‬‬‫يكون ‪ API‬معرض للخطر اذا كان‪:‬‬‫•‬‫اذا كان لدى المهاجم قائمة متكاملة من اسماء المستخدمين وكلمات المرور تم الحصول عليها من اختراق‬‫او تسريب سابق‬‫•‬‫عند قيام المهاجم بهجمات كسر كلمة المرور وعدم استخدام آلية تحقق اخرى من المستخدم مثل ‪.Captcha‬‬‫•‬‫كلمات المرور الضعيفة‬‫•‬‫ارسال المعلومات الحساسة او كلمات المرور من خالل ‪.URL‬‬‫•‬‫عدم التحقق بالشكل الصحيح من عمليات المصادقة‬‫•‬‫الموافقة على استخدام المصادقة الغير موقعه او الموقع بشكل غير امن ("‪ )"alg":"none‬او عدم التحقق من‬‫تاريخ انتهاء المصادقة‪.‬‬‫•‬‫استخدام البيانات غير المشفرة في عمليات تسجيل الدخول او عدم حفظ االرقام السرية بشكل مشفر‬‫•‬‫استخدام مفاتيح تشفير ضعيفة‪.‬‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫في حال قام المهاجم بمحاولة الدخول بحسابات متعددة والتي تم الحصول عليها من تسريب للبيانات والتي يجب‬‫ان نقوم بوضع آلية للحماية من هجمات الدخول المتعدد بحسابات صحيح في وقت قصير ومحدود‪.‬‬‫السيناريو الثاني ‪:‬‬
‫في حال قام المهاجم بمحاولة استعاد كلمة المرور من خالل ارسال طلب ‪ POST‬الى ‪api/system/verification-/‬‬‫‪ codes‬وذلك باستخدام اسم المستخدم فقط لتحقق من استعادة كلمة المرور‪ .‬حيث يقوم التطبيق بإرسال رسالة‬‫‪ API2:2019‬خلل في صالحيات المستخدم‬‫نصية لهاتف الضحية مع آلية المصادقة الجديدة والمكونة من ‪ 6‬ارقام‪ .‬وحيث ان ‪ API‬لم يقم بوضع حد اعلى لطلبات‬‫المصادقة سيقوم المهاجم بتنفيذ جميع االحتماليات وذلك بالتخمين على آلية المصادقة التي تم ارسالها الى هاتف‬‫الضحية وذلك بإرسال طلبات متعددة الى ‪ api/system/verification-codes/{smsToken}/‬لتحقق من مصدر البيانات‬‫في حال كان احد عمليات التخمين كانت صحيحة‪.‬‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫يجب ان تكون على دراية بجميع طرق و آليات المصادقة التي تتم من خالل ( الهواتف ‪/‬تطبيقات الويب‬‫‪/‬المصادقة الواحدة‪/‬إلخ)‬‫•‬‫قم بالتعاون مع مهندس التطبيقات لمعرفة ماهي اآلليات المفقودة عند عمليات المصادقة‬‫•‬‫اقرأ عن آليات المصادقة الخاصة بك‪ .‬تأكد من أنك تفهم ماذا وكيف يتم استخدامها ويجب التنويه على ان‬‫برتوكول‪ OAuth .‬ليس للمصادقة ‪ ،‬وال مفاتيح واجهة رمجة التطبيقات ‪ API‬تستخدم للمصادقة‪.‬‬‫•‬‫ال تقم بإختراع واعادة صناعة آليات مصادقة جديدة بل اتبع افضل االمتثاالت والمعايير المتعارف عليها‪.‬‬‫•‬‫يجب التعامل مع مصادر البيانات الستعادة كلمة المرور ونسيت كلمة المرور بشكل صحيح وذلك من خالل‬‫وضع ضوابط و آليات للحد من هجمات كسر كلمات المرور‬‫•‬‫االستفادة من وسائل الحماية كتعطيل الحساب بعد عدد محاوالت غير ناجحة من عمليات تسجيل الدخول‪.‬‬‫•‬‫قم باستخدام نموذج ‪OWASP Authentication Cheatsheet‬‬‫•‬‫في حال توفر التحقق الثنائي قم باستخدامه‪.‬‬‫•‬‫قم بتنصيب التقنيات والطرق واالليات لرصد هجمات كسر كلمات المرور او محاولة استغالل الحسابات‬‫المسربة وقم بوضع آلية محددة لتقليل معدل المصادقة التي تستخدم ‪.API‬‬‫•‬‫قم باستخدام آلية ايقاف الحسابات او ‪ Captcha‬وذلك لتقليل ومنع هجمات كسر كلمات المرور وقم بتنصيب‬‫تقنية عدم اتاحة استخدام كلمات المرور الضعيفة‪.‬‬‫•‬‫يجب عدم استخدام مفاتيح الـ ‪ API‬لمصداقة المستخدم‪ ,‬بل تستخدم لتصديق التطبيقات والمشاريع مع الـ‬‫‪.API‬‬‫المراجع ‪:‬‬‫•‪OWASP Key Management Cheat Sheet‬‬‫•‪OWASP Authentication Cheatsheet‬‬‫•‪Credential Stuffing‬‬‫مصادر الخارجية ‪:‬‬‫•‪CWE-798: Use of Hard-coded Credentials‬‬‫‪ API3:2019‬خلل في استعراض البيانات‬‫التهديد‬‫خصائص ‪API‬‬‫اسلوب‬‫الهجوم‬‫قابلية‬‫االستغالل‪3 :‬‬‫نقاط الضعف‬‫االنتشار ‪2 :‬‬‫قابلية االكتشاف ‪2 :‬‬‫التأثير‬‫التأثر التقني و تأثر‬‫االعمال‪2 :‬‬‫خصائص ‪API‬‬‫تعتمد واجهات التطبيقات ‪ API‬على ان تكون‬‫عوامل التصفية من جانب المستخدم حيث ان‬‫‪ API‬عادة ما يتم استخدامه كمصدر للبيانات‬‫عادة ما يكون الكشف الغير‬‫وفي بعض األحيان يقوم المطورون بتنصيب‬‫مصرح به عن المعلومات او‬‫‪ API‬بشكل عام وافتراضي من غير التفكير في عادة ما يودي الكشف عن‬‫حركة‬‫البيانات من خالل مراقبة‬‫طرق التعامل مع البيانات الحساسة‪ .‬حيث ان البيانات الى االطالع غير المصرح‬‫مرور البيانات او الطلبات وتحليل‬‫به او تسريب البيانات‬‫أدوات الفحص واكتشاف الثغرات األمنية‬‫جميع الردود القادمة من ‪،API‬‬‫تستطيع رصد مثل تلك الثغرات والتي يصعب‬‫وذلك للبحث عن أي بيانات‬‫على ‪ API‬معرفة إذا كان هذا الطلب ألغراض‬‫حساسة يتم استعادتها وغير‬‫االستخدام الصحيح والقانوني او ألغراض‬‫مصرح للمستخدم باالطالع عليها‪.‬‬‫االطالع وتسريب البيانات الحساسة‪ .‬لذلك‬‫يجب ان نقوم بتصنيف البيانات الحساسة‬‫والفهم العميق أللية الطلب لها‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫تقوم واجهة برمجة التطبيقات بإرجاع البيانات الحساسة إلى العميل حسب التصميم والطلب ‪ .‬عادة ما يتم تصفية‬‫هذه البيانات من جانب العميل قبل تقديمها للمستخدم‪ .‬يمكن للمهاجم بسهولة اعتراض حركة المرور ورؤية البيانات‬‫الحساسة‪.‬‬‫امثلة على سيناريوهات الهجوم‪:‬‬‫السيناريو االول‪:‬‬‫يقوم مطورين تطبيق الهواتف الذكية باستخدام‪ api/articles/{articleId}/comments/{commentId} /‬كمصدر للبيانات‬‫وذلك بهدف عرض المقاالت وبعض البيانات الوصفية الخاصة بها‪ .‬وهنا يقوم المهاجم باعتراض حركة مرور البيانات‬‫الصادرة من هذه التطبيق وقراءة تلك البيانات الوصفية والتي قد تقوم بتسريب بعض البيانات الحساسة مثل بيانات‬‫كاتبين التعليقات وبعض بيانات تحديد الشخصية كـ ‪ ،PII‬حيث ان مصدر البيانات تم تنصيبه بشكل افتراضي على هيئة‬‫(‪ )JSON‬ومبنية على عامل التصفية لدى المستخدم‪.‬‬‫السيناريو الثاني ‪:‬‬
‫يسمح نظام المراقبة المبني على أنظمة ‪ IOT‬او انترنت األشياء لمدير النظام بانشاء حسابات للمستخدمين بمختلف‬‫الصالحيات‪ ،‬حيث قام مدير النظام بانشاء حساب الحد حراس االمن والذي مصرح له باالطالع على بعض المباني و‬‫المواقع‪ .‬وعندما قام الحارس باستخدام هاتفه لالطالع على النظام يقوم نظام ‪ API‬باستدعاء لوحة أنظمة المراقبة‬‫المتاحة له من خالل ‪ api/sites/111/cameras/‬والتي تسمح له بمعرفة عدد الكاميرات المتاحة االطالع عليها من قبل‬‫حارس االمن حيث ان بعد عملية الطلب تم استقبال الرد من الخادم ببعض المعلومات التفصيلية على سبيل‬‫المثال{" ‪ }"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy‬والتي ال تظهر على لوحة المراقبة‬‫الخاصة بالحارس ( الواجهة الرسومية ) بل في تفاصيل الطلب فقط والتي تحتوي على جميع الكاميرات والمباني‪.‬‬‫‪ API3:2019‬خلل في استعراض البيانات‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫•‬‫ال تثق ابدا ُ في عوامل التصفية لدى العميل او المستخدم في حال كانت هناك بيانات حساسة‬‫دائما ً قم بمراجعة الطلبات والردود من مصادر البيانات للتاكد من ان جميع البيانات المتوفرة هي بيانات غير‬‫حساسة ومنطقية‬‫•‬‫يجب على مهندسي التطبيقات الداخلية و مسؤولي االنظمة السؤال بشكل دائم من هم مستخدمي تلك‬‫البيانات قبل البدء بتنصيب ‪ API‬جديدة على النظام‪.‬‬‫•‬‫تجنب استخدام اإلعدادات العامة مثل ‪ )(to_json‬و ‪ )(To_string‬واستبدلها بخصائص معينة ومحددة مطلوب‬‫استرجاعها‪.‬‬‫•‬‫قم بتصنيف المعلومات الحساسة و المعلومات المرتبطة بالهوية الشخصية (‪ )PII‬التي يخزنها تطبيقك ويعمل‬‫معها ‪ ،‬مع مراجعة جميع الطلبات الخاصة بواجهة برمجة التطبيقات‪ API‬والردود المتوقعة منها ومعرفة‬‫االشكاليات االمنية التي قد يتم رصدها بتلك الردود‬‫•‬‫قم باستخدام آليات التحقق مثل( ‪ )schema-based response validation mechanism‬وحدد ماهي البيانات التي‬‫يتم ارجاعها مع الطلبات بما في ذلك االخطاء والمعلومات المتوفرة بها‪.‬‬‫•‬‫المراجع ‪:‬‬
‫مصادر خارجية ‪:‬‬‫• ‪CWE-213: Intentional Information Exposure‬‬‫‪ API4:2019‬ضعف في البنية التحتية و حد محاوالت الطلبات‬‫التهديد‬‫اسلوب‬‫الهجوم‬‫خصائص ‪API‬‬‫قابلية االستغالل‪2 :‬‬‫نقاط الضعف‬‫االنتشار ‪3 :‬‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪3 :‬‬‫االعمال‪2 :‬‬‫التأثير‬‫خصائص ‪API‬‬‫ان عملية االختراق في بعض االحيان‬‫قد يؤدي االستغالل الى هجمات‬‫من االخطاء الشائعة والمنتشرة هو‬‫عملية غير معقدة حيث ال يستلزم اال‬‫حجب الخدمة ‪ DOS‬مما يجعل‬‫عدم وضع معدل لطلبات او لم يتم‬‫طلب بسيط للـ‪ API‬ومن غير عملية‬‫اختيار الموصفات المناسبة عند تنصيب واجهة برمجة التطبيقات ‪ API‬غير‬‫مصادقة كذلك وقد يتم ارسال طلب‬‫مستجيبة او خارج الخدمة‪.‬‬‫من خالل جهاز واحد او أجهزة متعددة او واجهات برمجة التطبيقات ‪.API‬‬‫أجهزة الخدمات السحابية‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫تستهلك واجهة برمجة التطبيقات ‪ API‬المصادر واألصول من شبكات ووحدات المعالجة وكذلك وسائط التخزين حيث‬‫يعتمد بشكل كبير مقدرة تعامل البنية التحتية حسب طلبات ومدخالت المستخدم لمصادر البيانات‪ .‬وضع في االعتبار‬‫ان طلبات واجهة برمجة التطبيقات ‪ API‬التي تفوق قدرات البنية التحتية تعرضها للخطر بشكل كبير اذا لم يتم‬‫تداركها و وضع معدل لمستوى ومحتوى تلك الطلبات ومنها‪:‬‬‫•‬‫مدة حياة الطلب‬‫•‬‫اعلى حد من استخدام الذاكرة العشوائية لكل طلب‬‫•‬‫عدد الملفات وطرق وصفها وحفظها وعرضها‬‫•‬‫عدد العمليات‬‫•‬‫عدد وحجم البياتات عند رفعها‬‫•‬‫عدد الطلبات لكل مستخدم‬‫•‬‫عدد الصفحات التي يتم عرضها في كل طلب و استجابة لصفحة الواحدة‪.‬‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫يقوم المهاجم برفع صورة كبيرة الحجم واالبعاد عن طريق طلب ‪ POST‬الى‪ api/v1/images/‬وعند اكتمال عملية‬‫الرفع يقوم الخادم باستعراض الصور المتبقية على هيئة ايقونات مصغرة بسبب االبعاد والحجم الذي قد يستغرق‬‫الموارد وقد يؤدي الى عدم واجهة برمجة التطبيقات ‪.API‬‬‫السيناريو الثاني ‪:‬‬
‫يقوم التطبيق بعرض المستخدمين بحد اقصى ‪ 200‬مستخدم في كل صفحة من خالل ارسال طلب الى‪api/users?/‬‬‫‪ ،page=1&size=200‬مما قد يمكن المهاجم من تغير القيمة الى ‪ 200000‬في عدد أسماء المستخدمين المعروضة في‬‫صفحة واحد مما يسبب في حدوث مشكالت في أداة قاعدة البيانات وفي الوقت نفسة تصبح واجهة برمجة‬‫التطبيقات غير متاحة وغير قادرة على التعامل مع الطلبات األخرى ( هجمة حجب الخدمة ‪ ) DOS‬ويمكن استخدام‬‫نفس السيناريو الستعراض األخطاء او الستغالل بعض عمليات ‪ Integer Overflow‬او ‪.Buffer Overflow‬‬‫‪ API4:2019‬ضعف في البنية التحتية و حد محاوالت الطلبات‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫استخدم منصة ‪ Docker‬مما يجعل االمر في غاية البساطة في التحكم في الذاكرة العشوائية او وحدات‬‫المعالجة و التخزين‬‫•‬‫ضع معدل محدد لعدد الطلبات التي يقوم بطلبها المستخدم خالل اطار زمني معين‬‫•‬‫اخطار المستخدم عند تجازو المعدل المحدد في االطار الزمني المعين‬‫•‬‫قم باضافة بعض آليات التحقق من جانب الخادم في عمليات الطلبات او حتى التحقق من النصوص او‬‫العمليات او الطلبات وتحديدا ً في تلك العمليات التي تتطلب عدد من السجالت يتم استرجاعها من العميل‪.‬‬‫•‬‫تحديد وفرض الحد االعلى لحجم وابعاد الطلبات المرفوعة مثل الحد االقصى لعدد الجمل او الحد االعلى‬‫لعدد االسطر‬‫المراجع ‪:‬‬‫•‬‫‪Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, processes, restarts‬‬‫•‬‫‪Blocking Brute Force Attacks‬‬‫•‬‫‪REST Assessment Cheat Sheet‬‬‫مصادر خارجية ‪:‬‬‫• ‪CWE-307: Improper Restriction of Excessive Authentication Attempts‬‬‫• ‪CWE-770: Allocation of Resources Without Limits or Throttling‬‬‫•“ ‪Rate Limiting (Throttling)” - Security Strategies for Microservices-based Application Systems‬‬‫‪ API5:2019‬ضعف في التحقق من الهوية وادارة التفويض والصالحيات‬‫التهديد‬‫اسلوب‬‫الهجوم‬‫خصائص ‪API‬‬‫قابلية االستغالل‪3 :‬‬‫نقاط الضعف‬‫االنتشار ‪2 :‬‬‫التأثير‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪1:‬‬‫االعمال‪2 :‬‬‫خصائص ‪API‬‬‫ان عملية استغالل هذه الثغرة بسيط نسيبا ً‬‫بحيث يستطيع المهاجم ارسال طلب غير عادة ما يتم تحديد صالحيات‬‫ضار من خالل واجهة برمجة التطبيقات ‪ API‬الوصول للموارد من خالل‬‫الى مصادر البيانات التي من الغير مصرح له االعدادات‪ .‬وفي بعض األحيان‬‫باالطالع عليها‪ .‬وقد تكون تلك المصادر متاحة على مستوى االكواد البرمجية‪ ،‬بعض آليات العمل قد تسمح‬‫للمسخدمين المجهولين او المستخدم الذي ال ان عملية تنصيب طرق التحقق للمهاجم في االستفادة والوصول‬‫يملك صالحيات عالية‪ .‬وحيث ان من السهل بالشكل الصحيح قد تكون في واالطالع الغير مصرح به‪ ،‬او‬‫اكتشاف مثل تلك الثغرات من خالل معرفة بعض األحيان عملية معقدة‪ .‬حيث حصوله على صالحيات إدارية‬‫سلوك الطلبات والياتها المستخدمة وطرق ان معظم التطبيقات الحديثة تمكنه من التحكم والسيطرة‪.‬‬‫طلبها والردود المتوقعة من كل طلب وقد يتم تحتوي على مختلف الصالحيات‬‫استغاللها ببساطة من خالل استبدال طلب والمجموعات بتسلسل هرمي‬‫‪ GET‬بـ ‪ PUT‬او تغير صالحيات المستخدم من " معقد بعض الشئ‪.‬‬‫‪ " User‬الى "‪."Admin‬‬‫هل أنا معرض لهذه الثغرة؟‬‫أفضل طريقة للعثور على مشكالت وخلل تفويض مستوى الصالحيات والمصادقة هي إجراء تحليل عميق آللية‬‫التفويض ‪ ،‬مع مراعاة التسلسل الهرمي للمستخدم ‪ ،‬واألدوار أو المجموعات المختلفة في التطبيق ‪ ،‬وطرح األسئلة‬‫التالية‪:‬‬‫•‬‫هل يستطيع المستخدم العادي الوصول الى مصادر صالحيات المدراء ؟‬‫•‬‫هل يستطيع المستخدم تعديل او تعيين او مسح مصادر البيانات عند تغير طريقة الطلب للبروتوكول على‬‫سبيل المثال من ‪ GET‬الى ‪ DELETE‬؟‬‫•‬‫هل يستطيع المستخدم في مجموعة أ من الوصول الى مصادر المجموعة ب من خالل تخمين مصدر تلك‬‫المجموعة ‪api/v1/users/export_all/‬‬‫•‬‫ال تقم بوضع وتقسيم الصالحيات ما بين الصالحيات المعتادة والصالحيات االدارية من خالل مسار ‪.URL‬‬‫•‬‫و من الشائع لدى المطورين عرض مصادر البيانات اإلدارية ضمن مسار محدد مثل ‪ API/Admin‬ومن الشائع‬‫كذلك استخدام مصادر واحدة للمستخدم العادي وكذلك للمدراء مثل ‪.api/users‬‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫يقوم التطبيق فقط بالسماح للمستخدمين المدعوين بالتسجيل‪ ،‬حيث يقوم التطبيق بطلب ‪ API‬الخاص من خالل‬‫طلب ‪ GET‬على سبيل المثال المسار التالي‪ api/invites/{invite_guid} /‬ويأتي الرد من الخادم والذي يحتوي على ملف‬‫‪ JSON‬مع تفاصيل الدعوة‪ ،‬وكذلك تفاصيل المستخدمين و الصالحيات والبريد االلكتروني‪.‬‬‫يقوم المهاجم بتكرار الطلبات ومحاولة التالعب والتعديل في طريقة الطلب من مصدر البيانات من ‪ GET‬الى ‪POST‬‬‫مع المسار التالي‪api/invites/new/‬حيث ان هذا المسار مسموح بالوصول له فقط ألصحاب الصالحيات اإلدارية‬‫بواسطة صفحة اإلدارة والتي من الواضح عدم تطبيق مستوى المصادقة والتفويض على مستوى الصالحية‪.‬‬‫المهاجم قام باستغالل الخطأ من خالل ارسال طلب دعوة لنفسه ومن ثم قام بإنشاء حساب بصالحيات مرتفعة‪.‬‬‫‪POST /api/invites/new‬‬‫}”‪{“email”:”hugo@malicious.com”,”role”:”admin‬‬‫‪ API5:2019‬ضعف في التحقق من الهوية وادارة التفويض والصالحيات‬‫السيناريو الثاني ‪:‬‬
‫تحتوي واجهة برمجة التطبيقات ‪ API‬على صالحيات وصول الى مصادر البيانات والمحددة فقط لمدراء النظام من‬‫خالل الطلب باستخدام ‪ GET‬للمسار التالي‪ api/admin/v1/users/all/‬حيث ان مصدر البيانات عند ارجاع البيانات ال‬‫تقوم بالتأكد من صالحيات من قام بطلبها او الصالحيات المخولة له مما يمكن المهاجم من تخمين المسارات‬‫الخاصة بمصادر البيانات الستعراض بيانات حساسة غير مصرح له بالوصول لها‪.‬‬‫كيف أمنع هذه الثغرة؟‬‫يجب أن يحتوي التطبيق الخاص بك على وحدة تفويض متسقة وسهلة التحليل يتم استدعاؤها من خالل جميع‬‫وظائف تطبيقك‪ .‬في كثير من األحيان يتم توفير هذه الحماية بواسطة مكون أو أكثر خارج االكواد البرمجية الخاصة‬‫بالتطبيق‪.‬‬‫•‬‫يجب منع الوصول لجميع المصادر بشكل افتراضي وبعد ذلك يتم السماح واالستثناء للمصادر لكل مصدر‬‫على حدة ولكل صالحية بشكل مستقل‪.‬‬‫•‬‫قم بمراجعة صالحيات المصادقة والتفويض الخاص باآلليات العمل‪ ،‬مع مراعاة منطق التسلسل الهرمي‬‫وصالحيات المجموعات والصالحيات على مستوى المستخدمين‪.‬‬‫•‬‫التأكد من ان صالحيات التحكم االدارية مبنية بشكل سليم ومرتبطة بصالحيات المصادقة والتفويض لكل‬‫مجموعة او مستخدم او صالحية‪.‬‬‫•‬‫التأكد من ان االوامر والصالحيات االدارية مبنية بشكل محوكم وهناك وحدة تحكم تقوم بفحص الصالحيات‬‫والتفويض لكل مستخدم بناء على المجموعة التي تم تعيينه بداخلها‪.‬‬‫المراجع ‪:‬‬‫•‬‫‪OWASP Article on Forced Browsing‬‬‫•‬‫‪OWASP Top 10 2013-A7-Missing Function Level Access Control‬‬‫•‬‫‪OWASP Development Guide: Chapter on Authorization‬‬‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-285: Improper Authorization‬‬‫‪ API6:2019‬خلل في التعيين او التعديل‬‫التهديد‬‫خصائص ‪API‬‬‫اسلوب‬‫الهجوم‬‫قابلية االستغالل‪:‬‬‫‪2‬‬‫نقاط الضعف‬‫االنتشار ‪2 :‬‬‫التأثير‬‫قابلية االكتشاف ‪ :‬التأثر التقني و تأثر‬‫االعمال‪2 :‬‬‫‪2‬‬‫خصائص ‪API‬‬‫تشجع األطر الحديثة في البرمجة‬‫المطورين على استخدام الدوال التي‬‫يتطلب االستغالل عادة ً فهم منطق‬‫تربط بشكل األوتوماتيكي المدخالت‬‫آلية العمل وعالقة الكائنات ببعضها‬‫من المستخدم مع المتغيرات‬‫قد يؤدي هذا االستغالل إلى تصعيد‬‫وهيكل واجهة برمجة التطبيقات ‪.API‬‬‫البرمجية ومكونات التطبيق الداخلية‪.‬‬‫الصالحيات والتالعب بالبيانات وتجاوز‬‫حيث يعد استغالل التعيين الجماعي‬‫يستطيع المهاجم استخدام هذه‬‫آليات األمان وغير ذلك‪.‬‬‫أسهل في واجهات برمجة التطبيقات‬‫الخاصية لتحديث أو تغيير بعض‬‫‪ ، API‬حيث أنها تفصح عن أجزاء من‬‫لمكونات‬‫الحساسة‬‫الخصائص‬‫بنية التطبيق ومسميات خصائصه‪.‬‬‫التطبيق التي لم ينوى المطور‬‫السماح بها‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫تحتوي بعض التطبيقات الحديثة على العديد من الخصائص وبعض تلك الخصائص يجب تحديثها بواسطة‬‫المستخدمين على سبيل المثال ‪ user.first_name‬أو‪ user.addres‬وبعض الخصائص ال يسمح للمستخدمين بتعديلها‬‫على سبيل المثال‪.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‬‬‫ونظرا ً الن مصادر البيانات مصابة بخلل في التعيين والتعديل قام المهاجم بالحصول على مبالغ مالية من دون دفع‬‫أي مبلغ حقيقي‪.‬‬‫‪ API6:2019‬خلل في التعيين او التعديل‬‫السيناريو الثاني ‪:‬‬
‫تتيح منصة مشاركة ملفات الفيديو تحميل ورفع وتنزيل الملفات بتنسيقات وامتدادات مختلفة‪ .‬حيث الحظ المهاجم‬‫أن واجهة برمجة التطبيقات والتي تستطيع الوصول لها من خالل طلب ‪ 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‬بعد إرساله لطلب تنزيل ملف الفيديو‪.‬‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫تجنب بقدر ما يمكن استخدام الوظائف التي تتطلب من المستخدم إدخال بعض المتغيرات في االكواد‬‫الداخلية‪.‬‬‫•‬‫أضف الخصائص التي يتوجب على المستخدم إدخالها إلى قائمة بيضاء محددة‪.‬‬‫•‬‫استخدام الطرق واألساليب التي تمنع المستخدم من االطالع أو الوصول غير المصرح به إلى المصادر أو‬‫الخصائص‪.‬‬‫•‬‫إذا كان من الممكن فرض سياسة استخدام مدخالت محددة في البيانات عند عمليات الرفع أو التنزيل‪.‬‬‫المراجع ‪:‬‬
‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes‬‬‫‪ API7:2019‬االعداد الخاطئ‬‫اسلوب‬‫الهجوم‬‫التهديد‬‫خصائص ‪API‬‬‫قابلية‬‫االستغالل‪3 :‬‬‫نقاط الضعف‬‫االنتشار ‪3 :‬‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪3 :‬‬‫االعمال‪2 :‬‬‫التأثير‬‫خصائص ‪API‬‬‫يمكن ان يحدث االعداد الخاطئ في أي‬‫يحاول المهاجمون غالبا ً البحث مستوى من مستويات واجهة برمجة‬‫عن الثغرات األمنية على مستوى التطبيقات ‪ ،API‬ابتداءًا من مستوى الشبكة‬‫قد يؤدي عملية اإلعدادات الخاطئة‬‫األنظمة او اليات العمل اول على الى مستوى التطبيقات‪ ،‬حيث تتوفر األدوات‬‫الى تسريب البيانات وكذلك‬‫مصادر بيانات غير محمية وذلك للقيام بالفحص واكتشاف األخطاء بشكل آلي‬‫اختراق األنظمة والخوادم‪.‬‬‫بغاية الوصول الغير مصرح به وذلك بهدف البحث عن مواطن اإلعدادات‬‫الخاطئة او الخدمات الفعالة والغير ضرورية‬‫للمعلومات‪.‬‬‫او الخيارات القديمة والمصابة بثغرات‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫قد يكون واجهة التطبيقات ‪ API‬معرضة لثغرات في حال ‪:‬‬‫•‬

‫اذا لم يكن هناك أي آلية متبعة لعملية تعزيز حماية النظام في جميع مراحله او اذا كان هناك تهيئة غير‬‫صحيحة على الخدمات السحابية‪.‬‬‫•‬‫اذا لم يكن هناك آلية لسد الثغرات األمنية او في حال كانت األنظمة المستخدمة غير محدثة او خارجة عن‬‫الخدمة‪.‬‬‫•‬‫اذا كان هناك تفعيل لبعض الطلبات الغير مطلوبة مثل بعض طلبات ‪ HTTP‬الغير مستخدمة ‪ TREAC‬او ‪DELETE‬‬‫على سبيل المثال‪.‬‬‫•‬‫اذا لم يتم استخدام التشفير بواسطة ‪.TLS‬‬‫•‬‫إذا لم يتم تعين سياسة مشاركة المواد بطريقة صحيحة او كان هناك خطا في اإلعدادات الخاصة بها‬‫•‬‫إذا كانت رسائل الخطأ تحتوي على معلومات حساسة ويمكن تتبعها‪.‬‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫يعثر المهاجم على ملف‪ bash_history.‬في احد المسارات الرئيسية في الخادم والذي يحتوي على األوامر التي‬‫يستخدمها المطورين في الوصول الى واجهة برمجية التطبيقات ‪.API‬‬‫'==‪$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg‬‬‫يمكن للمهاجم ايضا ً معرفة مصادر البيانات من خالل األوامر التي يستخدمها المطورين من خالل تكرار عملية‬‫الوصول للملف أعاله وما حدث ذلك اال بسبب عدم توثيق اإلجراءات بالشكل الصحيح‪.‬‬‫السيناريو الثاني ‪:‬‬
‫يقوم المهاجمون في معظم األحيان باستخدام محركات البحث بهدف الحصول على خوادم يستطيع من خاللها‬‫الوصول الى مصدر البيانات بشكل مباشر‪ .‬او من خالل البحث عن أحد المنافذ المشهورة في قواعد البيانات او في‬‫إدارة األنظمة والخوادم‪ .‬وفي حال كان الخادم او النظام المستهدف يقوم باستخدام األعدادت االفتراضية وغير‬‫محمي باستخدام مصادقة صحيحة قد يمكن المهاجم من الوصول للبيانات الشخصية ‪ PII‬والذي قد يؤدي الى تسريب‬‫بيانات المستخدمين لتلك الخدمة‪.‬‬‫السيناريو الثالث ‪:‬‬

‫‪ API7:2019‬االعداد الخاطئ‬‫عند اعتراض حركة المرور للبيانات الخاصة بأحد تطبيقات الهواتف المحمولة والتي تستخدم بروتوكول ‪ TLS‬في‬‫حركة البيانات ولكن ال تعتمد على التشفير باستخدام ‪ TLS‬عند استخدام واجهة برمجة التطبيقات ‪ API‬وبعد البحث من‬‫قبل المهاجم استطاع معرفة ان عملية تحميل ورفع الصور يتم بشكل غير مشفر‪ ،‬فقد وجد المهاجم نمط وطريقة‬‫لمعرفة االستجابة الواردة من قبل الخادم او من قبل مصدر البيانات والتي قد تمكنه بطريقة او بأخرى من تتبع‬‫تفضيالت المستخدمين عند تنزيل او عرض تلك الصور‪.‬‬‫كيف أمنع هذه الثغرة؟‬‫دورة حياة واجهة برمجة التطبيقات ‪ API‬البد ان تشتمل على ‪:‬‬‫•‬

‫عملية تعزيز حماية األنظمة تساهم بشكل كبير في بناء بيئة امنة و موثوقة‬‫•‬‫إيجاد آلية لمراجعة اإلعدادات و التحديثات بأكملها ويجب ان تتضمن مراجعة كل من ملفات الحفظ و‬‫المزامنة مكونات واجهة برمجة التطبيقات ‪ API‬و الخدمات السحابية‪.‬‬‫•‬‫توفير اتصال امن و مشفر لجميع االتصاالت في التعامل مع التطبيق او رفع وتحميل الصور‪.‬‬‫•‬‫عملية تقييم امني مستمر لمعرفة مستوى نضج االعدادات في جميع انحاء البنية التحتية‪.‬‬‫عالوة على ذلك‪:‬‬‫•‬‫لمنع تتبع األخطاء التي قد يتم الرد بها بعد عمليات الطلب والتي قد تمكن المهاجم من استعراض البيانات‬‫الحساسة يجب ان تكون جميع الردود محدودة ومحصورة بما في ذلك عمليات االستجابة لألخطاء‪.‬‬‫•‬‫تأكد انه ال يمكن الوصول الى واجهة برمجة التطبيقات ‪ API‬اال من خالل احد الطلبات المحددة وعدم السماح‬‫بجميع الطلبات الخاصة ببروتوكول ‪ HTTP‬بالعمل بل ويجب تعطيلها مثال (‪.)HEAD , TRACE‬‬‫•‬‫يجب على واجهات برمجة التطبيقات ‪ API‬التي تتوقع أن يتم الوصول إليها من عمالء يستندون إلى المتصفح‬‫على سبيل المثال ( الواجهة االمامية لخدمات الويب) يجب تنفيذ سياسة سليمة وموثوقة لمشاركة الموارد‬‫عبر (‪.)CORS‬‬‫المراجع ‪:‬‬‫•‬‫‪OWASP Secure Headers Project‬‬‫•‬‫‪OWASP Testing Guide: Configuration Management‬‬‫•‬‫‪OWASP Testing Guide: Testing for Error Codes‬‬‫•‬‫‪OWASP Testing Guide: Test Cross Origin Resource Sharing‬‬‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-2: Environmental Security Flaws‬‬‫•‬‫‪CWE-16: Configuration‬‬‫•‬‫‪CWE-388: Error Handling‬‬‫•‬‫‪Guide to General Server Security, NIST‬‬‫•‬‫‪Let’s Encrypt: a free, automated, and open Certificate Authority‬‬‫‪ API8:2019‬الحقن‬‫اسلوب‬‫الهجوم‬‫التهديد‬‫خصائص ‪API‬‬‫نقاط الضعف‬‫قابلية االستغالل‪:‬‬‫‪3‬‬‫االنتشار ‪2 :‬‬‫قابلية االكتشاف ‪ :‬التأثر التقني و تأثر‬‫االعمال‪3 :‬‬‫‪3‬‬‫التأثير‬‫خصائص ‪API‬‬‫يقوم المهاجمون بإرسال بيانات تعتبر ثغرات الحقن منشرة وشائعة في‬‫ضارة من خالل واجهة برمجة استعالمات ‪ SQL‬و ‪ LDAP‬و ‪NoSQL‬‬‫يمكن أن يؤدي الحقن إلى إفشاء‬‫التطبيقات ‪ API‬وذلك من خالل حقنها وأوامر أنظمة التشغيل و ‪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‬‬‫;)}‬‫‪ API8:2019‬الحقن‬
‫}‬
‫;)}‬

‫قام المهاجم باعتراض الطلبات الخاصة بالمعرف الفريد ‪ bookingId‬وقام بتغير أمر االستعالم كما هو معروض‬‫باألسفل مما أدى إلى حذف حجز يعود لمستخدم آخر‪:‬‬‫‪DELETE /api/bookings?bookingId[$ne]=678‬‬‫كيف أمنع هذه الثغرة؟‬‫لمنع عمليات الحقن انت بحاجة إلى فصل األوامر والتعليمات البرمجية عن االستعالمات بشكل صحيح و امن‪.‬‬‫•‬‫قم بإجراء التحقق من صحة البيانات المدخلة باستخدام مكتبة موحدة وامنه وموثوقة ويتم صيانتها بشكل‬‫دوري‪.‬‬‫•‬‫تحقق من صحة جميع البيانات المقدمة من المستخدم أو غيرها من البيانات الواردة من األنظمة المتكاملة‬‫وتصفيتها‪.‬‬‫•‬‫يجب التعامل مع األحرف والرموز الخاصة باستخدام الصيغة المحددة للمفسر المستهدف‪.‬‬‫•‬‫استخدم واجهة برمجة تطبيقات آمنة (‪ )safe API‬ذات استعالمات واضحة‪.‬‬‫•‬‫ضع حدا ً لعدد السجالت التي يتم إرجاعها لمنع تسريب البيانات بشكل كبير في حالة نجاح عملية الحقن‪.‬‬‫•‬‫تحقق من صحة البيانات الواردة باستخدام عوامل تصفية كافية للسماح فقط بالقيم الصالحة لكل استعالم‬‫تم إدخاله‪.‬‬‫•‬‫عرف بشكل واضح ومحدد االنماط و أنواع البيانات المستخدمة في االستعالمات‬‫المراجع ‪:‬‬‫•‬‫‪OWASP Injection Flaws‬‬‫•‬‫‪SQL Injection‬‬‫•‬‫‪NoSQL Injection Fun with Objects and Arrays‬‬‫•‬‫‪Command Injection‬‬‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-77: Command Injection‬‬‫•‬‫‪CWE-89: SQL Injection‬‬‫‪ API9:2019‬خلل في ادارة االصول‬‫اسلوب‬‫الهجوم‬‫التهديد‬‫خصائص ‪API‬‬‫قابلية‬‫االستغالل‪3 :‬‬‫نقاط الضعف‬‫االنتشار ‪3 :‬‬‫التأثر التقني و تأثر‬‫قابلية االكتشاف ‪2 :‬‬‫االعمال‪2 :‬‬‫التأثير‬‫خصائص ‪API‬‬‫وثائق األنظمة والبرمجيات الغير محدثة تجعل‬‫من الصعب تتبع وإصالح الثغرات‪ .‬وكذلك عدم‬‫برمجة‬‫واجهة‬‫إصدارات‬‫ً وجود جرد لألصول التقنية واستراتيجية للتخلص‬‫التطبيقات ‪ API‬القديمة غالبا‬‫من األصول القديمة يؤدي إلى وجود أنظمة قد يتمكن المهاجمون من الوصول‬‫غير مرقعة وتعتبر طريق سهل‬‫تعمل بدون ترقيعات أمنية‪ ،‬وذلك قد يؤدي إلى إلى بيانات حساسة‪ ،‬أو حتى‬‫الختراق األنظمة وتجاوز العديد‬‫تسريب للبيانات الحساسة‪ .‬وكما انه من الشائع اختراق الخادم من خالل استغالل‬‫من تقنيات الحماية الحديثة‬‫رصد واجهة برمجة التطبيقات ‪ API‬متاحة على احد الثغرات الغير مرقعة لخدمات‬‫والتي تم تركيبها غالبا ً لحماية‬‫اإلنترنت مع كونها ال تستخدم بسبب المفاهيم واجهة برمجة التطبيقات ‪ API‬والتي‬‫األنظمة الحديثة و المتطورة‬‫الحديثة كالخدمات المصغرة (‪ )microservices‬تستخدم لالتصال بقاعدة البيانات‪.‬‬‫من واجهة برمجة التطبيقات‬‫والتي تجعل من التطبيقات سهلة النشر‬‫‪.API‬‬‫ومستقلة على سبيل المثال (الحوسبة‬‫السحابية)‬‫هل أنا معرض لهذه الثغرة؟‬‫قد يكون واجهة برمجة التطبيقات معرض لمثل هذه الثغره في حالة ‪:‬‬‫•‬

‫الغرض من استخدام واجهة برمجة التطبيقات غير واضح وال توجد إجابات لألسئلة التالية‪:‬‬‫◦ ما هي البيئة التي تعمل فيها واجهة برمجة التطبيقات (على سبيل المثال ‪ ،‬اإلنتاج ‪ ،‬التدريج ‪ ،‬االختبار ‪،‬‬‫التطوير)؟‬‫◦ من المخول للوصول إلى الشبكة الخاصة بواجهة برمجة التطبيقات (على سبيل المثال ‪ ،‬عام ‪ ،‬داخلي ‪،‬‬‫شركاء)؟‬‫◦ ما هو إصدار ‪ API‬المستخدم؟‬‫◦ ماهي البيانات التي يتم جمعها بواسطة ‪API‬؟ وهل هي بيانات شخصية؟‬‫◦ ماهي آلية سير البيانات؟‬‫•‬‫ال توجد وثائق معتمدة أو وثائق قديمة وغير محدثة‪.‬‬‫•‬‫ال توجد خطة للتخلص من إصدارة واجهة برمجة التطبيقات القديمة‪.‬‬‫•‬‫ال يوجد حصر لألصول أو أنه غير محدث‪.‬‬‫•‬‫ال يوجد حصر للخدمات المتصلة باألنظمة سواء كانت طرف أول أو طرف ثالث أو أنه غير محدث‪.‬‬‫•‬‫إصدارات ‪ API‬قديمة وغير محدثة وال تزال مستخدمة‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫بعد إعادة تصميم التطبيقات إلحدى الخدمات‪ ،‬لم يتم التخلص من اإلصدارة القديمة والغير محمية من واجهة برمجة‬‫التطبيقات‪api.someservice.com/v1‬والمتصلة بقاعدة البيانات‪ .‬وبعد عمليات الفحص من قبل أحد المهاجمين توصل‬‫لعنوان واجهة برمجة التطبيقات الجديدة‪ .api.someservice.com/v2‬باستبدال ‪ v2‬بـ‪ v1‬تمكن المهاجم من الوصول‬‫‪ API9:2019‬خلل في ادارة االصول‬‫لواجهة برمجة التطبيقات القديمة والغير محدثة والتي أدت إلى تسريب معلومات شخصية ألكثر من ‪ 100‬مليون‬‫مستخدم‪.‬‬‫السيناريو الثاني ‪:‬‬
‫قامت منصة للتواصل االجتماعي باستخدام آلية للحد من عدد محاوالت تخمين كلمات المرور‪ .‬آلية األمان تلك لم يتم‬‫تطبيقها على الشفرة المصدرية الخاصة بواجهة برمجة التطبيقات ‪ ،API‬بل قاموا بفصلها لكي تكون ما بين‬‫المستخدم وواجهة برمجة التطبيقات(‪ .)socialnetwork.com.‬أحد الباحثين عثر على خادم لنسخة تجريبية (‬‫‪ )www.mbasic.beta.socialnetwork.com‬والتي يستطيع من خاللها القيام بنفس المهام التي تقوم بها الواجهة‬‫المعتمدة بما في ذلك إعادة تعين كلمات المرور لكن بدون آلية األمان التي تحد من عدد محاوالت التخمين‪ .‬و‬‫باستخدام النسخة التجريبية تمكن الباحث من إعادة تعيين كلمة السر بعد قيامة بعمليات بسيطة لتخمين كلمة‬‫المصادقة المكونة من ‪ 6‬أرقام‪.‬‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫جرد وحصر جميع األجهزة الخاصة بواجهة برمجة التطبيقات وتوثيق الجوانب الهامة لك واحد منهم‪ ،‬والتركيز‬‫بشكل كبير على بيئة ‪ ( API‬على سبيل المثال‪ ،‬اإلنتاج ‪ ،‬التدريج ‪ ،‬االختبار ‪ ،‬التطوير)‪ ،‬ومن هم المخولين‬‫بالوصول لهم من الشبكة (كشبكة اإلنترنت أو الداخلية أو الشركاء)‪.‬‬‫•‬‫حصر جميع الخدمات المرتبطة باألنظمة وتوثيق جوانبها المهمة كدورها في النظام ونوعية البيانات التي يتم‬‫تداولها من خاللها وحساسية تلك البيانات‪.‬‬‫•‬‫توثيق جميع جوانب واجهة برمجة التطبيقات ‪ API‬مثل عمليات التحقق واألخطاء وإعادة التوجيه وسياسة‬‫حصر مشاركة الموارد (‪ ،)CORS‬بما في ذلك إعداداتها والطلبات واالستجابة لتلك الطلبات‪.‬‬‫•‬‫إنشاء الوثائق بشكل آلي من خالل تبني المعايير المفتوحة‪ .‬وتضمين عملية بناء الوثائق في خط اإلنتاج‬‫الخاص باختبار ونشر التطبيقات‪.‬‬‫•‬‫التأكد من أن الوثائق متاحة لألشخاص المصرح لهم فقط‪.‬‬‫•‬‫التأكد من استخدام التدابير الوقائية الالزمة مثل جدران الحماية الخاصة بواجهة برمجة التطبيقات ‪ API‬لجميع‬‫إصدارات واجهة برمجة التطبيقات المتصلة باألنترنت وليس فقط اإلصدارة الحالية‪.‬‬‫•‬‫تجنب استخدام بيانات حقيقية من بيئة التشغيل على البيئة التجريبية لواجهة برمجة التطبيقات‪ ،‬وفي حال‬‫توجب عليك استخدامها فيجب أن يتم تطبيق جميع المعايير األمنية نفسها التي يتم تطبيقها على بيئة‬‫التشغيل‪.‬‬‫•‬‫في حال كانت اإلصدارات الحديثة من واجهة برمجة التطبيقات تحتوي على معايير أمان افضل‪ ،‬قم بإجراء‬‫تحليل للمخاطر التخاذ القرارات واإلجراءات التي تخفف من مخاطر اإلصدار القديم‪ .‬على سبيل المثال إذا‬‫كان من الممكن إضافة تلك المعايير األمنية الجديدة لإلصدار السابق من دون التأثير على التوافقية مع‬‫األنظمة األخرى أو أنه البد من التخلص من اإلصدار القديم و إلزام جميع المستخدمين باالنتقال إلى اإلصدار‬‫الحديث‪.‬‬‫المراجع ‪:‬‬
‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-1059: Incomplete Documentation‬‬‫•‬‫‪OpenAPI Initiative‬‬‫‪ API9:2019‬خلل في ادارة االصول‬‫‪ API10:2019‬خلل في طريقة تسجيل االحداث والمراقبة‬‫خصائص ‪API‬‬‫قابلية االستغالل‪:‬‬‫‪2‬‬‫االنتشار ‪3 :‬‬‫قابلية االكتشاف التأثر التقني و تأثر‬‫االعمال‪2 :‬‬‫‪1:‬‬‫خصائص ‪API‬‬‫يستغل المهاجمون عدم تسجيل عدم وجود أو خلل في آلية نظام تسجيل‬‫االحداث وحركة مرور البيانات االحداث و مراقبة حركة مرور البيانات عدم وجود رؤية كاملة على االنشطة‬‫بشكل صحيح للقيام بأنشطة ينتج عنه صعوبة في تتبع األنشطة المشبوة التي تحدث تمنح المهاجمين‬‫ضارة على األنظمة من دون أي المشبوة واالستجابة لها في الوقت الوقت الكافي ألختراق األنظمة‪.‬‬‫المناسب‪.‬‬‫مالحظة‪.‬‬‫هل أنا معرض لهذه الثغرة؟‬‫سيكون النظام لديك معرض اذا كان‪:‬‬‫•‬‫ال يتم استخراج أي سجالت او لم يتم تعيين عمليات التسجيل بالشكل الصحيح او لم يتم جمع السجالت‬‫بشكل كافي وناضج‪.‬‬‫•‬‫عند عدم ضمان السجالت ( على سبيل المثال في حال حقن السجالت بسجالت غير صحيح)‬‫•‬‫ال يتم مراقبة السجالت بشكل مستمر‬‫•‬‫ال يتم مراقبة البنية التحتية لواجهة برمجة التطبيقات ‪ API‬بشكل مستمر‪.‬‬‫امثلة على سيناريوهات الهجوم ‪:‬‬
‫السيناريو االول ‪:‬‬
‫عن طريق الخطأ تم تسريب احد مفاتيح إدارة المستودعات في احد المستودعات العامة‪ ،‬لذا تم أخطار مالك‬‫المستودع عن طريق البريد االلكتروني بشأن التسريب المحتمل‪ ،‬ولكن لم يقم مالك المستودع بالتجاوب في خالل‬‫‪ 48‬ساعة والتصرف بشأن هذا التسريب‪ ،‬وﻷن من المحتمل استخدام هذه المفاتيح في عمليات تسريب البيانات‪ ،‬و‬‫بسبب عدم تسجيل االحداث بشكل صحيح ال تستطيع الشركة تقييم ومعرفة األصول والبيانات التي تم الوصول لها‬‫او في حال تم تسريبها‪.‬‬‫السيناريو الثاني ‪:‬‬
‫منصة مشاركة ملفات الفيديو تعرضت بشكل واسع الى هجمات محاولة كسر كلمات المرور بأستخدام حسابات‬‫مستخدمين صالحة‪ ,‬بالرغم من المحاوالت الكثيرة لعمليات تسجيل الدخول الخاطئة لم تظهر أي تنبيهات اثناء‬‫الهجوم‪ ،‬في حين قام المستخدمين بالشكوى لدى الشركة بشأن اغالق حسابتهم بشكل مفاجئ‪ ،‬وبعد تحليل‬‫سجالت الخاصة بواجهات برمجة التطبيقات ‪ API‬تبين أن هناك هجوم حدث‪.‬لذا قامت الشركة أصدار اعالن لجميع‬‫المستخدمين ألعادة تهيئة كلمات المرور الخاصة بهم‪.‬‬‫‪ API10:2019‬خلل في طريقة تسجيل االحداث والمراقبة‬‫كيف أمنع هذه الثغرة؟‬‫•‬‫قم بتسجيل جميع محاوالت المصادقة الفاشلة او محاوالت رفض الوصول للمجلدات وكذلك جميع المدخالت‬‫الخاطئة‪.‬‬‫•‬‫يجب كتابة السجالت بشكل متناسق الستخدامه في عمليات إدارة السجالت ويجب ان تتضمن كافة‬‫التفاصيل التي تتيح للمحلل معرفة األنشطة الضارة ومن قام بها‪.‬‬‫•‬‫يجب التعامل مع السجالت باعتبارها بيانات حساسة ويجب ضمان سالمتها اثناء المرور و التخزين‪.‬‬‫•‬‫قم بإعداد عمليات المراقبة واجعلها مستمرة ولتشمل البنية التحتية والشبكات و واجهة برمجة التطبيقات‬‫‪.API‬‬‫•‬‫استخدام أنظمة مركز سجل األحداث ‪ SIEM‬إلدارة السجالت من جميع المصادر واألنظمة و واجهات برمجة‬‫التطبيقات‪.‬‬‫•‬‫قم بإعداد لوحة مراقبة مخصصة للتنبيهات األمنية وقم بتفعيل التواقيع الرقمية لرصد األنشطة المشبوهة‬‫لرصدها في مراحلها األولية‪.‬‬‫المراجع ‪:‬‬‫•‬‫‪OWASP Logging Cheat Sheet‬‬‫•‬‫‪OWASP Proactive Controls: Implement Logging and Intrusion Detection‬‬‫•‬‫‪OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification‬‬‫‪Requirements‬‬‫مصادر خارجية ‪:‬‬‫•‬‫‪CWE-223: Omission of Security-relevant Information‬‬‫•‬‫‪CWE-778: Insufficient Logging‬‬‫ما التالي للمطورين؟‬‫قد تكون مهمة إنشاء برامج آمنة وصيانتها ‪ ،‬أو إصالح البرامج الموجودة ‪ ،‬صعبة‪ .‬وكذلك هو الحال مع واجهات برمجة‬‫التطبيقات ال تختلف‪.‬‬‫نعتقد أن التعليم والوعي من العوامل الرئيسية لكتابة برامج آمنة‪ .‬كل شيء آخر من المتطلبات هو لتحقيق األهداف‬‫المنشودة‪ ،‬وهو باألساس يعتمد على إنشاء واستخدام عمليات أمنية قابلة للتكرار وضوابط أمنية قياسية‪.‬‬‫لدى ‪ OWASP‬العديد من الموارد المجانية والمفتوحة لمعالجة مشاكل األمن منذ بداية هذا المشروع‪ .‬يرجى زيارة‬‫صفحة مشاريع أواسب للحصول على قائمة شاملة بالمشاريع المتاحة‪.‬‬‫يمكنك البدء في قراءة مواد مشروع ‪ OWASP‬التعليمي وفقًا لمهنتك واهتماماتك‪ .‬للتعلم‬‫العملي ‪ ،‬أضفنا ‪ crAPI - Ridiculous API‬في خارطة الطريق الخاصة بنا‪ .‬وفي الوقت‬‫نفسه ‪ ،‬يمكنك التدرب على ‪ WebAppSec‬باستخدام ‪، OWASP DevSlop Pixi Module‬‬‫تعليم أمن التطبيقات‬‫وهو تطبيق ويب ضعيف وخدمة ‪ API‬تهدف إلى تعليم المستخدمين كيفية اختبار‬‫تطبيقات الويب الحديثة وواجهات برمجة التطبيقات للتعامل مع مشكالت األمان ‪،‬‬‫ضا حضور‬‫وكيفية كتابة واجهات برمجة تكون أكثر أمانًا في المستقبل‪ .‬كما يمكنك أي ً‬‫جلسات ‪ OWASP AppSec‬التدريبية أو االنضمام إلى فرق ‪ OWASP‬المحلية ‪.‬‬
‫إلنتاج تطبيقات ويب آمنة‪ ،‬يجب عليك تعريف معنى األمن بالنسبة للتطبيق‪ .‬أواسب‬‫متطلبات أمن التطبيقات تنصحك باستخدام مشروع أواسب لمعايير التحقق من أمن التطبيقات‪ ،‬كدليل إرشادي‬‫يساعدك في ضبط المتطلبات األمنية لتطبيقاتك‪ .‬في حال انجاز المشاريع عبر موارد‬‫خارجية‪ ،‬قم بمراجعة ملحق أواسب لعقود البرمجيات اآلمنة‪.‬‬‫يجب أن يظل األمن مصدر لالهتمام خالل جميع مراحل المشروع‪ .‬تعد ورقة المرجعية‬‫من )‪ OWASP (Cheat Sheet‬نقطة انطالق جيدة لإلرشادات حول كيفية تصميم األمان‬‫هيكلة أمن التطبيقات‬‫أثناء مرحلة البناء‪ .‬من بين العديد من االوراق األخرى ‪ ،‬ستجد ورقة مراجع األمان (‬‫‪ )Security Cheat Sheet‬وورقة مراجع التقييم (‪).Assessment Cheat Sheet‬‬‫إن عملية إنشاء أدوات تحكم أمنية قوية ومناسبة لالستخدام هي مهمة صعبة جدا ‪ .‬إن‬‫وجود مجموعة من أدوات التحكم األمنية المعيارية ستسهل –وبشكل جذري‪ -‬عملية‬‫أدوات التحكم األمنية‬‫تطوير تطبيقات آمنة‪ .‬تنصح أواسب بمشروع واجهات التطبيقات البرمجية األمنية‬‫المعيارية‬‫للمنشآت كنموذج لواجهات التطبيقات البرمجية ‪ APIs‬الالزمة إلنتاج تطبيقات ويب آمنة‪.‬‬‫أيضا يقدم بعض المكتبات واألدوات التي قد تجدها ذات قيمة ‪ ،‬مثل التحقق من صحة‬‫أدوات التحكم‪.‬‬‫يمكنك استخدام )‪ OWASP Software Assurance Maturity Model (SAMM‬لتحسين‬‫دورة حياة التطوير اآلمنة العملية عند إنشاء واجهات برمجة التطبيقات ‪ .API‬تتوفر العديد من مشاريع ‪OWASP‬‬‫األخرى لمساعدتك خالل مراحل تطوير ‪ API‬المختلفة ‪ ،‬على سبيل المثال ‪ ،‬مشروع‬‫مراجعة كود ‪.OWASP‬‬

‫ما التالي لمطوري الممارسات االمنية في التطبيقات؟‬‫نظر ا ألهميتها في بناء التطبيقات الحديثة ‪ ،‬فإن بناء واجهات برمجة آمنة أمر في غاية األهمية ‪ ،‬ويجب أن يكون األمن‬‫ً‬‫جزءًا من دورة حياة التطوير بأكملها‪ .‬لم تعد اختبارات االختراق السنوية كافية‪.‬‬‫يجب أن تنضم ‪ DevSecOps‬إلى جهود التطوير ‪ ،‬مما يسهل اختبار األمان المستمر عبر دورة حياة تطوير البرامج‬‫بأكملها‪ .‬هدفهم هو تعزيز طريق التطوير بأتمتة األمان ‪ ،‬ودون التأثير على سرعة التطوير‪.‬‬‫في حالة تود االطالع والمراجعة ‪ ،‬راجع‪https://www.devsecops.org :‬‬‫فهم نماذج التهديد‬‫فهم دورة حياة التطبيقات‬‫استراتيجيات االختبار‬‫تأتي أولويات االختبار من نماذج التهديد المتوقعة‪ .‬إذا لم يكن لديك واحد ‪ ،‬ففكر‬‫في استخدام )‪، OWASP Application Security Verification Standard (ASVS‬‬‫ودليل اختبار ‪ OWASP‬كمدخل‪ .‬قد يساعد في رفع مستوى الوعي لفريق‬‫التطوير‪.‬‬‫قم باالنضمام الى فريق تطوير البرمجيات لفهم دورة حياة البرامج‪ .‬حيث ان‬‫مساهمتك في اختبار االمان بشكل مستمر ومتوافق مع االدوات والعمليات‬‫واالجراءات التي يتفق عليها الجميع وبشكل سلسل‪.‬‬‫ال يجب ان تؤثر اعمالك على سرعة وتيرة التطوير بل يجب أن تختار بحكمة‬‫األسلوب األفضل (البسيط واألسرع واألكثر دقة) للتحقق من متطلبات األمان‪.‬‬‫يمكن أن يكون إطار ‪ OWASP‬للمعرفة األمنية ومعيار ‪ OWASP‬للتحقق من أمان‬‫التطبيقات مصادر جيدة لمتطلبات األمان الوظيفية وغير الوظيفية‪ .‬هناك مصادر‬‫أخرى للمشاريع واألدوات المشابهة لتلك التي يقدمها مجتمع ‪DevSecOps‬‬‫أنت حلقة الوصل بين المطورين وفرق العمليات‪ .‬لتحقيق التغطية بالشكل‬‫ضا على‬‫المطلوب ‪ ،‬ال يجب أن تركز فقط على آلية عملها فقط ‪ ،‬ولكن أي ً‬‫تحقيق التغطية والدقة المطلوبة‬‫التنسيق بشكل سليم‪ .‬وذلك من خالل العمل بالقرب من فرق التطوير‬‫والعمليات من البداية حتى تتمكن من استغالل الجهود المبذولة‪ .‬يجب أن تهدف‬‫إلى حالة دائمة من تحقيق معايير األمان بشكل أساسي ومستمر‪.‬‬‫ايصال النتائج بشكل واضح‬‫قم بالمشاركة في صنع قيمة مع اقل اختالف مع فرق العمل‪ .‬وقم بتسليم النتائج‬‫في الوقت المناسب ‪ ،‬باستخدام األدوات المتاحة من قبل الفريق‪ ،‬انضم إلى‬‫فريق التطوير لمعالجة النتائج والمخرجات وقم بشرح ووصف نقاط الضعف‬‫بشكل واضح جدا ً وكيف سيتم إساءة استخدامها وقم بذكر بعض السيناريوهات‬‫الحقيقة الستغاللها ‪.‬‬

‫المنهجية والبيانات‬‫نظرة عامة‬‫نظر ا ألن صناعة برامج آمنة لم تركز بشكل خاص على أحدث بنية وهيكلة للتطبيقات‪ ،‬حيث تلعب واجهات برمجة‬‫ً‬‫م ا‪ ،‬فإن تجميع قائمة بأكثر عشرة مخاطر لواجهة برمجة التطبيقات (‪ ،)API‬استنادًا إلى استفتاء‬
‫مه‬
‫ا‬
‫دور‬
‫التطبيقات‬‫ً‬‫ً‬‫عام‪ ،‬كانت من أصعب المهام‪ .‬على الرغم من عدم وجود مصادر عامة‪ ،‬إال أن قائمة العشرة مخاطر ال تزال تستند‬‫على االستفتاء‪ ،‬ومساهمات خبراء األمن المعلوماتي‪ ،‬والمناقشات المفتوحة مع مجتمع األمنى‪.‬‬‫المنهجية‬‫في المرحلة األولى‪ ،‬تم جمع البيانات المتاحة من المصادر العامة وحول الحوادث األمنية لواجهات برمجة التطبيقات‬‫‪ API‬ومراجعتها وتصنيفها من قبل مجموعة من خبراء األمن‪ .‬وكما تم جمع هذه البيانات من منصات مكافآت الثغرات‬‫وقواعد بيانات الثغرات األمنية‪ ،‬في إطار زمني مدته عام واحد‪ .‬تم استخدام تلك البيانات ألغراض إحصائية‪.‬‬‫في المرحلة التالية ‪ ،‬ط ُلب من الممارسين األمنيين ذوي الخبرة في اختبار االختراق حصر اكثر عشر مخاطر امنية‬‫خاصة بهم‪.‬‬‫تم استخدام منهجية ‪OWASP‬لتصنيف المخاطر إلجراء تحليل المخاطر‪ .‬تمت مناقشة النتائج ومراجعتها بين‬‫الممارسين األمنيين‪ .‬للحصول على رأي ‪ OWASP‬حول هذه االمور ‪ ،‬يرجى الرجوع إلى قسم مخاطر أمان ‪.API‬‬‫نتجت المسودة األولى من ‪ OWASP API Security Top 10 2019‬عن توافق بين النتائج اإلحصائية من المرحلة األولى‬‫وقوائم الممارسين األمنيين‪ .‬ثم تم تقديم هذه المسودة لتقديرها ومراجعتها من قبل مجموعة أخرى من ممارسي‬‫األمن ‪ ،‬من ذوي الخبرة ذات الصلة في مجاالت أمان واجهة برمجة التطبيقات‪.‬‬‫تم تقديم ‪ OWASP API Security Top 10 2019‬ألول مرة في حدث ‪ OWASP Global AppSec‬في (مايو ‪ .)2019‬منذ ذلك‬‫حا على ‪ GitHub‬للمناقشة العامة والمساهمات‪.‬‬‫الحين ‪ ،‬كان متا ً‬‫قائمة المساهمين متاحة في قسم الشكر والتقدير‪.‬‬‫اإلقرار‬‫المساهمين في صناعة المحتوى‬‫ وكذلك المشاركين من خالل وسائل ووسائط اخرى وهم‬GitHub ‫نشكر جميع المشاركين بشكل عام من خالل منصة‬:007divyachawla•
Abid Khan•
Adam Fisher•
anotherik•bkimminich•caseysoftware•
Chris Westphal•
dsopas•DSotnikov•
emilva•ErezYalon•
flascelles•
Guillaume Benats•
IgorSasovets•
Inonshk•
JonnySchnittger•
jmanico•jmdx•
Keith Casey•kozmic•LauraRosePorter•
Matthieu Estrade•nathanawmk•
PauloASilva•
pentagramz•
philippederyck•
pleothaud•
r00ter•Raj kumar•
Sagar Popat•
Stephen Gates•
thomaskonrad•xycloops123•: ‫وكذلك المترجمين للغة العربية وهم‬‫ ثامر الشمري‬-‫ محمد السحيمي‬-‫ مالك الدوسري‬-‫ مصطفى االقصم‬-‫ صبري صالح‬-0xMohammed -‫ فهد الدريبي‬-