في 4 أغسطس 2026، نشر باحثو Mysk تحليلًا لثلاث آليات في WebKit التي ترسل حركة المرور متجاوزة الوكيل المُعد — مباشرة من الجهاز. كانت جميع متصفحات iOS التي تستخدم وضع الوكيل، بما في ذلك متصفحات Tor، تحت الضغط، بالإضافة إلى خدمة Apple الخاصة — iCloud Private Relay. الوكيل مفعل، والواجهة تظهر بلدًا آخر، ولكن الموقع يرى عنوان IP الحقيقي الخاص بك ومحلل DNS المنزلي الخاص بك.
هذه ليست ثغرة غريبة للمهووسين. إنها عرض توضيحي واضح لقاعدة معمارية يجب أن يتقنها كل من يعمل عبر الوكيل: الوكيل على مستوى التطبيق يحمي فقط حركة المرور التي تمر عبر كومة الشبكة لهذا التطبيق. كل ما تنتجه نظام التشغيل أو خدمة نظامية منفصلة يمر دون أن يُلاحظ.
ما الذي يتسرب بالضبط
بدأ البحث بحالة منزلية: اشتكى مستخدم متصفح Psylo من تسرب DNS للمطور. كشف تحليل الشكوى عن ثلاث قنوات تسرب مستقلة — جميعها موجودة في WebKit نفسه، وليس في التطبيق المحدد.
1. DNS prefetching — الأسهل والأكثر إزعاجًا
آلية: علامة <link rel="dns-prefetch"> تطلب من المتصفح حل اسم المضيف مسبقًا لتسريع التحميل المستقبلي. المشكلة هي أن WebKit على iOS يحل مثل هذه الأسماء عبر مسار DNS العادي للجهاز، وليس عبر الوكيل.
يدعم Safari على سطح المكتب dns-prefetch منذ Safari 5، لكن iOS تجاهل هذه العلامة — حتى iOS 26.0 (سبتمبر 2025). حينها، قام WebKit بتفعيلها كجزء من نفس التغيير الذي أزال DNS prefetching التخميني القديم (خطأ 285744).
كيف يتم استغلال ذلك: تقوم الصفحة بإدخال أسماء مضيفين فريدة لكل زائر في مثل هذه العلامات، ثم ببساطة تراقب كيف تأتي الطلبات إلى خادم DNS الخاص بها — من عنوان الشبكة الحقيقي للزائر. لا حاجة لجافا سكريبت، ولا تفاعل مع المستخدم. يكفي فتح الصفحة.
2. WebAuthn Related Origin Requests — تسرب عبر جواز سفر من passkey
ظهرت هذه القناة في iOS 18.0. عندما يطلب الموقع بيانات اعتماد WebAuthn (أي passkey)، تذهب النظام للتحقق من الملف https://<rpId>/.well-known/webauthn — للتأكد من أن النطاق مرتبط فعلاً بالطرف المعتمد المحدد.
التفصيل الرئيسي: هذا الطلب التحقق لا يخرج من كومة الشبكة للمتصفح. يتم تنفيذه بواسطة خدمة بيانات الاعتماد في نظام التشغيل، التي ترسل طلب HTTPS مباشرة من الجهاز. الوكيل المُعد داخل المتصفح لا يعرف عنه ببساطة (خطأ 268426).
أي أنه يكفي أن تبدأ الصفحة طلب passkey — ويحصل خادم المهاجم على اتصال من عنوان IP الحقيقي الخاص بك.
3. WebTransport — QUIC مباشرة من الجهاز
أحدث قناة. يستدعي new WebTransport(url) اتصال QUIC مباشرة من الجهاز، متجاوزًا تكوين الوكيل. ظل WebTransport في WebKit مغلقًا لفترة طويلة وظهر علنًا في iOS 26.4 في مارس 2026 (الأخطاء 260810 و303453).
من يهم هذا
تتطلب Apple أن تستخدم جميع المتصفحات على iPhone WebKit. وبالتالي، سيتأثر كل متصفح iOS يعتمد على واجهة برمجة التطبيقات الخاصة بـ WebKit — بما في ذلك جميع إصدارات متصفحات Tor على iOS وPsylo نفسه، الذي بدأ التحقيق. بالإضافة إلى Safari وiCloud Private Relay.
ما لا يتأثر — تطبيقات VPN. تعمل على مستوى النظام وتغلف كل حركة مرور الجهاز بالكامل، بما في ذلك تلك التي تنتجها خدمات النظام. هذه هي جوهر الفرق: لا يوجد "خارج" في النفق النظامي. استثناء منفصل — متصفح Onion على مستوى الأمان Silver مع تفعيل وضع Lockdown: فهو غير معرض للتسرب عبر WebTransport.
من جانب المطورين، هناك بالفعل رد فعل. في Psylo 1.3.1، تم إغلاق جميع القنوات الثلاث: التطبيق يمنع اقتراحات dns-prefetch (لم تعد الصفحة قادرة على إجبار الجهاز على حل أسماء تحت سيطرة المهاجم)، وتم إيقاف WebTransport وWebAuthn بشكل افتراضي — يمكن تفعيلها بشكل انتقائي، عبر مفاتيح منفصلة. وفقًا للمعلومات المتاحة عند النشر، يجب على Apple معالجة المشكلات في التحديث المستقبلي؛ لم تحدد الشركة مواعيد محددة.
لماذا ظهرت هذه المشكلة الآن فقط
التسلسل الزمني هنا دال، ويستحق التحليل بشكل منفصل — فهو يفسر لماذا لم يتم ملاحظة المشكلة من قبل.
- سبتمبر 2024، iOS 18.0 — يظهر آلية WebAuthn Related Origin Requests. قناة التسرب موجودة منذ ما يقرب من عامين ولم يتم مناقشتها من قبل: تحقق النطاق لـ passkey يبدو كعنصر أمان، وليس كوسيلة لكشف العنوان.
- سبتمبر 2025، iOS 26.0 — يقوم WebKit بتفعيل دعم dns-prefetch على الأجهزة المحمولة. رسميًا، هذه تحسين لسرعة التحميل؛ في الواقع — تحصل الصفحة على القدرة على إجبار الجهاز على الاتصال باسم DNS عشوائي متجاوزًا الوكيل.
- مارس 2026، iOS 26.4 — يتم تفعيل WebTransport علنًا. القناة الثالثة.
- أغسطس 2026 — شكوى من مستخدم واحد عن تسرب DNS تؤدي إلى تحليل يكشف جميع الثلاثة دفعة واحدة.
المشترك: لم يتم تصميم أي من هذه الوظائف كقناة لكشف الهوية. جميعها — ميزات عادية للمنصة: تسريع الحل، تحقق من passkey، نقل حديث. تصبح تسربًا فقط عند الجمع مع وضع الوكيل على مستوى التطبيق، ولهذا السبب لم يتم التحقق منها على هذا الأساس لسنوات.
الاستنتاج العملي بسيط وغير مريح: عدم وجود أخبار عن التسريبات لا يعني عدم وجودها. يجب التحقق بنفسك وبشكل منتظم، وليس الانتظار حتى ينشر شخص ما تحليلًا.
كيف تتحقق من نفسك
نشر الباحثون منصة عامة — leaks.psylo.app. تتحقق من ثلاث أشياء: حركة مرور HTTPS العادية (أي عنوان IP وأي محللات DNS يراها الخادم)، WebTransport وارتباط WebAuthn + dns-prefetch. افتحها مع تفعيل الوكيل وقارن النتيجة مع العنوان الذي تتوقع رؤيته.
من المهم أيضًا التحقق من النظافة الأساسية — هل يتطابق عنوان IP وDNS وعنوان WebRTC في مجموعتك العملية. إذا لم تكن قد قمت بذلك بشكل منهجي من قبل، ابدأ بتحليلنا: كيف تتحقق من الوكيل من تسرب DNS.
الاستنتاج العملي: الطبقة لها أهمية
قصة WebKit هي حالة خاصة من قاعدة عامة يجب أن تبقى في الذهن عند العمل عبر الوكيل، على أي منصة.
- الوكيل في المتصفح ≠ الوكيل على الجهاز. الإعداد داخل التطبيق يغطي فقط حركة المرور التي يرسلها التطبيق نفسه. الخدمات النظامية، العمليات الخلفية، التحديثات، اتصالات الدفع، وكما اتضح، خدمة passkey المدمجة — كل ذلك يسير في طريقه الخاص.
- التسريبات تحدث ليس فقط في الأماكن "المعروفة". WebRTC معروف منذ فترة، وقد تعلم الناس كيفية سد ثغراته. بينما dns-prefetching والتحقق من WebAuthn — هي ميزات للأداء والأمان، لم يعتبرها أحد كقناة لكشف الهوية. الميزات الجديدة في المتصفحات تخلق بانتظام طرقًا جديدة للتجاوز.
- تحديث المنصة يمكن أن يكسر حمايتك بصمت. هنا، يمكن رؤية ذلك حرفيًا من خلال التواريخ: تم "تفعيل" dns-prefetching في iOS 26.0، وWebTransport في iOS 26.4. لم يغير المستخدم شيئًا، ولكن سطح التسرب زاد بنفسه.
ماذا يعني هذا بالنسبة للاستخدام المتعدد للحسابات والأتمتة
بالنسبة لأولئك الذين يديرون عدة حسابات أو يجمعون البيانات، فإن المخاطر هنا ليست مجرد خصوصية مجردة، بل هي مالية تمامًا. تقوم أنظمة مكافحة الاحتيال في المنصات بمقارنة الإشارات: إذا كانت الجلسة تعلن عن عنوان IP واحد، بينما يأتي الطلب المصاحب من عنوان آخر ومن محلل منزلي، فهذا سبب كافٍ لربط الحسابات معًا أو وضع علامة على الجلسة كمشبوهة.
النتائج العملية:
- لا تدير جلسات متعددة الحسابات في متصفحات الهاتف المحمول مع وضع الوكيل. حتى تغلق المنصة الثغرات، فإن طبقة التطبيق على iOS غير موثوقة بطبيعتها.
- قم بتغليف حركة المرور على مستوى النظام. إذا كانت المهمة هي بيئة الهاتف المحمول، فمن الأفضل إعداد الوكيل على مستوى الجهاز أو توجيه الحركة عبر بوابة منفصلة، بدلاً من الاعتماد على الإعداد داخل المتصفح.
- تحقق من المجموعة بعد كل تحديث كبير لنظام التشغيل والمتصفح. مرة واحدة في الربع — على الأقل. اجعل ذلك في قائمة التحقق الخاصة بك، وليس "عندما يحدث شيء خاطئ".
- قم بإيقاف تشغيل ما لا تستخدمه. WebTransport وWebAuthn في الملف الشخصي العملي لجمع البيانات أو SMM لا تحتاج تقريبًا — إيقاف تشغيلها يزيل قناتين من التسرب من ثلاث.
تظل جودة عنوان IP نفسه متغيرًا منفصلًا: حتى مع تكوين محكم، يمكن أن يكشف عنوان مركز البيانات عن نفسه من خلال ASN. بالنسبة للسيناريوهات التي من المهم أن تبدو كأنك مستخدم عادي، تعمل الوكالات السكنية، ولتطبيقات الهاتف المحمول والمنصات ذات أنظمة مكافحة الاحتيال الأكثر صرامة — الوكالات المحمولة مع عناوين من مشغلي الشبكات الحقيقية. لكن لا يمكن لأي نوع من الوكالات أن ينقذك إذا كانت جزء من حركة المرور تمر فعليًا بجانبه — أولاً، يجب أن تكون محكمًا، ثم جودة العنوان.
الخلاصة
أظهرت ثلاث ثغرات في WebKit — DNS prefetching، WebAuthn Related Origin Requests وWebTransport — أن "الوكيل مفعل" و"كل حركة المرور تمر عبر الوكيل" هما ادعاءان مختلفان. على iOS، كان الفجوة بينهما واسعة بما يكفي لكي تتمكن صفحة ويب عادية دون سطر واحد من جافا سكريبت من معرفة العنوان الحقيقي لزائر متصفح Tor.
بينما تستعد Apple لإصلاح، فإن الاستراتيجية الوحيدة الفعالة هي التحقق، وليس الافتراض. افتح منصة الاختبار، قارن العناوين، وأوقف تشغيل واجهات برمجة التطبيقات الزائدة. واعتبر كل تحديث كبير لنظام التشغيل كحدث، بعده يجب إعادة التحقق من التكوين. غالبًا ما تتكون الفجوة بين الخصوصية ووهمها من سؤال واحد لم يُطرح في الوقت المناسب: "هل كل حركة المرور حقًا؟". من المفيد أيضًا فهم أي إشارات أخرى تكشف عنك بخلاف العنوان — وقد كتبنا عن ذلك في المادة حول الحماية من بصمة المتصفح.