Update 0xa5-broken-function-level-authorization.md

Author: 0xHasanM

2019/ar/src/0xa5-broken-function-level-authorization.md

@@ -11,7 +11,7 @@
     <td> التأثر التقني و تأثر الاعمال: 2 </td>
   </tr> 
      <td> ان عملية استغلال هذه الثغرة بسيط نسيباً بحيث يستطيع المهاجم ارسال طلب غير ضار من خلال واجهة برمجة التطبيقات API الى مصادر البيانات التي من الغير مصرح له بالاطلاع عليها. وقد تكون تلك المصادر متاحة للمسخدمين المجهولين او المستخدم الذي لا يملك صلاحيات عالية. وحيث ان من السهل اكتشاف مثل تلك الثغرات من خلال معرفة سلوك الطلبات والياتها المستخدمة وطرق طلبها والردود المتوقعة من كل طلب وقد يتم استغلالها ببساطة من خلال استبدال طلب GET  بـ PUT او تغير صلاحيات المستخدم من "User " الى "Admin".   </td>
-    <td> عادة ما يتم تحديد صلاحيات الوصول للموارد من خلال الاعدادات. وفي بعض الأحيان على مستوى الاكواد البرمجية، ان عملية تنصيب طرق التحقق بالشكل الصحيح قد تكون في بعض الأحيان عملية معقدة. حيث ان معظم التطبيقات الحديثة تحتوي على مختلف الصلاحيات والمجموعات بتسلسل هرمي معقد بعض الشي. </td>
+    <td> عادة ما يتم تحديد صلاحيات الوصول للموارد من خلال الاعدادات. وفي بعض الأحيان على مستوى الاكواد البرمجية، ان عملية تنصيب طرق التحقق بالشكل الصحيح قد تكون في بعض الأحيان عملية معقدة. حيث ان معظم التطبيقات الحديثة تحتوي على مختلف الصلاحيات والمجموعات بتسلسل هرمي معقد بعض الشئ. </td>
     <td> بعض آليات العمل قد تسمح للمهاجم في الاستفادة والوصول والاطلاع الغير مصرح به، او حصوله على صلاحيات إدارية تمكنه من التحكم والسيطرة. </td>    
   </tr>
   </table>    
@@ -22,7 +22,7 @@
 <p dir='rtl' align='right'> أفضل طريقة للعثور على مشكلات وخلل تفويض مستوى الصلاحيات والمصادقة هي إجراء تحليل عميق لآلية التفويض ، مع مراعاة التسلسل الهرمي للمستخدم ، والأدوار أو المجموعات المختلفة في التطبيق ، وطرح الأسئلة التالية:
 
 <p dir='rtl' align='right'>▪️ هل يستطيع المستخدم العادي الوصول الى مصادر صلاحيات المدراء ؟
-<p dir='rtl' align='right'>▪️ هل يستطيع المستخدم التعديل او التعين او المسح لمصادر البيانات عند تغير طريقة الطلب للبروتوكول على سبيل المثال من GET الى DELETE ؟
+<p dir='rtl' align='right'>▪️ هل يستطيع المستخدم تعديل او تعيين او مسح مصادر البيانات عند تغير طريقة الطلب للبروتوكول على سبيل المثال من GET الى DELETE ؟
 <p dir='rtl' align='right'>▪️  هل يستطيع المستخدم في مجموعة أ من الوصول الى مصادر المجموعة ب من خلال تخمين مصدر تلك المجموعة /api/v1/users/export_all 
 
 <p dir='rtl' align='right'> لا تقم بوضع وتقسيم الصلاحيات ما بين الصلاحيات المعتادة والصلاحيات الادارية من خلال مسار URL.
@@ -34,9 +34,9 @@
 
 <p dir='rtl' align='right'> يقوم التطبيق فقط بالسماح للمستخدمين المدعوين بالتسجيل، حيث يقوم التطبيق بطلب API الخاص من خلال طلب GET  على سبيل المثال المسار التالي " /api/invites/{invite_guid}" ويأتي الرد من الخادم والذي يحتوي على ملف JSON مع تفاصيل الدعوة، وكذلك تفاصيل المستخدمين و الصلاحيات والبريد الالكتروني.
 
-<p dir='rtl' align='right'> يقوم المهاجم بتكرار الطلبات ومحاولة التلاعب والتعديل في طريقة الطلب من مصدر البيانات  من GET  الى POST  مع المسار التالي " /api/invites/new" حيث ان هذا المسار مسموح بالوصول له فقط لأصحاب الصلاحيات الإدارية بواسطة صفحة الإدارة والتي من الوضح عدم تطبيق مستوى المصادقة والتفويض على مستوى الصلاحية.
+<p dir='rtl' align='right'> يقوم المهاجم بتكرار الطلبات ومحاولة التلاعب والتعديل في طريقة الطلب من مصدر البيانات  من GET  الى POST  مع المسار التالي " /api/invites/new" حيث ان هذا المسار مسموح بالوصول له فقط لأصحاب الصلاحيات الإدارية بواسطة صفحة الإدارة والتي من الواضح عدم تطبيق مستوى المصادقة والتفويض على مستوى الصلاحية.
 
-<p dir='rtl' align='right'> المهاجم قام باستغلال الخطأ من خلال ارسال طلب دعوة لنفسة ومن ثم قام بإنشاء حساب بصلاحيات مرتفعة.
+<p dir='rtl' align='right'> المهاجم قام باستغلال الخطأ من خلال ارسال طلب دعوة لنفسه ومن ثم قام بإنشاء حساب بصلاحيات مرتفعة.
 
 ```
 POST /api/invites/new
@@ -46,16 +46,16 @@ POST /api/invites/new
 
 <h4 dir='rtl' align='right'>السيناريو الثاني : </h4>
 
-<p dir='rtl' align='right'> تحتوي واجهة برمجة التطبيقات API على صلاحيات وصول الى مصادر البيانات والمحددة فقط لمدراء النظام من خلال الطلب باستخدام GET  للمسار التالي /api/admin/v1/users/all حيث ان مصدر البيانات عند ارجاع البيانات لا بتأكد من صلاحيات من قام بطلبها او الصلاحيات المخولة له مما يمكن المهاجم من تخمين المسارات الخاصة بمصادر البيانات لاستعراض بيانات حساسة غير مصرح له بالوصول لها.
+<p dir='rtl' align='right'> تحتوي واجهة برمجة التطبيقات API على صلاحيات وصول الى مصادر البيانات والمحددة فقط لمدراء النظام من خلال الطلب باستخدام GET  للمسار التالي /api/admin/v1/users/all حيث ان مصدر البيانات عند ارجاع البيانات لا تقوم بالتأكد من صلاحيات من قام بطلبها او الصلاحيات المخولة له مما يمكن المهاجم من تخمين المسارات الخاصة بمصادر البيانات لاستعراض بيانات حساسة غير مصرح له بالوصول لها.
 
 <h4 dir='rtl' align='right'>كيف أمنع هذه الثغرة؟ </h4>
 
-<p dir='rtl' align='right'>يجب أن يحتوي التطبيق الخاص بك على وحدة تفويض متسقة وسهلة التحليل يتم استدعاؤها وظائف تطبيقك.  في كثير من الأحيان يتم توفير هذه الحماية بواسطة مكون أو أكثر خارج الاكواد البرمجية الخاصة بالتطبيق.
+<p dir='rtl' align='right'>يجب أن يحتوي التطبيق الخاص بك على وحدة تفويض متسقة وسهلة التحليل يتم استدعاؤها من خلال جميع وظائف تطبيقك.  في كثير من الأحيان يتم توفير هذه الحماية بواسطة مكون أو أكثر خارج الاكواد البرمجية الخاصة بالتطبيق.
 
 <p dir='rtl' align='right'>▪️ يجب منع الوصول لجميع المصادر بشكل افتراضي وبعد ذلك يتم السماح والاستثناء للمصادر لكل مصدر على حدة ولكل صلاحية بشكل مستقل.
 <p dir='rtl' align='right'>▪️ قم بمراجعة صلاحيات المصادقة والتفويض الخاص بالآليات العمل، مع مراعاة منطق التسلسل الهرمي وصلاحيات المجموعات والصلاحيات على مستوى المستخدمين.
 <p dir='rtl' align='right'>▪️ التأكد من ان صلاحيات التحكم الادارية مبنية بشكل سليم ومرتبطة بصلاحيات المصادقة والتفويض لكل مجموعة او مستخدم او صلاحية.
-<p dir='rtl' align='right'>▪️ التأكد من ان الاوامر والصلاحيات الادارية مبنية بشكل محوكم وهناك وحدة تحكم تقوم بفحص الصلاحيات والتفويض لكل مستخدم بناء على المجموعة التي تم تعينه بداخلها.
+<p dir='rtl' align='right'>▪️ التأكد من ان الاوامر والصلاحيات الادارية مبنية بشكل محوكم وهناك وحدة تحكم تقوم بفحص الصلاحيات والتفويض لكل مستخدم بناء على المجموعة التي تم تعيينه بداخلها.