التفويض المعطّل

تثبت المصادقة هويتك، بينما يحدد التفويض ما يُسمح لك بفعله.

يعني التفويض المعطّل أن النظام يسمح للمستخدمين بفعل أشياء أو رؤية أشياء لا ينبغي لهم فعلها أو رؤيتها.

يشير BOLA إلى التفويض المعطّل على مستوى الكائن.

وهو أخطر مخاطر API: تتحقق API من أنك سجّلت الدخول، لكنها لا تتحقق من أن الكائن المحدد الذي تطلبه يخصك فعلًا.

افترض أن حسابك هو المستخدم 100.

إذا غيّرت المعرّف واستمر الخادم في الاستجابة، فقد قرأت طلبات شخص آخر. هذا هو BOLA.

غالبًا ما يثق المطورون بالمعرّف الموجود في الطلب.

وينسون التحقق من أن المستخدم الذي سجّل الدخول يمتلك ذلك الكائن فعلًا. والحل هو إجراء فحص للملكية في كل طلب.

هناك خلل آخر يُسمى BFLA: التفويض المعطّل على مستوى الوظيفة.

يستدعي المستخدم العادي إجراءً مخصصًا للمشرف وينجح ذلك، لأن نقطة النهاية لا تتحقق من دور المستخدم.

تأمل مسارًا مخصصًا للمشرف:

إذا تمكن مستخدم عادي من استدعائه بنجاح، فقد أخفقت API في فرض الوصول المستند إلى الأدوار.

تربط بعض واجهات API حقول الطلب مباشرةً بسجل دون إجراء التحقق اللازم.

قد يضيف المستخدم حقلًا مثل role=admin إلى تحديث الملف الشخصي، فيرفع امتيازاته سرًا.

لا تعتمد مطلقًا على العميل لإخفاء الأزرار أو الحقول.

يجب على الخادم فرض كل قرار متعلق بالتفويض، لأن المهاجمين يرسلون الطلبات مباشرةً، متجاوزين واجهة المستخدم بالكامل.

تجعل المعرّفات المتسلسلة استغلال BOLA سهلًا.

لا يؤدي استخدام معرّفات عشوائية مثل UUID إلى الاستغناء عن فحوصات التفويض، لكنه يلغي هجوم تخمين الرقم التالي البسيط.

تقوم API الآمنة بالرفض افتراضيًا.

لا يُسمح بالوصول إلا عندما تمنحه قاعدة صريحة. وبهذه الطريقة، يؤدي نسيان فحص ما إلى إغلاق الوصول بدلًا من تسريب البيانات.

يصعب اكتشاف أخطاء التفويض، لذا اختبرها عمدًا.

حاول الوصول إلى بيانات مستخدم آخر باستخدام الرمز المميز الخاص بك. إذا نجح ذلك، فقد اكتشفت خللًا خطيرًا يجب إصلاحه.

تؤكد API أنك سجّلت الدخول، لكنها تعيد سجل مستخدم آخر عند تغيير المعرّف. ما الخلل الموجود هنا؟

يسمح التفويض المعطّل للمستخدمين بالوصول إلى ما لا ينبغي لهم الوصول إليه. انتبه إلى BOLA وBFLA والإسناد الشامل.

افرض فحوصات الملكية والأدوار على الخادم، وارفض الوصول افتراضيًا، واختبر التفويض عمدًا.