API2:2019 خلل في صلاحيات المستخدم
| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
|---|---|---|
| خصائص API : قابلية الاستغلال 3 | الانتشار 2 : قابلية الاكتشاف 2 | التأثر التقني 3 : تأثر الأعمال |
| المصادقة في واجهات برمجة التطبيقات API هي آلية معقدة وصعبة الفهم وقد يكون لدى مهندسي البرمجيات ومهندس امن المعلومات بعض المفاهيم الخاطئة حول حدود المصادقة وكيفية تنفيذها بشكل صحيح. بالإضافة إلى ذلك، تعد آلية المصادقة هدفًا سهلاً للمهاجمين ، نظرًا لأنها متاحة للجميع. تجعل هاتان النقطتان مكون المصادقة عرضة للعديد من عمليات الاستغلال. | هناك مسألتان فرعيتان: 1. محدودية آليات الحماية: يجب التعامل مع مصادر البيانات الخاصة بواجهات برمجة التطبيقات API والمسؤولة عن المصادقة بشكل مختلف عن المصادر الاخرى وتأمين طبقات إضافية من الحماية 2. سوء تنفيذ الآلية: يتم استخدام / تنفيذ الآلية دون مراعاة طرق الاستغلال الهجوم، أو أنها تبني بشكل غير صحيح (على سبيل المثال، قد لا تتناسب آلية المصادقة المصممة لأجهزة إنترنت الأشياء مع تطبيقات الويب). | يمكن للمهاجمين التحكم في حسابات المستخدمين الآخرين في النظام ، وقراءة بياناتهم الشخصية ، وتنفيذ إجراءات حساسة نيابة عنهم ، مثل المعاملات المالية وإرسال الرسائل الشخصية. |
هل أنا معرض لهذه الثغرة؟
مصادر البيانات وآلية عملها والاصول الخاصة بها تحتاج إلى الحماية. حيث يجب معاملة "نسيت كلمة المرور / إعادة تعيين كلمة المرور" بنفس طريقة آليات المصادقة.
يكون API معرض للخطر اذا كان: * اذا كان لدى المهاجم قائمة متكاملة من اسماء المستخدمين وكلمات المرور تم الحصول عليها من اختراق او تسريب سابق * عند قيام المهاجم بهجمات كسر كلمة المرور وعدم استخدام آلية تحقق اخرى من المستخدم مثل Captcha. * كلمات المرور الضعيفة * ارسال المعلومات الحساسة او كلمات المرور من خلال URL. * عدم التحقق بالشكل الصحيح من عمليات المصادقة * الموافقة على استخدام المصادقة الغير موقعه او الموقع بشكل غير امن ("alg":"none") او عدم التحقق من تاريخ انتهاء المصادقة. * استخدام البيانات غير المشفرة في عمليات تسجيل الدخول او عدم حفظ الارقام السرية بشكل مشفر * استخدام مفاتيح تشفير ضعيفة.
امثلة على سيناريوهات الهجوم
السيناريو الاول
في حال قام المهاجم بمحاولة الدخول بحسابات متعددة والتي تم الحصول عليها من تسريب للبيانات والتي يجب ان نقوم بوضع آلية للحماية من هجمات الدخول المتعدد بحسابات صحيح في وقت قصير ومحدود.
السيناريو الثاني
في حال قام المهاجم بمحاولة استعاد كلمة المرور من خلال ارسال طلب POST الى /api/system/verification-codes وذلك باستخدام اسم المستخدم فقط لتحقق من استعادة كلمة المرور. حيث يقوم التطبيق بإرسال رسالة نصية لهاتف الضحية مع آلية المصادقة الجديدة والمكونة من 6 ارقام. وحيث ان API لم يقم بوضع حد اعلى لطلبات المصادقة سيقوم المهاجم بتنفيذ جميع الاحتماليات وذلك بالتخمين على آلية المصادقة التي تم ارسالها الى هاتف الضحية وذلك بإرسال طلبات متعددة الى /api/system/verification-codes/{smsToken} لتحقق من مصدر البيانات في حال كان احد عمليات التخمين كانت صحيحة.
كيف أمنع هذه الثغرة؟
- يجب ان تكون على دراية بجميع طرق و آليات المصادقة التي تتم من خلال ( الهواتف /تطبيقات الويب /المصادقة الواحدة/إلخ)
- قم بالتعاون مع مهندس التطبيقات لمعرفة ماهي الآليات المفقودة عند عمليات المصادقة
- اقرأ عن آليات المصادقة الخاصة بك. تأكد من أنك تفهم ماذا وكيف يتم استخدامها ويجب التنويه على ان برتوكول. OAuth ليس للمصادقة ، ولا مفاتيح واجهة رمجة التطبيقات API تستخدم للمصادقة.
- لا تقم بإختراع واعادة صناعة آليات مصادقة جديدة بل اتبع افضل الامتثالات والمعايير المتعارف عليها.
- يجب التعامل مع مصادر البيانات لاستعادة كلمة المرور ونسيت كلمة المرور بشكل صحيح وذلك من خلال وضع ضوابط و آليات للحد من هجمات كسر كلمات المرور
- الاستفادة من وسائل الحماية كتعطيل الحساب بعد عدد محاولات غير ناجحة من عمليات تسجيل الدخول.
- قم باستخدام نموذج OWASP Authentication Cheatsheet
- في حال توفر التحقق الثنائي قم باستخدامه.
- قم بتنصيب التقنيات والطرق والاليات لرصد هجمات كسر كلمات المرور او محاولة استغلال الحسابات المسربة وقم بوضع آلية محددة لتقليل معدل المصادقة التي تستخدم API.
- قم باستخدام آلية ايقاف الحسابات او Captcha وذلك لتقليل ومنع هجمات كسر كلمات المرور وقم بتنصيب تقنية عدم اتاحة استخدام كلمات المرور الضعيفة.
- يجب عدم استخدام مفاتيح الـ API لمصداقة المستخدم, بل تستخدم لتصديق التطبيقات والمشاريع مع الـ API.