محتوای مختلط پشت VPN: منبع را درست کنید، نه تونل را

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

درخواست را بخوانید، نه نوار نشانی را

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

نامیدن منبع به‌عنوان صرفاً یک فایل گنجانده‌شده جایگزینی آن را بی‌خطر نمی‌کند.

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

بدانید کدام منابع مسدود و کدام ارتقا می‌یابند

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

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

ابزارک مسدودشده شاهدی بر شکست تونل نیست. شاهدی بر این است که مرورگر کارش را انجام داده است.

ارجاع را در منبعش اصلاح کنید

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

سپس تأیید کنید که منبع واقعاً با هویت معتبر از طریق HTTPS ارائه می‌شود، زیرا تغییر طرح نمی‌تواند سرویسی را که هرگز آنجا منتشر نشده از خود بسازد.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

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

صفحه را همان‌گونه که کاربران لمس می‌کنند دوباره آزمایش کنید

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

تونل هنوز کار خودش را دارد و آن کار دسترسی به شبکه است، نه یکپارچگی صفحه.

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