۴ اوت ۲۰۲۶، محققان Mysk تجزیه و تحلیل سه مکانیزم WebKit را منتشر کردند که ترافیک را دور از پروکسی تنظیم شده — مستقیماً از دستگاه ارسال میکند. همه مرورگرهای iOS با حالت پروکسی، از جمله مرورگرهای Tor و همچنین سرویس خود اپل — iCloud Private Relay تحت تأثیر قرار گرفتند. پروکسی فعال است، رابط کاربری کشور دیگری را نشان میدهد، در حالی که وبسایت آدرس IP واقعی و DNS-رزولور خانگی شما را میبیند.
این یک آسیبپذیری عجیب و غریب برای پارانوئیدها نیست. این یک نمایش واضح از قاعده معماری است که باید توسط همه کسانی که از طریق پروکسی کار میکنند، درک شود: پروکسی در سطح برنامه فقط ترافیکی را که از طریق استک شبکه آن برنامه عبور میکند، محافظت میکند. هر چیزی که سیستمعامل یا یک سرویس سیستمی جداگانه تولید کند، از آن عبور میکند.
چه چیزی در حال نشت است
تحقیق با یک وضعیت روزمره آغاز شد: کاربر مرورگر پروکسی Psylo به توسعهدهندهای درباره نشت DNS شکایت کرد. بررسی شکایت سه کانال نشت مستقل را فاش کرد — همه آنها در خود WebKit نهفتهاند، نه در یک برنامه خاص.
۱. DNS prefetching — سادهترین و ناخوشایندترین
مکانیزم: تگ <link rel="dns-prefetch"> از مرورگر میخواهد که نام میزبان را از قبل حل کند تا بارگذاری آینده را تسریع کند. مشکل این است که WebKit در iOS چنین نامهایی را از طریق مسیر DNS معمولی دستگاه حل میکند، نه از طریق پروکسی.
مرورگر دسکتاپ Safari از زمان Safari 5 از dns-prefetch پشتیبانی میکند، اما iOS این تگ را نادیده میگرفت — تا iOS 26.0 (سپتامبر ۲۰۲۵). در آن زمان WebKit آن را در چارچوب همان تغییراتی که DNS-prefetching غیرمستقیم قدیمی را حذف کرد، فعال کرد (بگ ۲۸۵۷۴۴).
چگونه این مورد سوءاستفاده قرار میگیرد: صفحه در این تگها نامهای میزبان منحصر به فرد برای هر بازدیدکننده را جاسازی میکند و سپس به سادگی مشاهده میکند که درخواستها به سرور DNS معتبر خودشان میرسند — از آدرس واقعی شبکه بازدیدکننده. هیچ JavaScript، هیچ تعامل با کاربر. کافی است صفحه را باز کنید.
۲. WebAuthn Related Origin Requests — نشت از طریق پاسپورت از passkey
این کانال از iOS 18.0 ظاهر شد. هنگامی که وبسایت اطلاعات WebAuthn (یعنی passkey) را درخواست میکند، سیستم به بررسی فایل https://<rpId>/.well-known/webauthn میپردازد — تا اطمینان حاصل کند که دامنه واقعاً با طرف وابسته مشخص شده مرتبط است.
جزئیات کلیدی: این درخواست تأیید از استک شبکه مرورگر نمیآید. این درخواست توسط سرویس اعتبارنامههای سیستمعامل انجام میشود که خود HTTPS-request را مستقیماً از دستگاه ارسال میکند. پروکسی تنظیم شده در داخل مرورگر از آن بیخبر است (بگ ۲۶۸۴۲۶).
به عبارت دیگر، کافی است که صفحه یک درخواست passkey را آغاز کند — و سرور مهاجم اتصال را از آدرس IP واقعی شما دریافت میکند.
۳. WebTransport — QUIC مستقیماً از دستگاه
جدیدترین کانال. فراخوانی new WebTransport(url) یک اتصال QUIC را مستقیماً از دستگاه باز میکند و پیکربندی پروکسی را دور میزند. WebTransport در WebKit برای مدت طولانی غیرفعال بود و بهطور عمومی در iOS 26.4 در مارس ۲۰۲۶ منتشر شد (بگهای ۲۶۰۸۱۰ و ۳۰۳۴۵۳).
این موضوع چه کسانی را تحت تأثیر قرار میدهد
اپل از همه مرورگرها در iPhone میخواهد که از WebKit استفاده کنند. بنابراین، هر مرورگر iOS که به API پروکسی WebKit وابسته است، تحت تأثیر قرار میگیرد — از جمله تمام نسخههای iOS مرورگرهای Tor و خود Psylo که تحقیق از آن آغاز شد. به علاوه Safari و iCloud Private Relay.
چیزی که تحت تأثیر قرار نمیگیرد — برنامههای VPN. آنها در سطح سیستم کار میکنند و تمام ترافیک دستگاه را بهطور کامل میپیچند، از جمله آنچه که توسط خدمات سیستمی تولید میشود. این اساس تفاوت است: تونل سیستمی هیچ «دور» ندارد. یک استثنای جداگانه — Onion Browser در سطح امنیتی Silver با فعالسازی Lockdown Mode: این برنامه نسبت به نشت از طریق WebTransport مقاوم است.
از سوی توسعهدهندگان، واکنشها وجود دارد. در Psylo 1.3.1 همه سه کانال بسته شدهاند: برنامه پیشنهادات dns-prefetch را مسدود میکند (صفحه دیگر نمیتواند دستگاه را وادار به حل نامهای تحت کنترل مهاجم کند)، و WebTransport و WebAuthn بهطور پیشفرض غیرفعال هستند — میتوان آنها را بهطور دقیق با سوئیچهای جداگانه فعال کرد. بر اساس اطلاعات در زمان انتشار، اپل باید مشکلات را در بهروزرسانی آینده برطرف کند؛ شرکت زمانهای خاصی را اعلام نکرده است.
چرا این موضوع فقط اکنون مطرح شده است
زمانبندی در اینجا قابل توجه است و باید بهطور جداگانه بررسی شود — این توضیح میدهد که چرا مشکل قبلاً مشاهده نشده است.
- سپتامبر ۲۰۲۴، iOS 18.0 — مکانیزم WebAuthn Related Origin Requests ظاهر میشود. کانال نشت تقریباً دو سال وجود دارد و در تمام این مدت هیچکس درباره آن بحث نکرده است: بررسی دامنه برای passkey بهعنوان یک عنصر امنیتی به نظر میرسد، نه بهعنوان یک روش برای افشای آدرس.
- سپتامبر ۲۰۲۵، iOS 26.0 — WebKit پشتیبانی از dns-prefetch را در دستگاههای موبایل فعال میکند. بهطور رسمی این یک بهینهسازی سرعت بارگذاری است؛ در واقع — صفحه این امکان را پیدا میکند که دستگاه را وادار کند به یک نام DNS دلخواه به دور از پروکسی مراجعه کند.
- مارس ۲۰۲۶، iOS 26.4 — WebTransport بهطور عمومی فعال میشود. سومین کانال.
- اوت ۲۰۲۶ — شکایت یک کاربر درباره نشت 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 فاش میکند. برای سناریوهایی که مهم است که بهعنوان یک کاربر عادی به نظر برسید، پروکسیهای مسکونی کار میکنند، و برای برنامههای موبایل و پلتفرمهایی با سختترین ضد تقلب — پروکسیهای موبایل با IP اپراتورهای واقعی. اما هیچ کلاسی از پروکسی نمیتواند نجات دهد، اگر بخشی از ترافیک بهطور فیزیکی از آن عبور کند — ابتدا محکم بودن، سپس کیفیت آدرس.
نتیجهگیری
سه باگ WebKit — DNS prefetching، WebAuthn Related Origin Requests و WebTransport — نشان دادند که «پروکسی فعال است» و «تمام ترافیک از طریق پروکسی میرود» دو ادعای متفاوت هستند. در iOS، شکاف بین آنها به اندازهای وسیع بود که یک صفحه وب معمولی بدون یک خط JavaScript میتوانست آدرس واقعی بازدیدکننده مرورگر Tor را شناسایی کند.
تا زمانی که اپل در حال آمادهسازی اصلاحات است، تنها استراتژی کارا — بررسی کردن و نه فرض کردن است. ایستگاه آزمایشی را باز کنید، آدرسها را مقایسه کنید، APIهای اضافی را غیرفعال کنید. و به هر بهروزرسانی بزرگ سیستمعامل بهعنوان یک رویداد نگاه کنید که پس از آن باید پیکربندی را دوباره بررسی کنید. تفاوت بین حریم خصوصی و توهم آن اغلب دقیقاً در یک سوال بهموقع مطرح نشده است: «آیا واقعاً تمام ترافیک است؟». همچنین مفید است که بدانید چه سیگنالهای دیگری به جز آدرس شما را فاش میکنند — درباره این موضوع در مقالهای درباره محافظت در برابر فینگرپرینتینگ مرورگر نوشتیم.