تسربات IP و DNS في WebKit: خطر يهدد خصوصية متصفحات الوكيل و iCloud Private Relay

تُصمم المتصفحات المبنية على WebKit في نظامي iOS و macOS لتوجيه كل حركة المرور عبر خوادم وكيلة (بروكسي)، وهو ما تعتمد عليه متصفحات Tor في iOS ومتصفح Psylo الخاص بنا. ومع ذلك، اكتشفنا ثلاث ميزات في WebKit تتجاوز إعدادات الوكيل المُحددة وترسل البيانات مباشرة من الجهاز، مما يكشف عن الشبكة الحقيقية للمستخدم وعنوان IP الخاص به. هذه التسربات تؤثر أيضاً على خدمة iCloud Private Relay من Apple. لحسن الحظ، تم إصلاح هذه المشكلات الثلاث في الإصدار 1.3.1 من Psylo.

ملخص شامل لتسربات WebKit

تُبنى المتصفحات التي تعتمد على WebKit في نظامي iOS و macOS لتوجيه جميع حركة مرور الويب عبر خوادم وكيلة. هذا هو مبدأ عمل جميع متصفحات الوكيل على iOS، بما في ذلك متصفحات Tor ومتصفح Psylo الخاص بنا. من المفترض أن يمر كل اتصال شبكي يقوم به أي موقع إلكتروني عبر الوكيل المُعد، بحيث لا ترى المواقع سوى عنوان IP الخاص بالوكيل. ومع ذلك، اكتشفنا ثلاث ميزات في WebKit تتجاوز إعدادات الوكيل وترسل حركة المرور مباشرة من الجهاز بدلاً من ذلك:

• استباق جلب DNS: يقوم بحل أسماء النطاقات عبر مسار DNS الطبيعي للجهاز، مما يكشف خوادم DNS الحقيقية للمستخدم بدلاً من خادم الوكيل. متوفر منذ iOS 26.0.
• طلبات الأصل المرتبطة بـ WebAuthn: تجعل خدمة بيانات الاعتماد في نظام التشغيل تجلب ملف تحقق مباشرة من الجهاز، مما يكشف عنوان IP الحقيقي للجهاز. متوفر منذ iOS 18.0.
• WebTransport: يفتح اتصال HTTP/3 مباشراً ويتجاوز الوكيل، مما يكشف أيضاً عنوان IP الحقيقي للجهاز. متوفر منذ iOS 26.4.

تؤثر هذه التسربات أيضاً على خدمة iCloud Private Relay من Apple. تجدر الإشارة إلى أن شبكات VPN غير متأثرة بهذه المشكلات، لأنها تقوم بتوجيه حركة مرور الشبكة بالكامل على مستوى النظام.

لقد تواصلنا مع مشروع Tor ومطوري متصفح Onion على iOS بخصوص هذه المشكلات. للتحقق من هذه التسربات، يمكنكم زيارة موقعنا التجريبي leaks.psylo.app.

تم حل هذه المشكلات في Psylo 1.3.1: يقوم Psylo الآن بحظر تلميحات dns-prefetch ويقوم بتعطيل WebTransport و WebAuthn بشكل افتراضي. بالنسبة للمواقع التي تتطلب هذه الميزات، يمكن إعادة تمكين كل منها يدوياً عبر مفاتيح تبديل لكل حساب (silo)، مما يمنح المستخدمين التحكم الكامل في توازنات الخصوصية والأداء.

خلفية المشكلة: كيف تحدث التسربات

إعدادات الوكيل في iOS و macOS

تم تقديم واجهة برمجة التطبيقات WKWebsiteDataStore.proxyConfigurations في iOS 17 و macOS 14، وهي تسمح للمتصفحات المبنية على WebKit بتوجيه جميع حركة مرور الويب الخاصة بها عبر خوادم وكيلة على مستوى التطبيق. تُعد هذه الواجهة أساس متصفحات الوكيل على iOS: فمن المفترض أن يمر كل اتصال شبكي يقوم به موقع ويب عبر الوكيل المُعد، بحيث لا ترى المواقع سوى عنوان IP الخاص بالوكيل.

تسرب DNS أبلَغ عنه مستخدم لـ Psylo

بدأ هذا التحقيق بتقرير خطأ من مستخدم لـ Psylo لاحظ تسربات DNS عند زيارة مواقع ويب معينة فقط، مما دفعنا للتحقيق الفوري. بعد بحث معمق، وجدنا مصدر تسربات DNS، بالإضافة إلى تسربين آخرين يكشفان عن عنوان IP الحقيقي للجهاز. توجد هذه التسربات الثلاثة في WebKit، حيث تتجاوز إعدادات الوكيل المقدمة بواسطة WKWebsiteDataStore.proxyConfigurations. نظراً لأن سياسة متجر تطبيقات Apple تتطلب من كل متصفح iOS استخدام WebKit، فإن أي متصفح iOS يعتمد على هذه الواجهة للوكالة يتأثر، بما في ذلك جميع متصفحات Tor على iOS و Psylo. هذه التسربات موجودة أيضاً في خدمة iCloud Private Relay من Apple. في المقابل، لا تتأثر شبكات VPN بهذه المشكلات، لأن حركة مرور الشبكة بالكامل للجهاز يتم توجيهها عبر VPN على مستوى النظام.

خدمة iCloud Private Relay

iCloud Private Relay هي ميزة خصوصية من Apple لمشتركي iCloud+. عند تمكينها، تقوم هذه الخدمة بتوجيه حركة مرور الويب واستعلامات DNS الخاصة بمتصفح Safari (فقط) عبر مرحلتين من التوجيه، مصممة بحيث لا يمكن لأي طرف واحد، حتى Apple، رؤية هويتك والمواقع التي تزورها في نفس الوقت. ولكن، اتضح أن التسربات الثلاثة الموضحة في هذه المقالة تحدث خارج عملية تحميل الصفحة القياسية في WebKit، مما يعني أن Private Relay عرضة لنفس التسربات.

1. استباق جلب DNS: كشف خوادم DNS الحقيقية

يسمح استباق جلب DNS لموقع ويب بطلب من المتصفح حل اسم نطاق قبل الحاجة إليه، مما يسرع عملية الاتصال لاحقاً. يتم ذلك عبر وسم HTML مثل . عندما تتضمن صفحة هذا الوسم، يقوم WebKit بحل اسم النطاق عبر مسار DNS الطبيعي للجهاز، بغض النظر عن أي وكيل تم إعداده بواسطة المتصفح عبر WKWebsiteDataStore.proxyConfigurations. يمكن لصفحة أن تُضمّن أسماء نطاقات فريدة لكل زائر في هذه الوسوم، ثم تراقب الاستعلامات وهي تصل إلى خادم DNS الموثوق الخاص بها من الشبكة الحقيقية للزائر بدلاً من شبكة الوكيل.

كان هذا هو التسرب وراء تقرير المستخدم الأصلي، ويفسر لماذا أثر على بعض المواقع فقط: فبدون وسم الاستباق في الصفحة، لا يقوم WebKit بهذا البحث عن DNS. لا تستطيع Private Relay اكتشاف هذا التسرب. يصل الاستعلام إلى الخادم الموثوق من الشبكة الحقيقية للجهاز حتى مع تمكين Private Relay.

2. طلبات الأصل المرتبطة بـ WebAuthn: كشف عنوان IP الجهاز

WebAuthn هو المعيار الويب وراء مفاتيح المرور (passkeys). يرتبط مفتاح المرور عادةً بنطاق واحد، لكن طلبات الأصل المرتبطة تسمح للمؤسسة باستخدام مفتاح مرور واحد عبر مجموعة صغيرة من النطاقات التي تمتلكها. لجعل ذلك يعمل، عندما تطلب صفحة بيانات اعتماد يختلف rpId الخاص بها عن أصلها، يقوم العميل أولاً بجلب ملف https:///.well-known/webauthn، وهو ملف JSON يسرد الأصول التي قد تستخدم rpId هذا.

هذا الجلب للتحقق لا يأتي من مكدس شبكة المتصفح. يقوم WebKit بتسليم عمليات WebAuthn إلى خدمة بيانات الاعتماد في نظام التشغيل، والتي تصدر طلب HTTPS بنفسها، مباشرة من الجهاز ودون علم بأي وكيل قام التطبيق المضيف بإعداده. يمكن لصفحة تعيين rpId إلى مضيف من اختيارها، ويتم إطلاق الجلب حتى بدون تفاعل المستخدم. ينطبق نفس المنطق على iCloud Private Relay. لأن الجلب يتم إصداره بواسطة خدمة بيانات الاعتماد في نظام التشغيل بدلاً من Safari، فإنه لا يدخل أبداً المسار الوكيلي لـ Private Relay. يرى الخادم المستهدف عنوان IP الحقيقي للجهاز في كلتا الحالتين.

3. WebTransport: تجاوز الوكيل عبر اتصالات HTTP/3 المباشرة

WebTransport هو بديل منخفض زمن الاستجابة لـ WebSocket. يعمل عبر HTTP/3 و QUIC، ويوفر تدفقات متعددة مستقلة بالإضافة إلى تسليم بيانات غير موثوق به (unreliable datagram delivery)، ويمكن أن يعود إلى HTTP/2 حيث لا يتوفر QUIC. يؤدي استدعاء new WebTransport(url) إلى فتح اتصال QUIC مباشرة من الجهاز. ينشئ WebKit الاتصال بمعاملات شبكته الخاصة ولا يقدم له وكيل الجلسة أبداً، لذلك يرى الخادم عنوان IP الحقيقي للجهاز بدلاً من الوكيل.

لا تساعد Private Relay هنا أيضاً. يقوم WebKit بإنشاء الاتصال خارج حركة مرور الويب التي تقوم Private Relay بتوكيلها، لذلك يتعرف خادم WebTransport على عنوان IP الحقيقي للجهاز حتى مع تمكين Private Relay. يوجد استثناء واحد: مستوى الأمان Silver في متصفح Onion يقوم بتهيئة WebKit بوضع الإغلاق (Lockdown Mode)، الذي يعطل WebTransport بالكامل، لذلك لا يتأثر مستخدمو متصفح Onion الذين يستخدمون مستوى Silver بهذا التسرب المحدد.

الإصلاحات المقدمة في Psylo 1.3.1

لقد عالجنا جميع التسربات الثلاثة في Psylo 1.3.1 عبر الإجراءات التالية:

• يقوم Psylo بحظر تلميحات dns-prefetch، بحيث لا يمكن لصفحة بعد الآن أن تجعل جهازك يحل أسماء نطاقات يتحكم فيها مهاجمون.
• تم تعطيل WebTransport بشكل افتراضي.
• تم تعطيل WebAuthn بشكل افتراضي.

لمفاتيح المرور (Passkeys) و WebTransport استخدامات مشروعة، لذلك يمكن إعادة تمكينهما في أي وقت من خلال مفاتيح تبديل مخصصة لكل حساب (silo). هذا يحافظ على Psylo خالياً من التسربات بشكل افتراضي، بينما يمكن للمستخدمين الذين يحتاجون إحدى هذه الميزات على موقع معين تمكينها بشكل صريح، مع فهم واضح للمقايضة بين الأمان والوظائف.

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