مقدّمة
في عصر المصادقة عبر الإنترنت (OAuth، SSO، تسجيل الدخول عبر Google/Facebook)، ظهرت تقنية احتيالية ذكية تُعرف باسم Browser-in-the-Browser (BitB) — أو بالعربية «المتصفح داخل المتصفح».
هذا الهجوم لا يحتاج ثغرة برمجية تقليدية، بل يعتمد على خداع بصري واجتماعي (UI deception) يجعل المستخدم يصدّق أنّه يُدخل بياناته في نافذة مصادقة رسمية بينما هو في واقع الأمر يقدّم بياناته لصفحة خبيثة.
في هذا المقال سنشرح الفكرة تقنيًا وبشكل واضح، نماذج الهجوم، علامات الكشف، وكيف تحمي مستخدميك وخدماتك منه — بدون تعليمات تنفيذية ضارة، مع تركيز عملي على الوقاية والدفاع.
ما هو هجوم Browser-in-the-Browser (BitB)؟
BitB هو شكل من أشكال هجمات التصيّد (phishing) يَستخدم نوافذ منبثقة (popups) أو عناصر ظاهرية داخل صفحة الويب لعرض «نافذة تسجيل دخول» تبدو تمامًا مثل نافذة المصادقة الحقيقية (مثلاً نافذة OAuth الخاصة بجوجل).
الفرق: بدلاً من إعادة توجيه المستخدم إلى صفحة موثوقة أو فتح نافذة حقيقية للمتصفح، يظهر المهاجم نافذة وهمية داخل الصفحة (HTML/CSS/JS) تُحاكي شريط العنوان، أيقونات الموقع، حتى زر الإغلاق — كل ذلك لإقناع المستخدم بإدخال اسم المستخدم وكلمة المرور أو منح صلاحيات الوصول.
كيف يعمل الهجوم (فكرة عامة، بدون تفاصيل عملية)
- يجهّز المهاجم صفحة تصيّد أو يحقن سكربت في صفحة موثوقة عبر XSS أو إعلان خبيث.
- يعرض على المستخدم زرًا مثل "Sign in with Google" أو رابطًا يؤدي إلى نافذة «تسجيل رسمي».
- عند النقر، لا يفتح المتصفح نافذة مصادقة أصلية، بل تُنشأ داخل الصفحة مركبة (modal) تُحاكي المتصفح: شريط عنوان مزيف، أيقونة القفل المزيفة، وعناصر واجهة أخرى.
- المستخدم يظن أنه يتعامل مع نافذة نظامية، فيُدخل بياناته أو يوافق على منح صلاحيات (scopes).
- المهاجم يجمع بيانات الاعتماد أو يحصل على توكن وصول (access token) إذا استُخدمت آليات منح غير محمية.
> ملاحظة مهمة: الهجوم يستغل ثقة المستخدم في عناصر واجهة المستخدم (UI) وليس بالضرورة ثغرة في المتصفح نفسه — لذا الوقاية تعتمد على صرامة الواجهات والعمليات الأمنية.
أمثلة واقعّية للسيناريوهات
- منتدى أو إعلان يحتوي رابطًا لـ «تسجيل سريع عبر Google»؛ فتح نافذة وهمية تطلب الإذن للوصول إلى البريد.
- صفحة داخل تطبيق ويب تعرض نافذة تبدو مثل نافذة المصادقة لـ SSO وتطلب إدخال كلمة المرور مجددًا.
- تطبيق ويب يستخدم نوافذ منبثقة لإكمال مهام المستخدم؛ مهاجم يستغلها لعرض واجهة تسجيل مزيفة.
لماذا هذا الهجوم فعّال؟
- محاكاة واجهة المتصفح: شريط العنوان المزيف يجعل المستخدم يعتقد بأن النافذة أصلية.
- اعتماد المستخدم على النوافذ المنبثقة في عمليات OAuth وSSO.
- قلة الوعي: معظم المستخدمين لا يتحققون من قِدم/أصل نافذة المصادقة أو من شريط العنوان الفعلي.
تصميم واجهات سيئة في بعض الخدمات تسمح بفتح مصادقة داخل iframes أو modals بدل الانتقال إلى نافذة نظامية.
مؤشرات على وجود هجوم BitB (علامات للمستخدم والمطور)
للمستخدم:
- النافذة تبدو داخل الصفحة (يمكنك تحريك مؤشر الماوس خارجها ورؤية الصفحة تحتها).
- شريط العنوان لا يستجيب كالشريط الحقيقي (لا يمكن سحب النافذة من شريط العنوان الحقيقي).
- لا يمكنك الوصول إلى شريط العنوان الحقيقي للمتصفح (URL الحقيقي لا يظهر بوضوح).
- طلب صلاحيات غريبة وغير مرتبطة بالخدمة.
للمطور/المؤسسة:
- نوافذ المصادقة تُعرض داخل iframes أو عناصر modal بدلاً من نافذة منفصلة أو إعادة توجيه إلى نطاق موثوق.
- عدم وجود سياسات صارمة لـ redirect_uri في OAuth.
- السماح لعرض صفحاتك داخل iframes (X-Frame-Options غير مضبوط).
كيف تكتشف الهجوم (تقنيًا)
- تحليل سلوك النوافذ: رصد إذا ما كانت نافذة المصادقة موجودة داخل DOM الرئيسي أم كنافذة منفصلة.
- مراقبة طلبات OAuth: تحقق من الـ redirect_uri والمنشأ (origin) عند منح صلاحيات.
- سجلات المستخدمين: ارتفاع في محاولات المصادقة الفاشلة أو طلبات منح صلاحيات من نطاقات غير مألوفة.
- أدوات الحماية: بعض حلول EDR/UEBA قد تكشف سلوكيات مشبوهة لمواقع تصيّد.
كيف تمنع هجوم BitB — ضوابط تقنية فعّالة
> التركيز هنا على خطوات دفاعية وإجراءات تصميم آمنة لا تسمح لمهاجم ببناء واجهة مخادعة بسهولة.
لمطوّري ومصمِّمي التطبيقات
1. لا تعرض نوافذ المصادقة داخل iframes/modal داخل نفس الصفحة. إجبار المصادقة على أن تحدث في نافذة مستقلّة أو عبر إعادة توجيه إلى نطاق المصادِق الموثوق.
2. استخدم OAuth Best Practices:
- فرض redirect_uri مسجّل ومقيّد بدقة.
- تفعيل PKCE (خصوصًا للتطبيقات العامة).
- التحقق من state وnonce لمنع CSRF و replay attacks.
3. ضبط رؤوس الأمان:
- X-Frame-Options: DENY أو Content-Security-Policy: frame-ancestors 'none' لمنع العرض داخل إطارات.
- Referrer-Policy و Strict-Transport-Security.
5. rel="noopener noreferrer" مع window.open لمنع الوصول إلى window.opener من الصفحة المحملة.
- لمزودي الهوية (Identity Providers)
- إظهار عناصر واجهة مميزة لا يمكن تقليدها بسهولة (مثلاً نافذة نظامية منفصلة أو تفعيل مصادقة جهازية مثل WebAuthn).
- دعم طرق مصادقة لا تعتمد على إدخال كلمة المرور داخل نافذة (OAuth device flow، WebAuthn).
للمستخدمين ومنظّمات التوعية
- درّب المستخدمين على التحقق من شريط العنوان الحقيقي وعدم إدخال بيانات الاعتماد داخل نوافذ تبدو داخل الصفحة.
- لا تمنح صلاحيات غير مفهومة (scopes) لتطبيقات غير موثوقة.
- استخدم المصادقة متعددة العوامل (MFA) وطرق مبنية على مفاتيح أمان (FIDO2/WebAuthn).
إجراءات طوارئ عند الاشتباه باختراق
- إبطال التوكنات والجلسات المشبوهة فورًا (revoke tokens, invalidate sessions).
- فرض إعادة تعيين كلمات المرور للحسابات المتأثرة (إذا كانت بيانات الاعتماد مسروقة).
- فحص سجلات الوصول (access logs) لتحديد مدى التعرض.
- إعلام المستخدمين المتأثرين وتقديم إرشادات أمنية فورية.
هل يمكن للمتصفح أن يمنع الهجوم بالكامل؟
بعض متصفحات حديثة تعمل على تقليل قابلية محاكاة شريط العنوان عبر CSS/HTML، لكن لا توجد «حلّ سحري» دون تعاون من المصممين ومزودي الهوية: التصميم الآمن للعملية (design for secure auth flow) ووعي المستخدم هما الحلان الأهم.
ملخص التوصيات السريعة (Checklist للمدراء والمطورين)
- ⛔ منع عرض صفحاتك داخل iframes (X-Frame-Options / frame-ancestors).
- ✅ فرض استخدام PKCE وقيود redirect_uri في OAuth.
- 🔒 إجبار المصادقة على top-level navigation أو نافذة نظامية.
- 🔐 استخدام WebAuthn/FIDO2 حيثما أمكن.
- 📢 توعية المستخدمين والتحقق من سلوكيات المصادقة.
- 🧾 مراقبة السجلات وسلوك التوكنات لاكتشاف نشاط شاذ.
أسئلة شائعة (FAQ)
هل BitB يحتاج ثغرة XSS لاشتغاله؟
لا بالضرورة — يمكن للمهاجم استغلال طرق أخرى لعرض الواجهة الوهمية (مثل صفحة تصيّد مستقلة أو سكربت عبر إعلان)، لكن XSS يزيد سهولة التنفيذ داخل مواقع موثوقة.
هل استخدام popup حقيقي آمن؟
الاستخدام الصحيح لنافذة منفصلة أو إعادة التوجيه إلى مزود الهوية الرسمي أكثر أمانًا من modal داخل الصفحة، بشرط التحقق من redirect_uri ووجود PKCE.
كيف أتعامل كمستخدم إن ظهرت لي نافذة تسجيل داخل نفس الصفحة؟
أوقف العملية واغلق الصفحة، لا تدخل بيانات اعتمادك، وتواصل مع الدعم الرسمي للخدمة. تحقق دومًا من شريط العنوان الحقيقي في أعلى المتصفح.
CTA: 🖥 لمتابعة المزيد من مقالات الأمن السيبراني وادوات الحماية: اضغط [هنا]
