no-transform と HTTPS でプロキシによるコンテンツ書き換えを制限する

コンテンツを変換するプロキシは、ブラウザへ向かう途中でレスポンスを変更できます。画像を再圧縮したり、マークアップを書き換えたり、補助的な JavaScript を挿入したりします。あるネットワークでは動作するページが、別のネットワークで見慣れないマークアップを受け取る場合、その中間者の挙動に遭遇している可能性があります。

運用しているサイトでは、HTTP が明示的なレスポンスディレクティブを提供します。

Cache-Control: no-transform

RFC 9111 は、このレスポンスディレクティブを受け取った中間者に対し、キャッシュを実装しているかどうかに関わらず、コンテンツを変換せずに残すことを求めています。これは画像の再圧縮やマークアップの挿入に関わるもので、オブジェクトが保存されるかどうかだけの話ではありません。

既存のキャッシュポリシーと一緒に保つ

レスポンスにすでにキャッシュディレクティブがある場合は、ポリシーの残りを捨てるのではなく、要件を意図的に追加します。たとえば、公開キャッシュ可能なアセットは次のようになります。

Cache-Control: public, max-age=3600, no-transform

この例は 1 時間の鮮度ポリシーを保ちながら、コンテンツ変換を禁止しています。no-transform は no-store を意味せず、通常の転送処理を無効にするものでもありません。元のコンテンツが重要なレスポンスに設定してください。必要に応じて個別の画像レスポンスにも設定します。

このディレクティブは中間者の遵守によって機能します。ネットワーク機器が指示を無視することを暗号学的に防ぐものではありません。

転送も保護する

HTTPS はブラウザに、TLS ピアに対する認証と完全性保護を備えた接続を提供します。暗号化されたトラフィックを通過させる通常のキャリアプロキシは、その保護された接続にスクリプトをこっそり挿入できません。証明書の検証は有効なままにしてください。TLS を終端するローカルに信頼された検査プロキシは別の構成です。

ページとその依存リソースを HTTPS で提供します。HTTP の訪問者を HTTPS にリダイレクトし、一貫してサポートできる配備では HSTS を検討してください。リダイレクトだけでは、HTTP URL を使った訪問者にとって最初のやり取りは保護されない HTTP になります。以前に学習した、またはプリロードされた HSTS ポリシーはその最初の選択を変えます。

挿入されたスクリプトをブロックしても、目に見える影響を減らせるだけかもしれません。レスポンスにはすでに変更された HTML や書き換えられた画像 URL が含まれている可能性があります。古い関数名を 1 つ置き換えたり、異常なコメントを追加したり、過去の挿入アドレスをマッピングしたりしても、次の中間者に対するコンテンツの完全性は確立されません。

報告を調査するときは、受信したレスポンスを配信元の意図したコンテンツと比較し、TLS がどこで終端するかを特定してください。その証拠は、見慣れないスクリプトをすべてサイト自身のアプリケーションコードの不具合とみなすより有用です。