mixed content

Mixed content to sytuacja, w której strona wczytana przez HTTPS pobiera część zasobów przez nieszyfrowane HTTP. MDN definiuje ją jako bezpiecznie załadowane strony, które korzystają z zasobów pobieranych przez HTTP albo inny niezabezpieczony protokół ^[1]. Taka strona jest potencjalnie niebezpieczna, bo zasoby wysłane bez szyfrowania można podejrzeć, a atakujący może je zmienić ^[1]. Typowym objawem jest przekreślona kłódka w przeglądarce mimo zainstalowanego certyfikatu ^[5].

Jak działa

Szyfrowanie HTTPS chroni tylko te żądania, które faktycznie idą przez HTTPS. Jeśli dokument HTML przyszedł zaszyfrowany, a zawarty w nim skrypt ma adres http://, przeglądarka musiałaby pobrać go otwartym tekstem. Certyfikat SSL/TLS strony niczego tu nie zmienia, bo protokół TLS nie obejmuje tego jednego połączenia.

Ryzykiem jest atak man-in-the-middle (MITM): napastnik na drodze pakietów może przechwycić zasób i zmienić go w locie ^[1]. Najprostszy przypadek to publiczna sieć, co opisuje hasło zagrożenia publicznych sieci Wi-Fi. Schemat poniżej pokazuje, co mogłoby się stać, gdyby przeglądarka wczytała taki skrypt.

RYS. 1Skrypt przez HTTP na stronie HTTPS

Dlatego współczesne przeglądarki takich żądań nie wykonują. Według MDN automatycznie przestawiają obrazy, wideo i dźwięk z HTTP na HTTPS, a niezabezpieczone żądania wszystkich pozostałych typów zasobów blokują ^[1].

Rodzaje

Specyfikacja W3C Mixed Content, w wersji roboczej rekomendacji kandydującej z 23 lutego 2023 roku, dzieli zasoby na dwie grupy ^[2]. Zasoby, które da się podnieść (upgradeable), przeglądarka przepisuje na https zamiast je blokować ^[2]. Wszystko inne to zasoby blokowane (blockable) ^[1].

Starsze specyfikacje używały innych nazw: treść „aktywna” (skrypty i style, które mogą zmienić stronę) i „pasywna” (obrazy, wideo, dźwięk) ^[1]. Te nazwy nadal pojawiają się w poradnikach. home.pl opisuje aktywną treść mieszaną jako blokowaną przez przeglądarki, a pasywną jako mniej groźną ^[5].

Specyfikacja W3C zaleca też blokowanie pobierania plików przez HTTP ze stron HTTPS, bo takie pliki wychodzą poza piaskownicę przeglądarki ^[2]. Formularz wysyłany z bezpiecznej strony na adres http:// przeglądarka może oznaczyć ostrzeżeniem albo potraktować jak żądanie blokowane ^[2].

W WordPressie

Najczęstsza przyczyna w WordPressie to przejście istniejącej strony z HTTP na HTTPS. Adresy obrazów, odnośniki i adresy w ustawieniach wtyczek zostają w bazie w starej postaci http://. Zmiana adresu witryny w ustawieniach ich nie poprawia, bo są zapisane w treści wpisów i w opcjach.

WordPress od wersji 5.7 łagodzi problem. Gdy serwer obsługuje HTTPS, ekran Stan witryny pokazuje przycisk, który przestawia oba adresy witryny na HTTPS ^[3]. Funkcja wp_replace_insecure_home_url() zamienia wtedy niezabezpieczone adresy własnej strony w locie ^[3]. Dla administratorów, którzy wolą trwale poprawić adresy w bazie, notatka zaleca potem usunięcie opcji https_migration_required, by logika przepisywania nie działała bez potrzeby ^[3]. Zamiana w locie dotyczy adresów własnej domeny; zasoby z innych serwisów, na przykład z CDN, trzeba poprawić osobno.

Trwałą poprawkę w bazie robi polecenie WP-CLI wp search-replace. Dokumentacja podaje, że narzędzie poprawnie obsługuje dane serializowane PHP i nie zmienia wartości kluczy głównych ^[4]. Opcja --dry-run wykonuje całą operację i pokazuje raport bez zapisu, a --skip-columns=guid pomija wskazaną kolumnę ^[4].

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

Przed zapisem zmian warto mieć świeżą kopię zapasową (backup), a całość najpierw przećwiczyć w środowisku testowym (staging).

Zagrożenia i skutki

• Podmiana kodu. Gdyby skrypt przez HTTP się wczytał, napastnik w sieci mógłby go zmienić ^[1], a zmieniony skrypt działałby z uprawnieniami strony. home.pl wymienia wśród skutków aktywnej treści mieszanej manipulację danymi i phishing ^[5].
• Wyciek danych. Zasób pobrany bez szyfrowania można podejrzeć, co może ujawnić wrażliwe informacje ^[1].
• Zepsuta strona. Blokada skryptu, arkusza stylów albo czcionki oznacza, że strona wygląda lub działa inaczej, niż zaplanowano.
• Utrata zaufania. Przekreślona albo ostrzegawcza kłódka podważa zaufanie odwiedzających, mimo że strona ma certyfikat ^[5].

Jak naprawić i zapobiegać

MDN wskazuje trzy podstawowe kroki: serwować całą treść przez HTTPS, stosować do zasobów linki względne albo adresy https, a z zewnętrznych serwisów używać wersji HTTPS ^[1]. Miejsca problemów pokazuje konsola narzędzi deweloperskich przeglądarki; każdy komunikat wskazuje konkretny element ^[5].

Uzupełnieniem są nagłówki bezpieczeństwa HTTP. Dyrektywa CSP upgrade-insecure-requests podnosi do HTTPS wszystkie żądania, także blokowane zasoby mixed content ^[1]:

Content-Security-Policy: upgrade-insecure-requests

Nagłówek HSTS informuje przeglądarkę, że z domeną wolno łączyć się wyłącznie przez HTTPS ^[6]. Nie poprawia jednak odnośników do zasobów w innych domenach, więc nie zastępuje porządków w bazie i kodzie motywu.

Historia i przykłady

Podział na treść aktywną i pasywną pochodzi z wcześniejszych specyfikacji, w których treść „optionally blockable” obejmowała obrazy, wideo i dźwięk ^[1]. Obecna specyfikacja W3C ma status wersji roboczej rekomendacji kandydującej z 23 lutego 2023 roku ^[2]. Uzasadnia automatyczne podnoszenie obrazów i multimediów tym, że takie zasoby są szeroko używane przez HTTP i niosą małe ryzyko ^[2]. Zmiana przesunęła ciężar z ostrzegania użytkownika na naprawianie żądań przez samą przeglądarkę.

W WordPressie przełom przyniosła wersja 5.7, opisana przez zespół rdzenia w lutym 2021 roku ^[3]. Wcześniej przejście na HTTPS wymagało ręcznej zmiany obu adresów witryny i zamiany adresów w bazie. Polskie hostingi nadal publikują instrukcje szukania mixed content w konsoli przeglądarki: skrót Ctrl + Shift + I otwiera narzędzia deweloperskie, a ostrzeżenia na żółto dotyczą treści pasywnej, na czerwono zaś zablokowanej treści aktywnej ^[5].