ثغرة كسر مصادقة المستخدم في تطبيقات الـ API - التحديات وتقنيات الحماية المتقدمة

مقدمة

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

لذلك اكمالا لسلسة OWASP API TOP 10 سنقوم بشرح ألايات نظام مصادقة المستخدم والثغرة الثانية من ثغرات واجهات التطبيقات (API:2 (Broken User Authentication لذلك نرجو من جميع القراء ربط الأحزمة لنأخذكم فى جولة شيقة لفهم كل مايخص الثغرة الى اساليب الحماية لذلك وجب التنبيه استعدوا للأقلاع .....

ما هو من الأساس نظام المصادقة | User Authentication ؟

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

يتم استخدام مصادقة المستخدم لتحقيق العديد من الأهداف، بما في ذلك:

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

تتضمن أساليب مصادقة المستخدم عادةً استخدام أسماء المستخدم وكلمات المرور، أو طرق أخرى مثل الرموز المميزة (الرمز المكون من أرقام يرسل عبر الرسائل القصيرة)، أو استخدام بصمة الأصبع أو التعرف على الوجه كأدوات للتحقق من هوية المستخدم. تعتبر مصادقة المستخدم أحد العناصر الأساسية في تأمين النظام ومنع وصول الأشخاص غير المصرح لهم.

ما هو كسر نظام مصادقة المستخدم | Broken User Authentication ؟

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

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

كيف يحدث هذا ؟

هناك العديد من الجوانب المتعلقة بالثغرات الأمنية حول أنظمة المصادقة هذه. الأول هو أن تصميم نظام المصادفة قد لا يكون مقيدًا بدرجة كافية في حالة وجود سلسلة من محاولات المصادقة الفاشلة. يتضمن ذلك الافتقار إلى تنفيذ اختبارات CAPTCHA ، او عدم وجود طرق مصادقة متعددة العوامل (2FA) أو السماح بكلمات المرور التي تم تسريبها مسبقًا (مثل في موقع haveibeenpwned) ، او إرسال معلومات حساسة من خلال قنوات غير مشفرة و يحتمل أن يكون في العرض العادي (على سبيل المثال في عناوين URL) ، أو باستخدام مفاتيح تشفير ضعيفة. من الممكن أيضًا أن تحتوي آلية المصادقة على هذه الميزات ، ولكن تم تنفيذها بشكل غير صحيح ، مما يوفر مساحة للتحايل أو الهجوم على نظام المصادقة.

"غالبًا ما يتم تنفيذ آليات المصادقة بشكل غير صحيح ، مما يسمح للمهاجمين بأختراق رموز المصادقة المميزة أو استغلال عيوب التنفيذ لتحمل هويات مستخدمين آخرين بشكل مؤقت أو دائم. او المساس بقدرة النظام على تحديد العميل / المستخدم ، يعرض أمان واجهة برمجة التطبيقات  API بشكل عام للخطر.

تقرير OWASP API Security Top 10 لعام 2019"

كيف يشكل هذا خطرا على انظمة الـ API ؟

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

حتى عندما تتطلب واجهات برمجة التطبيقات المصادقة ، فإن الثقة في هوية النظام أو الشخص الذي يستخدم واجهة برمجة التطبيقات أمر ضروري لتوفير المستوى المناسب من الوصول إلى المستخدمين المعروف باسم الصلاحيات. فإذا كان بإمكان المهاجمين الوصول الى هوية مستخدم لنظام الـ API ، فإنهم يتمكنوا أيضًا من لعب دور هذا المستخدم والوصول إليه مما يسمح بالوصول إلى جميع بيانات واجهة برمجة التطبيقات.

كيف يحدث هذا (من واقع العمل) ؟

لتوضيح سيناريو الهجوم بشكل افضل وفهم توابع الثغرة سنذكر بعض الأمثلة الحية من واقع العمل.

[*] على سبيل المثال : أحمد يريد ان يقوم بعملية تسجيل دخول عادية كمثل التى تحدث يوميا على API فسيقوم بأرسال طلب به بياناتة الى الخادم المخصص بالرد على طلبات المستخدمين.

Request

POST https://example.com/api/v2/customer/get_token HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: application/json

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin


{

  "username": “Ahmed”,

  “password”: “#lubMv^cr25]UUJ/_%DkuxU|[”
 
}

[*] سيقوم السيرفر بالرد بـ :

Response

HTTP/1.1 200

Server: openresty/1.17.8.2

Date: Fri, 23 May 2023 01:25:30 GMT

Content-Type: application/json

Connection: keep-alive

Vary: Origin

Vary: Access-Control-Request-Method

Vary: Access-Control-Request-Headers

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

X-Frame-Options: DENY


{

  "token": “eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZEBleGFtcGxlLmNvbSIsImlhdCI6MTY1ODQ2MDMzMCwiZXhwIjoxNjU4NTQ2NzMwfQ.m0ha0L89xuLpLlLlybcaD2SfKp23BZfe_Hjjs-PprCN2sDvxpmWAcemN5yOq-nhx78Iu8EzLIJbqqc1d-q10UA”

}

[*] قد نجح أحمد فى تسجيل الدخول ولكن يريد ان يختبر نظام مصادقة المستخدم لذلك قام بكتابة بعض اسماء المستخدمين وبعض كلمات المرور المسربة على الأنترنت لمحاولة الحصول على تسجيل دخول ناجح لمستخدمين أخرين, فيقوم بالتعديل فى طلب الدخول $Username: $ahmed وكلمة المرور  Password: $2512121$ لاحظ ان علامة $ فى استخدامك للطلب مع استخدامك لبرامج اختبار التطبيقات ستتمكن من ارسال العديد من الطلبات فى ثوانى معدودة حتى تحصل على الـ Token الصحيح الذى يؤدى الى عملية تسجيل الدخول لمستخدمين اخرين.

Request

POST https://example.com/api/v2/customer/get_token HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Accept: */*

Accept-Language: en-US,en;q=0.5

Content-Type: application/json

Connection: keep-alive

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-origin


{

  "username": “kareem”,

  “password”: “2512121”

}

[*] بالنظر إلى الرد ، من الممكن معرفة متى كان الطلب ناجحًا. مع كل تخمين ناجح لبيانات الاعتماد ، أصبح لدى احمد الآن إمكانية الوصول إلى واجهة برمجة التطبيقات API كما لو كان ذلك الشخص الأخر. نظرًا لأن الحصول على قائمة كبيرة من بيانات الاعتماد المسربة سابقًا أمر سهل للمهاجمين ، يمكن لأحمد إجراء ملايين التخمينات والحصول على العديد من الرموز المميزة الصالحة للمستخدم لاستخدامها مع مزيد من الهجمات ضد واجهة برمجة التطبيقات.

ما هو الخطأ الذى يوجد فى الـ API الخاص بالمثال السابق ؟

1- عدم وجود عدد معين لأرسال الطلبات فى نظام المصادقة مما ادى الى حدوث هجوم التخمين .
2- عدم حظر الـ IP الخاص بالمهاجم بسبب كثرة الطلبات الناشئة من قبل المهاجم.
3- عدم وجود نظام المصادقة الثنائية (2FA) الذى تتيح التحقق من الطلب عبر ارسال رسالة نصية الى المستخدم.
4- عدم تشفير بيانات الأعتماد الخاص بالمستخدم بما يصعب على المهاجم معرفة نوع التشغير او الـ Salt المستخدم.
5- يجب أن تتحقق  JWT دائمًا من صحة الرمز المميز باستخدام الخوارزمية المناسبة (اذا وجد)، ومعظم أطارات عمل JWT بها خوارزمية تكون اعدادتها بشكل افتراضي وهذا أمر سيء للغاية.

ما هو السبيل الى الحماية ؟

1- افهم بالضبط كيف تعمل آليات المصادقة الخاصة بك ، لا تقوم فقط بتنفيذ شيء مثل oauth2 بشكل أعمى ، فالكثير من المطورين ينفذون ذلك بشكل غير صحيح.
2- يجب حماية جميع نقاط نهاية المصادقة Endpoint (بما في ذلك كلمة المرور المنسية) من خلال تحديد معدلها وتنفيذ آليات الصلاحيات لها.
3- قم بتطبيق آليات captcha لمنع المهاجمين من هجوم التخمين التلقائى بأستخدام ادوات تلفائية لأرسال الطلبات.
4- قم بتنفيذ نظام المصادقة الثنائية (2FA) مثل الرسائل القصيرة أو المصادقة و قم بتطبيق anti-brute-forcing
5- لابد من وجود الذين يراقبون حركة المرور ولديهم بيانات تتبع عن بُعد حول لمحاولات تسجيل الدخول الفاشلة ، يمكن رصد هذه الهجمات بسهولة.
6- لا تستخدم مفاتيح API للمصادقة ، يجب استخدامها لمصادقة العميل/التطبيق.
7- هناك بعض إرشادات عامة قدمتها OWASP لحظر هذا النوع من الهجوم وكيفية المصادقة.
8- يمكن استخدام البنية التحتية الحالية لحظر المهاجم أو إلغاء المصادقة عليه أو اتخاذ إجراء ضد المهاجم.

خاتمة

عند التعامل مع الـ authentication endpoints او نقاط النهاية الخاصة بعملية المصادقة ، نحتاج إلى تنفيذ آليات أمان صارمة أكثر من التعامل مع endpoints العادية. لذلك احرص على تطبيق معدلات امان الـ API وتأكد من قيامك بتنفيذ آليات مصادقة آمنة وإذا لم تكن متأكدًا ، يمكنك دائمًا الرجوع إلى تقرير مصادقة OWASP أو قراءة مقالة قائمة ثغرات الـ API الأشهر OWASP TOP 10 محتواها والإجراءات الواجب اتخاذها., والسلام ختام 

ما مرّ ذِكرُكَ إلا وابتسمتُ لهُ & كأنكَ العيد والباقون أيّامُ

‏أو حَامَ طيفُكَ إلا طِرتُ أتبعُهُ & أنتَ الحقيقةُ والجلّاسُ أوهامُ