VPN وصل شده اما محتوای ترکیبی هنوز مسدود است: چه چیزی را اصلاح کنیم

نیمی از صفحه رندر می‌شود، یک شیت استایل در پنل شبکه خاکستری می‌ماند، و کلاینت VPN هنوز تونل سالمی گزارش می‌دهد. هر سه مشاهده همزمان درست‌اند، چون مرورگر درخواستی را که صفحه ساخته بود داوری کرد و تونل در آن داوری رأیی نداشت. چیزی که پرونده را می‌بندد تصمیم است نه تنظیم: اصلاح ارجاع، ارجاع آن به مالک میزبان، یا رها کردن وابستگی. هر یک از این گزینه‌ها آزمون ارزانی دارد و انتخاب گزینه نادرست یک چرخه پشتیبانی می‌سوزاند.

چرا تونل نمی‌تواند یک منبع فرعی را پوشش دهد

محتوای ترکیبی با سندی HTTPS که منبع فرعی را از طریق HTTP ساده درخواست می‌کند آغاز می‌شود. هر URL بر اساس طرح خودش داوری می‌شود، بنابراین محافظت سند والد هرگز به درخواست فرزند گسترش نمی‌یابد. رمزنگاری‌ای که زیر مرورگر افزوده می‌شود چیزی را که روی سیم می‌رود تغییر می‌دهد، نه http:// را که نشانه‌گذاری خواسته بود.

مرورگرهای امروزی این درخواست‌ها را به دو گروه تقسیم می‌کنند و متفاوت با آن‌ها رفتار می‌کنند. اسکریپت‌ها، شیت‌های استایل، iframeها و فراخوانی‌های fetch، XMLHttpRequest یا WebSocket بی‌درنگ رد می‌شوند، بدون هیچ تلاش ارتقای پیشین. تصاویر، صدا و ویدیو به https:// بازنویسی و دوباره درخواست می‌شوند، و بارگذاری زمانی رها می‌شود که آن دریافت امن شکست بخورد. URL منبع فرعی که میزبانش یک نشانی IP خالی است از ارتقا معاف است، بنابراین یک تصویر HTTP روی میزبان IP مسدود می‌ماند به جای اینکه بی‌صدا اصلاح شود. این تقسیم، از جمله آن استثنا در سمت قابل ارتقا، در راهنمای Mozilla درباره محتوای ترکیبی مستند شده است. Chrome رد مشابهی را بر دانلودهای ناامن که از صفحه امن آغاز می‌شوند اعمال می‌کند، به همین دلیل یک پیوند PDF می‌تواند بمیرد در حالی که صفحه اطراف سالم به نظر می‌رسد.

پس سطر خاکستری گواهی بر کارکرد کنترل است، نه گواهی بر اینکه تونل متن روشن نشت داده است. با سطر مانند یافته‌ای برخورد کنید که به یک ارجاع اشاره می‌کند، نه به کل صفحه.

تعیین کنید ارجاع ناامن از آنِ کیست

URL مشکل‌دار را بر اساس جایی که تولید می‌شود مرتب کنید پیش از آنکه چیزی را تغییر دهید. آن پاسخ تعیین می‌کند که امروز می‌توانید اصلاحی منتشر کنید، یا یک تأمین‌کننده باید یکی منتشر کند، یا وابستگی باید صفحه را ترک کند. آن را در ستون Initiator در پنل شبکه بخوانید، چون نشانه‌گذاری روی صفحه اغلب در زمان اجرا مونتاژ می‌شود.

وقتی میزبان از قبل روی 443 پاسخ می‌دهد و تنها ارجاع می‌گوید http، اصلاح محلی است: ارجاع را تغییر دهید، حافظه نهان صفحه را پاک کنید و تأیید کنید که سطر https می‌شود. میزبانی که فقط روی پورت 80 گوش می‌دهد با ویرایش سازگار نمی‌شود، بنابراین منبع جابه‌جا می‌شود، چیزی که کنترل می‌کنید جلوی آن گذاشته می‌شود، یا ناپدید می‌شود. URL تزریق‌شده توسط مدیر برچسب حتی وقتی قالب خودتان پاک است ظاهر می‌شود، و آن مورد به تیکتی با URL دقیق و خط کنسول پیوست تعلق دارد. گفتن به کارکنان که محتوای ناامن را مجاز کنند یکی از این گزینه‌ها نیست، چون بررسی را برای هر سایتی که آن پروفایل مرورگر بازدید می‌کند خاموش می‌کند.

ارجاع را اصلاح کنید نه تنظیم مرورگر را

جریان ناموفق را با حفظ گزارش شبکه دوباره بارگذاری کنید و پنل را بر اساس میزبانی که مشکوکید فیلتر کنید. کنسول URL و دستورالعمل را نام می‌برد، که روشن می‌کند درخواست رد شده یا ارتقا یافته پیش از آنکه قالبی را لمس کنید.

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

دو کنترل پشتیبان ارزش دانستن دارند و هیچ‌کدام جای اصلاح را نمی‌گیرد. هدر Content-Security-Policy همراه با upgrade-insecure-requests مرورگر را وادار می‌کند URLهای منبع فرعی http را پیش از ترک صفحه بازنویسی کند، که ارجاع‌های قدیمی‌ای را می‌گیرد که هنوز نیافته‌اید. درخواست بازنویسی‌شده همچنان شکست می‌خورد وقتی میزبان هدف HTTPS ارائه نمی‌دهد، پس هدر فقط URLی را که مرورگر امتحان می‌کند تغییر می‌دهد. HSTS برای هر میزبان اعمال می‌شود، یعنی سیاستی روی دامنه خودتان برای CDN شخص ثالثی که هرگز هدر را نفرستاده هیچ کاری نمی‌کند. پس از تغییر قالب، حافظه نهان صفحه را پاک کنید و نام میزبان قدیمی را در HTML رندرشده جستجو کنید، چون همان URL می‌تواند از طریق یک جزء، رشته ترجمه یا فیلد پایگاه داده هم بیاید.

تغییرمسیرها را هم دنبال کنید، چون زنجیره‌ای که با https:// آغاز می‌شود می‌تواند در مکانی http:// فرود بیاید و مرورگر پرش آخر را داوری می‌کند. شکل -L دستور دوم بالا آن URL مؤثر را برای شما چاپ می‌کند. اگر پرش آخر http خالص باشد، ارجاع همچنان نادرست است حتی اگر پیوندی که ویرایش کردید خوب به نظر می‌رسید.

صفحه را با کنسول و پنل شبکه تأیید کنید

با حافظه نهان خاموش دوباره بارگذاری کنید و جریان را دوباره بگذرانید، از جمله دکمه‌هایی که محتوا را بر حسب تقاضا بار می‌کنند. نخستین بارگذاری صفحه ابزارک‌های تنبل، کاشی‌های نقشه و اسکریپت‌های پخش‌کننده را پنهان می‌کند که فقط پس از کلیک ظاهر می‌شوند. کنسول نباید هیچ ورودی محتوای ترکیبی داشته باشد و هر سطری که لمس کردید باید https نشان دهد. کنسول و سطر درخواست را پیش از بستن تیکت ثبت کنید، چون بازسازی آن وضعیت پس از استقرار بعدی دشوار است.

وقتی منبع به شخص دیگری تعلق دارد، چهار چیز بفرستید: URL دقیق، نوع درخواست، متن کنسول و صفحه‌ای که در آن ظاهر می‌شود. شناسه‌های نشست را در هر چیزی که در تیکت می‌چسبانید پنهان کنید. گزارشی که فقط می‌گوید تصاویر خراب‌اند چیزی برای جستجو به مالک نمی‌دهد.

تونل همچنان کار خودش را می‌کند در حالی که اصلاح در ارجاعی است که درخواست را تولید کرد. پس از استقرار، نام میزبان را یک بار دیگر در قالب و بسته تأمین‌کننده جستجو کنید، و پرونده را فقط زمانی ببندید که هیچ ورودی محتوای ترکیبی مسدودی در کنسول باقی نمانده باشد.