تتغير طبيعة الهجمات الإلكترونية بسرعة، لكن ثمة نمطًا يزداد خطورة: الهجمات التي لا تكتفي بتخريب محتوى الرسالة، بل تحاول اختراق الحدود بين “البريد غير الموثوق” و“واجهة الويب الموثوقة” التي تعرضه. تشير أبحاث جديدة عُرضت في [Black Hat USA 2026] إلى أن محتوى HTML وCSS داخل رسائل البريد قد “يتجاوز” حدود الرسالة ليؤثر في عناصر واجهة الويب الخاصة بخدمة البريد نفسها، بما يفتح الباب لالتقاط بيانات حساسة، وإعادة توجيه تفاعلات المستخدم، وحتى خداع أدوات ذكاء اصطناعي مرتبطة بالبريد.
الأهم هنا ليس مجرد وجود ثغرة في مُعالج رسائل، بل إمكانية تكوين سلسلة هجوم كاملة عبر عدة مزودي بريد مشهورين مثل Outlook وGmail وFastmail وProton Mail وYahoo Mail وAOL Mail. ورغم أن الباحثين قدموا إثباتات تقنية (Proof of Concept) ولم يصرّحوا بوقوع استغلالات خبيثة واسعة النطاق، فإن الدرس واضح: إذا كانت واجهة الويب تتعامل مع محتوى البريد بطريقة “قريبة جدًا” من الوثوق، فستظهر طرق للتلاعب.
لماذا يهم هذا لمؤسسات المال والصحة والحكومة؟
البريد الإلكتروني ليس مجرد وسيلة مراسلة؛ إنه بنية تحتية للهوية. كثير من عمليات إعادة تعيين كلمة المرور، وتأكيد تسجيل الدخول، وإدارة الجلسات، وربط التطبيقات الخارجية تعتمد على رسائل البريد. وعندما يتحول البريد إلى قناة قادرة على التأثير على واجهة الويب أو واجهات الطرف الثالث، فإن الأثر يمتد من حساب فردي إلى منظومة كاملة.
في قطاع التمويل، على سبيل المثال، تُستخدم رسائل البريد لتوثيق معاملات، وإرسال تنبيهات أمنية، وتفعيل صلاحيات. وفي الرعاية الصحية، قد تحتوي الرسائل على روابط بوابات المرضى أو تنبيهات تشغيلية. أما في الجهات الحكومية، فتتكرر سيناريوهات الاعتماد على البريد لتنفيذ طلبات داخلية أو مصادقة متعددة الخطوات. لذلك فإن أي استغلال يتيح اختطاف جلسات أو تجاوز واجهات تسجيل الدخول أو تسريب رموز الوصول يضاعف المخاطر.
ما المقصود بـ“تجاوز حدود الرسالة”؟
لفهم جوهر البحث، نحتاج إلى مصطلحين شائعين في أمن الويب:
التنقية (Sanitization): عملية إزالة/تعديل عناصر وسمات HTML وCSS غير المسموح بها قبل عرض الرسالة. الهدف أن يصبح محتوى الرسالة “آمنًا” حتى لو كان خبيثًا.
العزل داخل المتصفح (Sandboxed Isolation): أسلوب فصل محتوى غير موثوق داخل بيئة معزولة (مثل iframe مع قيود صارمة) لمنع تأثيره في بقية الصفحة الموثوقة.
البحث الجديد يركز على سيناريوهات يظهر فيها أن “الرسالة” لا تبقى محصورة. إما لأن المتصفح/التطبيق يخلق عناصر DOM بطريقة تختلف عن تلك التي يفترضها المُنقّي، أو لأن بعض قدرات CSS/HTML التي سمح بها النظام تصبح “أداة” للانتقال إلى سلوك واجهة الويب.
كيف تُبنى سلاسل الهجوم؟ (من حقن الأنماط إلى تسريب بيانات)
بحسب الأبحاث، هناك مساران رئيسيان:
استغلال ما هو مسموح أصلًا: إذا كانت واجهة البريد تسمح ببعض عناصر HTML أو خصائص CSS، يمكن للمهاجم توظيفها بشكل غير متوقع للتأثير خارج الحدود المخصصة.
خلق اختلاف بين ما يوافق عليه المُنقّي وما ينتهي به الأمر في DOM: أي أن المُنقّي قد يقرر أن شيئًا “غير مسموح”، لكن التطبيق أو المتصفح قد ينتهي إلى إنشاء عقدة/نمط فعلي يتجاوز قائمة السماح.
في سلاسل متعددة المزودات، وُصفت حالات يمكن أن تؤدي إلى:
التقاط كلمات المرور أثناء إدخال المستخدم في واجهة مزيفة.
اختطاف رموز تسجيل/جلسات أو تسريبها عبر مسارات غير مباشرة.
التلاعب بتفاعلات واجهة المستخدم (UI) مثل تحويل النقرات إلى إجراءات غير مقصودة.
خداع أدوات ذكاء اصطناعي مرتبطة بالبريد عبر “حقن تعليمات” تُلتقط عند معالجة الرسائل.
مثال Outlook: واجهة تسجيل مزيفة والتقاط كلمة المرور
أحد السيناريوهات الموصوفة يدمج تقنيات حقن الأنماط مع سلوك واجهة الويب. الفكرة الأساسية: يتم “تشويه” مظهر عناصر لتبدو كجزء من عملية تسجيل دخول شرعية، بينما يُستخدم التوقيت وسلوك المتصفح لالتقاط ما يكتبه المستخدم. تشير الأبحاث إلى أن سلسلة تشمل Outlook وFirefox استخدمت شاشة تسجيل دخول مزيفة من نمط “Microsoft sign-in” بهدف التقاط كلمة المرور.
وهذا ينسجم مع درس قديم في أمن التصيّد (Phishing): كلما اقتربت واجهة الهجوم من ثقة المستخدم، زادت فرص النجاح. لكن الجديد هنا هو أن الهجوم لا يعتمد فقط على النصوص والرابطات، بل على التلاعب في طبقات العرض داخل الويب.
مثال Yahoo/AOL: سباق لالتقاط رمز تسجيل الدخول
وُصف مسار مختلف: في Firefox، يمكن أن يحتفظ لصق HTML بخبيث لبعض الوقت بميزات CSS نشطة قبل انتهاء التنقية. ثم تُستغل هذه النافذة الزمنية في سيناريو “Medium” (كمثال توضيحي) حيث يتم تشغيل تدفق تسجيل دخول، وطلب من الضحية نسخ CSS المهاجم ولصقه في مسودة بريد على Yahoo أو AOL. النتيجة قد تُظهر طلبات كافية لإعادة بناء رمز تسجيل الدخول (Token) المكون من 12 حرفًا تقريبًا، ما يتيح للمهاجم تسجيل الدخول باسم الضحية.
هذا النوع من الهجمات يوضح خطر سباقات التزامن (Race Conditions) في مسارات التنقية والعرض. ولمزيد من الفهم، راجع تعريف حالة السباق.
مثال Gmail: حقن يمكن أن يؤدي لتسريب رمز من Slack
في سلسلة Gmail، ذُكر سيناريو يرتبط بـ Slack عبر “Prompt Injection” مع تفاعل مستخدم. الفكرة: يتم إرسال بريد مُحقن تعليمات (ضمن سياق “AI-connected email”) بحيث عند قيام المستخدم بخطوة معينة، يتم استغلال آلية معالجة/عرض أو ربط خارجي لاستخراج رمز مصادقة متعلق بـ Slack أو تسريبه.
للتوضيح: حقن الأوامر (Prompt Injection) هو فئة من الهجمات تحاول جعل نموذج أو نظام ذكاء اصطناعي يلتزم بتعليمات غير موثوقة. انظر Prompt injection على ويكيبيديا.
عندما يدخل الذكاء الاصطناعي في المعادلة: رسائل “تُقرأ” وتُنفَّذ
المرحلة الأكثر إثارة للقلق في الأبحاث هي ربط البريد بأدوات ذكاء اصطناعي. لأن البريد لم يعد مجرد نص يُعرض؛ بل أصبح مُدخلًا تتعامل معه أدوات قد تُلخصه أو تنفذ مهام بناءً على محتواه.
Gmail مع موصلات مرتبطة بـ Claude Cowork: تسريب رمز عبر مسودة HTML
تم توثيق سلسلة توضح كيف يمكن لبريد مُحقن أن يدفع أداة ذكاء اصطناعي (عبر موصل Gmail) إلى استخراج رمز من رسالة تأكيد ثم وضعه في مسودة HTML. وعند عرض المسودة داخل واجهة الويب، يتم تسريب الرمز عبر مسار عرض/تحميل خارجي.
Fastmail مع Atlas AI: تعليمات مخفية تُقرأ بواسطة نموذج
في تجربة أخرى، استهدف الباحثون متصفحًا/مساعدًا ذكاء اصطناعيًا من خلال Fastmail. استخدمت الحيلة خصائص CSS لإظهار نص “غير ضار” للإنسان، بينما تُلتقط تعليمات مخفية بواسطة النموذج. وعند طلب الضحية من الأداة ترجمة النص المرئي، قد تُنفّذ التعليمات المخفية فتؤدي لفتح تبويبات وتضمين اسم الضحية ضمن أجزاء من URL.
من المهم هنا أن الشركة المطورة أشارت إلى أن Atlas يجري إيقافه تدريجيًا، مع جدول لإيقاف العمل بحلول 9 أغسطس 2026. هذا يعكس اتجاهًا أوسع: حتى عندما تُعالج مشكلة في منتج بعينه، قد تعيش “فكرة الهجوم” وتنتقل إلى تكاملات أخرى.
ماذا عن إصلاحات المزودين؟ ولماذا لا يكفي “الترقيع”؟
الأبحاث تشير إلى أن بعض المزودين أجروا تعديلات بعد الكشف، مثل إصلاح Fastmail لثغرتين مرتبطتين بـ [CSS mutation]، وتوقف نجاح مسار Proton Mail الخاص بتجاوز البروكسي عند إعادة الاختبار. كما ذُكر أن بعض عناصر أخرى ما زالت تعمل وقت نشر البحث (مثل “label-jacking” في Outlook وبعض تجاوزات CSS في Gmail).
لكن جوهر الرسالة الدفاعية لا يعتمد على “من أصلح ماذا”. بل على مبادئ هندسية:
العزل الصارم لمحتوى HTML داخل رسائل البريد باستخدام sandboxed iframes وقيود تمنع التأثير في DOM الرئيسي.
قوائم سماح دقيقة (Allow lists) لخصائص CSS والسمات المخصصة، مع رفض “gadget” المعروفة التي قد تُستخدم لبناء قفزات غير متوقعة.
منع عناصر واجهة خطرة مثل select menus في سياقات معينة، وحظر محددات CSS التي قد تسمح بتلاعب غير مباشر.
تقييد طلبات الصور والوسائط ومنع تسريب البيانات عبر تحميل خارجي أو عبر نطاقات مسموحة (allow-listed domains) قد تُستغل للكشف عن “وقت/حقيقة العرض”.
البعد التنظيمي: أين تقع هذه المخاطر ضمن الأطر المعروفة؟
حتى لو لم تُذكر الأطر التنظيمية في نص البحث، فإن طبيعة المخاطر تقع ضمن مسؤوليات أمنية معروفة: حماية بيانات المستخدمين، تقليل مخاطر الاستيلاء على الحساب، والحد من تسريب الأسرار (Secrets) مثل رموز الوصول.
كمرجع عام، تُستخدم أطر مثل نموذج نضج دورة الحياة لمخاطر الويب ضمن برامج الامتثال، وغالبًا ما ترتبط السياسات الداخلية بمتطلبات مثل:
إدارة مخاطر الوصول (Access Control) وتقليل أثر اختطاف الجلسات.
حماية البيانات أثناء الاستخدام عبر تقنيات العزل.
ممارسات آمنة في هندسة الواجهات (Secure UI Rendering).
أما على مستوى أفضل الممارسات التقنية في الويب، ففكرة العزل والتعامل مع محتوى غير موثوق تُعد جوهرية في مفاهيم مثل Content Security Policy والعزل، رغم أن CSP وحدها لا تكفي عندما تكون المشكلة “من داخل DOM” لا “من خارج الشبكة”.
لمحة عن “تسريب عنوان IP” في Proton Mail: لماذا ما زال مهمًا؟
أُشير إلى مسار منفصل في Proton Mail يمكن أن يكشف عنوان IP للمستلم. البروتوكولات المتعلقة بحماية الخصوصية في البريد تستهدف تقليل كشف الوقت الدقيق لفتح الرسالة وعنوان IP، لكن الواقع العملي معقد: بعض الآليات (مثل تحميل موارد أو بروكسيات) قد تخلق آثارًا يمكن رصدها.
هذا يذكّرنا بأن الخصوصية ليست فقط “هل تم تسريب كلمة المرور؟” بل أيضًا: من أين تم فتح الرسالة؟ ومتى؟ ومن أي نمط اتصال؟، وهي معلومات قد تُستخدم في بناء ملف سلوكي (Profiling) أو في تحسين هجمات لاحقة.
إرشادات دفاعية عملية: ماذا يفعل مزود البريد أو مؤسسة تستخدمه؟
حتى إن لم تكن الجهة “مطوّر بريد”، يمكنها تقليل المخاطر عبر إجراءات تقلل احتمال نجاح الاستغلال أو أثره:
للمزودين: التزموا بمبدأ “لا ثقة في محتوى البريد” وطبّقوا العزل عبر sandboxed iframes، مع تدقيق صارم في مسارات التنقية والعرض.
للمؤسسات: فعّلوا سياسات تمنع تحميل الموارد الخارجية من البريد عند الإمكان، واستخدموا حلول حماية بريد (Secure Email Gateway) قادرة على تحليل HTML/CSS بشكل أعمق من مجرد فحص الروابط.
للحوكمة: راقبوا سلاسل التكامل (Integrations) بين البريد وأدوات مثل المساعدات/الذكاء الاصطناعي وموصلات التطبيقات؛ كثير من الهجمات تستغل خطوة “معالجة” لا “عرضًا”.
للمستخدمين: تقليل التفاعل مع محتوى البريد غير المتوقع (خصوصًا نسخ/لصق CSS أو إدخال بيانات في صفحات تُشبه تسجيل الدخول) يظل خط دفاع حقيقي، رغم أن الهجمات أصبحت أكثر تعقيدًا.
ملاحظة حول إثباتات الخدمة العامة: لماذا يجب أن نقلق حتى دون “استغلال واسع”؟
تذكر الأبحاث أن ورقة البحث قدمت PoC ولم تُبلّغ عن استغلال خبيث. ومع ذلك، أشارت إلى توفر [Public PoCs] وقتًا قريبًا من تاريخ البحث. تاريخيًا، غالبًا ما تتحول إثباتات التقنية إلى أدوات هجومية أسرع مما تتوقع الفرق، خاصة عندما تكون المشكلة “تصميم عرض” لا “ثغرة منطقية بسيطة”.
وبينما يقوم الباحثون بإظهار حدود العزل، يقوم المهاجمون بالبحث عن طرق لتجاوزها في بيئات مختلفة. لذا فإن أفضل قرار دفاعي هو اعتبار هذه الفئة من الهجمات “خطرًا مستمرًا” وليس حادثة عابرة.
سؤال للنقاش
إذا كانت رسائل البريد تستطيع—نظريًا ووفق إثباتات تقنية—التأثير في واجهة الويب الموثوقة أو دفع أدوات ذكاء اصطناعي مرتبطة بالبريد إلى تنفيذ خطوات غير مقصودة: فما الحد الفاصل الذي ينبغي أن تلتزم به أي خدمة بريد حديثة بين “محتوى غير موثوق” و“منطق واجهة موثوق”؟
Leave a Reply