Ogranicz przepisywanie treści przez proxy za pomocą no-transform i HTTPS

Proxy transformujące treść może zmienić odpowiedź w drodze do przeglądarki: ponownie skompresować obraz, przepisać znaczniki lub wstawić pomocniczy JavaScript. Strona, która działa w jednej sieci, a w innej otrzymuje nieznane znaczniki, może napotykać właśnie takie zachowanie pośrednika.

Dla witryny, którą obsługujesz, HTTP udostępnia wyraźną dyrektywę odpowiedzi:

Cache-Control: no-transform

RFC 9111 wymaga, aby pośrednik otrzymujący tę dyrektywę odpowiedzi pozostawił treść nieprzetworzoną, niezależnie od tego, czy implementuje pamięć podręczną. Dotyczy to ponownej kompresji obrazów i wstrzykiwania znaczników, nie tylko tego, czy obiekt zostanie zapisany.

Zachowaj ją wraz z istniejącą polityką pamięci podręcznej

Jeśli odpowiedź ma już dyrektywy pamięci podręcznej, dodaj wymóg świadomie, zamiast odrzucać resztę polityki. Na przykład publicznie buforowalny zasób może mieć:

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

Ten przykład zachowuje politykę świeżości jednej godziny i jednocześnie zabrania transformacji treści. no-transform nie oznacza no-store ani nie wyłącza zwykłego przetwarzania transferu. Ustaw ją na odpowiedziach, których oryginalna treść ma znaczenie, w tym na osobnych odpowiedziach obrazów, gdzie to stosowne.

Dyrektywa działa dzięki przestrzeganiu jej przez pośrednika. Nie uniemożliwia kryptograficznie urządzeniu sieciowemu zignorowania instrukcji.

Chroń także transport

HTTPS daje przeglądarce połączenie z uwierzytelnianiem i ochroną integralności do jej peera TLS. Zwykłe proxy operatora przepuszczające zaszyfrowany ruch nie może po cichu wstawić skryptu do tego chronionego połączenia. Pozostaw włączoną weryfikację certyfikatów; lokalnie zaufane proxy inspekcyjne kończące TLS to inny układ.

Serwuj stronę i jej zależne zasoby przez HTTPS. Przekierowuj odwiedzających HTTP na HTTPS i rozważ HSTS dla wdrożenia, które może je konsekwentnie obsługiwać. Samo przekierowanie zaczyna się od niechronionej wymiany HTTP dla odwiedzającego, który użył adresu HTTP; wcześniej poznana lub wstępnie załadowana polityka HSTS zmienia ten początkowy wybór.

Blokowanie wstrzykniętego skryptu może zmniejszyć jego widoczne skutki, ale odpowiedź może już zawierać zmieniony HTML lub przepisane adresy obrazów. Zastąpienie jednej starej nazwy funkcji, dodanie nietypowego komentarza lub zmapowanie historycznego adresu wstrzyknięcia nie ustanawia integralności treści dla następnego pośrednika.

Badając zgłoszenie, porównaj otrzymaną odpowiedź z zamierzoną treścią źródła i ustal, gdzie kończy się TLS. Ten dowód jest bardziej użyteczny niż traktowanie każdego nieznanego skryptu jako błędu w kodzie własnej aplikacji witryny.