Skip to content

Update 0xa1-broken-object-level-authorization.md #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
0xHasanM wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update 0xa1-broken-object-level-authorization.md #13

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions 2019/ar/src/0xa1-broken-object-level-authorization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
<td> الانتشار : 3 قابلية الاكتشاف : 2 </td>
<td> التأثر التقني و تأثر الاعمال: 3 </td>
</tr>
<td> يستطيع المهاجم استغلال نقاط الضعف في مصادر البيانات Endpoint المتأثرة بخلل في الصلاحيات من خلال التلاعب او التغير بالمعرف الفريد عند ارسال الطلبات. قد يؤدي كذلك الى الوصول غير المصرح به الى البيانات الحساسة. وتعتبر خلل تفويض الصلاحيات مشكلة شائعة جداً في التطبيقات بسبب عدم إمكانية الخوادم من تتبع العمليات التي يقوم بها المستخدم بشكل كامل. وحيث انه يعتمد بشكل كامل على إيصال كل معرف فريد لمصدر البيانات الذي يطلب منه. </td>
<td> يستطيع المهاجم استغلال نقاط الضعف في مصادر البيانات Endpoint المتأثرة بخلل في الصلاحيات من خلال التلاعب او التغيير بالمعرف الفريد عند ارسال الطلبات. قد يؤدي كذلك الى الوصول غير المصرح به الى البيانات الحساسة. ويعتبر خلل تفويض الصلاحيات مشكلة شائعة جداً في التطبيقات بسبب عدم إمكانية الخوادم من تتبع العمليات التي يقوم بها المستخدم بشكل كامل. وحيث انه يعتمد بشكل كامل على إيصال كل معرف فريد لمصدر البيانات الذي يطلب منه. </td>
<td> يعتبر هذا الهجوم هو الأكثر شيوعاً على واجهات برمجة التطبيقات API. حيث ان استخدام مثل هذه الاليات شائعة جداً في التطبيقات الحديثة وواسعة الانتشار. حتى وان كانت صلاحيات الوصول في البنية التحتية للتطبيق مبنيه بشكل سليم، فقد ينسى المطورون استخدام تلك الصلاحيات في الوصول الى البيانات الحساسة وقد لا يتم اكتشاف نقاط الضعف المبنية على خلل صلاحيات الوصول من خلال عمليات المسح للبحث عن الثغرات بشكل آلي. </td>
<td> يمكن أن يؤدي الوصول غير المصرح به إلى الكشف عن البيانات لأطراف غير مصرح لها أو فقدان البيانات أو التلاعب بها وكذلك يمكن أن يؤدي الوصول غير المصرح به إلى إلى الاستيلاء الكامل على الحساب. </td>
</tr>
Expand All @@ -20,15 +20,15 @@
<h3 dir='rtl' align='right'>هل أنا معرض لهذه الثغرة؟</h3>

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


<h3 dir='rtl' align='right'> امثلة على سيناريوهات الهجوم: </h3>

<h4 dir='rtl' align='right'>السيناريو الاول: </h4>

<p dir='rtl' align='right'>
توفر منصة التجارة الالكترونية مواقع عبر الانترنت (عبارة عن متاجر الالكترونية) خدمة مصادر الربح الخاصة بالمتاجر المستضاف على المنصة، حيث يستطيع المهاجم من خلال عرض مصدر الصفحة معرفة API الذي قام بجلب تلك المعلومات ومعرفة مصدرها على سبيل المثال : `/shops/{shopName}/revenue_data.json` ومن خلال تلك الطريقة يستطيع المهاجم من الحصول على بيانات الربح لجميع المتاجر المتسضافة في المنصة من خلال تغير {shopName} في عنوان URL بطريقة غير مصرح بها.
توفر منصة التجارة الالكترونية مواقع عبر الانترنت (عبارة عن متاجر إلكترونية) خدمة مصادر الربح الخاصة بالمتاجر المستضاف على المنصة، حيث يستطيع المهاجم من خلال عرض مصدر الصفحة معرفة API الذي قام بجلب تلك المعلومات ومعرفة مصدرها على سبيل المثال : `/shops/{shopName}/revenue_data.json` ومن خلال تلك الطريقة يستطيع المهاجم من الحصول على بيانات الربح لجميع المتاجر المتسضافة في المنصة من خلال تغير {shopName} في عنوان URL بطريقة غير مصرح بها.

<h4 dir='rtl' align='right'>السيناريو الثاني : </h4>

Expand All @@ -37,10 +37,10 @@

<h4 dir='rtl' align='right'>كيف أمنع هذه الثغرة؟ </h4>

<p dir='rtl' align='right'>▪️ الاعتماد على سياسة و آلية تخويل لصلاحيات تعتمد على سياسة الاستخدام المقبول والتسلسل الهرمي السهل الواضح.
<p dir='rtl' align='right'>▪️ استخدام آلية لتحقق من صلاحيات المستخدم الذي قام بتسجيل الدخول وهل لديه الحق في تنفيذ الإجراءات على السجلات في كل سجل على حدة وبشكل مستقل.
<p dir='rtl' align='right'>▪️ يفضل استخدام قيم عشوائية وغير قابلة لتخمين في استخدام GUIDs في السجلات
<p dir='rtl' align='right'>▪️ يفضل كتابة معايير لاختبار مدى نضج التفويض والصلاحيات وفي حال وجود أي ثغرة يفضل عدم استخدمها حتى تتخطى الاختبارات والمعايير المتفق عليها.
<p dir='rtl' align='right'>▪️ الاعتماد على سياسة و آلية تحويل لصلاحيات تعتمد على سياسة الاستخدام المقبول والتسلسل الهرمي السهل الواضح.
<p dir='rtl' align='right'>▪️ استخدام آلية للتحقق من صلاحيات المستخدم الذي قام بتسجيل الدخول وهل لديه الحق في تنفيذ الإجراءات على السجلات في كل سجل على حدة وبشكل مستقل.
<p dir='rtl' align='right'>▪️ يفضل استخدام قيم عشوائية وغير قابلة للتخمين في استخدام GUIDs في السجلات
<p dir='rtl' align='right'>▪️ يفضل كتابة معايير لاختبار مدى نضج التفويض والصلاحيات وفي حال القيام باى تغيير يؤدى الى ثغرة يفضل عدم القيام به حتى تتخطى الاختبارات والمعايير المتفق عليها.

<h4 dir='rtl' align='right'>المراجع : </h4>
<h4 dir='rtl' align='right'>المصادر الخارجية : </h4>
Expand Down