أبحاث الثغرات · دراسة معمّقة
خلال تقييم هجومي لأحد التطبيقات، صادف Uzair Kaaf نقطة نهاية لتسجيل الدخول أعادت رمز جلسة بصلاحيات كاملة فور إدخال اسم المستخدم وكلمة المرور، رغم أن المصادقة الثنائية عبر TOTP كانت مفعّلة للحساب. وقد طلبت واجهة الويب رمز التحقق كما ينبغي. لكن واجهة API كانت قد فتحت الباب بالفعل.
الغاية من المصادقة الثنائية ألّا تكفي كلمة مرور مسروقة وحدها للوصول إلى الحساب. أما هنا فلم تمنع ذلك إلا لمن يستخدم المتصفح من البشر. ومن خاطب واجهة API مباشرةً لم يكن بحاجة إلى العامل الثاني.
تتحقق نقطة نهاية تسجيل الدخول من اسم المستخدم وكلمة المرور، وتُصدر فورًا رمز جلسة بصلاحيات كاملة. أما كون رمز TOTP لا يزال مفقودًا، فلا يرد إلا في صورة إشارة ضمن الاستجابة نفسها.
اسم المستخدم وكلمة المرور الخاصان بالضحية، مثلًا من التصيّد الاحتيالي أو تسريبات البيانات أو حشو بيانات الاعتماد (Credential Stuffing). أما الهاتف الذكي للضحية أو تطبيق المصادقة لديه فلا يحتاج إليهما.
جميع صلاحيات حساب الضحية. وفي الحالة المختبَرة كان للحساب الدور workspace_admin: إذ كان بإمكان المهاجم تصدير بيانات المستأجر، وتغيير بيانات الفوترة، وتعديل بيانات الملف الشخصي، وإعادة توليد مفاتيح الأمان.
بوصفه Improper Authentication (CWE-287) وMissing Critical Step in Authentication (CWE-304). ويُعرف النمط الكامن وراءه باسم Client-Side Enforcement of Server-Side Security (CWE-602).
درجة الخطورة وفق CVSS 3.1
7.4
المتجهCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N (يفتح موقعًا خارجيًا)
قُيّم تعقيد الهجوم (Attack Complexity) بأنه عالٍ، لأن على المهاجم أولًا الحصول على كلمة مرور الضحية؛ وتذكر مواصفة CVSS الحصول على مثل هذه الأسرار مثالًا على التعقيد العالي. ولا يحتاج المهاجم إلى أي صلاحيات خاصة به، لأن كلمة المرور وحدها لا ينبغي أن تفتح شيئًا من دون العامل الثاني. أما كل ما عدا ذلك فينجح عبر الشبكة، من دون أي تدخل من الضحية.
99.22%
انخفاض في خطر الاختراق: هذا ما حققته المصادقة متعددة العوامل (MFA) في تحليل لحسابات في Microsoft Azure Active Directory. وتجاوزٌ كهذا يُعطّل هذه الحماية بالذات.
لا يُذكر اسم المنصة المتأثرة. وأسماء المضيفين والمعرّفات والرموز في هذه الصفحة مُموَّهة؛ أما التدفقات والاستجابات فمطابقة للنتيجة.
تتواصل تطبيقات الصفحة الواحدة وتطبيقات الهاتف المحمول مع النظام الخلفي (Backend) عبر واجهات API من نوع REST أو GraphQL. ويصبح الأمر خطيرًا حين يُترك جزء من التحكم في الوصول لمنطق العميل.
auth_token (scope: admin_access) + "two_factor_required": trueلم يكن اشتراط العامل الثاني ساريًا إلا في طبقة العرض، لا في البروتوكول.
challenge_token (scope: auth:mfa_challenge, 300 s)auth_token (scope: user:authenticated)من دون رمز تحقق صالح، لا يوجد أي رمز (Token) يمكن الاستفادة منه.
تصرّف المتصفح على النحو الصحيح: فقد احترم العلامة (Flag) ومنع التنقل. لكن لأن الخادم أصدر رمز الجلسة في الوقت نفسه، باتت فاعلية الحماية بأكملها متوقفة على أن يلتزم كل عميل بذلك طوعًا.
الطلبات والاستجابات مُموَّهة، أما التدفق والمحتوى فمطابقان للنتيجة.
كانت المصادقة الثنائية عبر TOTP مفعّلة في إعدادات الأمان للحساب المستهدف. وأكّدت محاولات تسجيل الدخول في المتصفح ذلك: فمن دون الرمز المكوّن من ستة أرقام لم تُتح واجهة المستخدم أي شيء.
يستدعي المهاجم ببيانات الاعتماد المسروقة نقطة نهاية REST ذات رقم الإصدار مباشرةً، مثلًا عبر curl أو نص برمجي. ولم تعد واجهة الويب طرفًا في هذا التدفق.
POST /api/v5/login HTTP/1.1Host: app.example.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Content-Type: application/jsonAccept: application/json{ "username": "victim", "password": "CompromisedPassword2026!"}تتحقق الخدمة من بيانات الاعتماد وتردّ برمز جلسة بدلًا من تحدٍّ (Challenge). وتذكر الاستجابة نفسها أن العامل الثاني مفقود، ومع ذلك تتضمّن رمز الجلسة. ويحمل الرمز بالفعل النطاق admin_access.
HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8Cache-Control: no-cache, no-store{ "status": "success", "data": { "user_id": "usr_99123", "email": "victim.user@example.com", "two_factor_required": true, "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c3JfOTkxMjMiLCJzY29wZSI6ImFkbWluX2FjY2VzcyJ9.SANITIZED" }}{ "userId": "usr_99123", "scope": "admin_access"}أُزيل التوقيع، والقيم مُموَّهة.
يستعلم المهاجم باستخدام رمز الجلسة من نقاط نهاية الملف الشخصي والإدارة. ويقبله الخادم دون أي تحقق إضافي، ويُبلغ عن الدور workspace_admin بما يشمل صلاحيات تصدير البيانات وتعديل الفوترة.
GET /api/v5/users/me/profile HTTP/1.1Host: app.example.comAuthorization: Token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c3JfOTkxMjMiLCJzY29wZSI6ImFkbWluX2FjY2VzcyJ9.SANITIZEDAccept: application/jsonHTTP/1.1 200 OKContent-Type: application/json; charset=utf-8{ "user_id": "usr_99123", "role": "workspace_admin", "email": "victim.user@example.com", "tenant_id": "tenant_eu_4402", "settings": { "can_export_data": true, "can_modify_billing": true }}لا تُعيدوا تنفيذ ذلك إلا على أنظمتكم الخاصة أو بتصريح كتابي من مشغّل النظام.
لا يكمن الخلل في سطر شيفرة واحد، بل في طريقة تصميم تدفق تسجيل الدخول.
افترض النظام الخلفي (Backend) أن كل استدعاء يمرّ عبر واجهة المستخدم المخصّصة له، وأن هذه الواجهة توقف التدفق حالما تحمل two_factor_required القيمة true. أما المهاجم فيكتب ببساطة عميله الخاص.
لم تفصل خدمة المصادقة بين مرحلة «تم التحقق من كلمة المرور» ومرحلة «تم منح الجلسة». ولا يجوز أن ينشأ رمز جلسة صالح للاستخدام الفعلي إلا بعد فحص جميع العوامل.
بالنسبة إلى المستخدمين يعمل كل شيء كما هو مقصود، وكل استجابة هي 200 OK عادية لا تثير الريبة. ولا يظهر الخلل إلا عندما يستدعي أحدهم نقطة النهاية من دون واجهة المستخدم ويقرأ الاستجابة حقلًا حقلًا.
يعالج الإجراء الأول السبب الجذري. ويضمن الإجراءان الآخران ألّا يعود الخلل في أي موضع آخر.
عند تفعيل العامل الثاني، لا تُصدر نقطة نهاية تسجيل الدخول سوى رمز تحدٍّ: قصير العمر (نحو خمس دقائق)، وصالح للاستخدام مرة واحدة، ومرتبط بالحساب وبعملية تسجيل الدخول، ولا يصلح إلا لفحص رمز التحقق. ولا يُنشأ رمز الجلسة إلا في الخطوة الثانية.
POST /api/v5/login{ "username": "…", "password": "…" }→ 200 { "data": { "challenge_token": "ct_…", "scope": "auth:mfa_challenge", "expires_in": 300 } }POST /api/v5/login/verify-2fa{ "challenge_token": "ct_…", "totp_code": "123456" }→ 200 { "data": { "auth_token": "eyJ…", "scope": "user:authenticated" } }تتحقق بوابة API (API Gateway) أو البرمجيات الوسيطة (Middleware) عند كل نقطة دخول من مطالبات الرمز (Claims). ولا تقبل المسارات المحمية إلا الرموز ذات النطاق user:authenticated، أما رمز التحدي (auth:mfa_challenge) فيتلقى فيها الرد 401 أو 403. وإذا سجّل رمز الجلسة أيضًا العوامل التي جرى فحصها، مثلًا في مطالبة amr، أمكن لكل خدمة التحقق من ذلك بنفسها.
if (!String(token.scope ?? '').split(' ').includes('user:authenticated')) { return res.status(401).end()}const user = await users.findById(token.sub)if (user.mfaEnabled && !token.amr?.includes('otp')) { return res.status(403).end()}تُجري الاختبارات الشاملة (End-to-End) تسجيل الدخول لحساب مفعَّل فيه العامل الثاني عبر عميل HTTP خام وعلى كل مسار لتسجيل الدخول، وتتحقق من أنه لا يمكن الوصول إلى أي نقطة نهاية محمية من دون رمز التحقق. وهكذا يُكتشف أي تراجع عند الإصدار التالي، لا عند المهاجم التالي.
LOGIN_PATHS = ["/api/v5/login", "/api/v4/login"] # every login route, incl. legacy versions@pytest.mark.parametrize("path", LOGIN_PATHS)def test_login_without_second_factor_yields_no_session(client, mfa_user, path): r = client.post(path, json=mfa_user.credentials) assert r.status_code == 200 data = r.json()["data"] assert set(data) <= {"challenge_token", "scope", "expires_in"} assert data["scope"] == "auth:mfa_challenge" p = client.get("/api/v5/users/me/profile", headers={"Authorization": "Token " + data["challenge_token"]}) assert p.status_code in (401, 403)المراجع: Multifactor Authentication Cheat Sheet (يفتح موقعًا خارجيًا) · SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (يوليو 2025) (يفتح موقعًا خارجيًا) · RFC 6238: TOTP: Time-Based One-Time Password Algorithm (مايو 2011) (يفتح موقعًا خارجيًا) · RFC 8176: Authentication Method Reference Values (يونيو 2017) (يفتح موقعًا خارجيًا)
ثمانية أسئلة لفرق التطوير والأمن. لا يغني الفحص الذاتي عن الاختبار، لكنه يُظهر أين ينبغي لكم التدقيق أكثر. وتبقى إجاباتكم في المتصفح.
تمت الإجابة: 0/8
النتيجة للاسترشاد فقط، وليست دليل إثبات للتدقيق.
تشترط أطر تنظيمية كثيرة المصادقة متعددة العوامل أو ضوابط وصول قوية. وتجاوزٌ كهذا يعني أن الضابط موثَّق، لكنه غير فعّال.
يذكر توجيه NIS2 صراحةً حلول المصادقة متعددة العوامل ضمن تدابير إدارة مخاطر الأمن السيبراني، وينقل قانون BSI الألماني (BSIG) ذلك إلى القانون الألماني. وأي مصادقة متعددة العوامل يمكن تجاوزها عبر واجهة API لا تحقق هذا الغرض.
التوجيه (EU) 2022/2555 (NIS2) (ديسمبر 2022) (يفتح موقعًا خارجيًا) · قانون BSI الألماني (BSIG)، تدابير إدارة المخاطر (يفتح موقعًا خارجيًا)
تطبيق NIS2يشترط الضابط «المصادقة الآمنة» (Secure authentication) إجراءات مصادقة آمنة، ويجب على نظام ISMS أن يقيّم فعالية ضوابطه. لذلك ينبغي لعمليات التدقيق أن تتناول أيضًا تدفق تسجيل الدخول في واجهة API، لا إعدادات واجهة المستخدم فحسب.
ISMS وفق ISO 27001إذا تمكّن شخص ما بهذه الطريقة من الوصول إلى بيانات شخصية، فهذا خرق لأمن البيانات الشخصية. ويجب على المسؤول عن المعالجة إبلاغ السلطة الرقابية به دون تأخير غير مبرَّر، وإن أمكن خلال 72 ساعة من علمه به، ما لم يكن من غير المرجّح أن يُفضي إلى خطر على الأشخاص المعنيين.
اللائحة (EU) 2016/679 (DSGVO) (يفتح موقعًا خارجيًا)
نظام إدارة حماية البياناتاعتبارًا من 11 ديسمبر 2027 يجب على الشركات المصنِّعة للمنتجات ذات العناصر الرقمية حمايتها من الوصول غير المصرّح به عبر ضوابط مناسبة مثل المصادقة. أما التزامات الإبلاغ عن الثغرات الأمنية المستغَلّة بشكل نشط فتسري بالفعل منذ 11 سبتمبر 2026. ولا تندرج عروض SaaS البحتة ضمن نطاقه في الغالب، بخلاف التطبيقات والبرمجيات التي يجري تسليمها، بما في ذلك خدمات الواجهة الخلفية (Backend) التابعة للمصنِّع التي لا تستطيع من دونها أداء إحدى وظائفها.
اللائحة (EU) 2024/2847 (Cyber Resilience Act) (يفتح موقعًا خارجيًا)
الامتثال لـ CRAلا يُعدّ هذا العرض استشارة قانونية.
ما يعلّمه Magical 2FA Bypass عن مصادقة واجهات API، معدًّا لصنّاع القرار: النمط ومسارات تسجيل الدخول، وتسجيل الدخول على مرحلتين وفحص الرموز، والاختبارات والأدلة، وأسئلة للموردين، والإطار التنظيمي، وخطة 30-60-90 يومًا. متاحة بالإنجليزية والألمانية.
نفحص تدفقات تسجيل الدخول كما يراها المهاجمون: من دون واجهة المستخدم، وبطلبات خام، ومع الانتباه إلى كل رمز (Token).
المعايير والمواصفات والنصوص القانونية والدراسات التي تستند إليها هذه الدراسة المعمّقة.
إجابات موجزة
هو طريقة لاستخدام حساب محمي بالمصادقة الثنائية من دون تقديم العامل الثاني. وفي حالة Magical 2FA Bypass أصدرت واجهة API لتسجيل الدخول رمز الجلسة بعد التحقق من كلمة المرور مباشرةً.
لا. يكفيه اسم المستخدم وكلمة المرور، وهذا تحديدًا ما يُفترض أن يحمي منه العامل الثاني في الأصل.
سجّلوا الدخول بحساب اختبار مفعَّل فيه العامل الثاني إلى نقطة نهاية تسجيل الدخول عبر عميل HTTP خام، واقرؤوا الاستجابة كاملةً. فإذا تضمّنت رمزًا (Token) يفتح نقاط نهاية محمية من دون رمز التحقق، فالتطبيق متأثر. ولا تُجروا الفحص إلا على أنظمتكم الخاصة أو على الأنظمة التي لديكم تصريح كتابي بفحصها.
لا. يجب إضافةً إلى ذلك أن ترفض كل نقطة نهاية محمية الرموز التي صدرت من دون إتمام العامل الثاني. وإلا عاد الخلل عبر مسار آخر، مثل إصدار أقدم من API أو تجديد الرمز (Token Refresh).
لا ننشر ذلك. وجميع أسماء المضيفين والمعرّفات والرموز في هذه الصفحة مُموَّهة.
تندرج ضمن API2:2023 Broken Authentication. وتذكر توصيات OWASP بشأن MFA صراحةً واجهات API المنفصلة لتسجيل الدخول بوصفها موضعًا ينبغي أن تُطبَّق فيه MFA أيضًا أو أن تتوفر فيه وسائل حماية أخرى.
نختبر نقاط نهاية المصادقة كما يفعل المهاجمون، ونُريكم أين يُنشأ رمز (Token) قبل أوانه.