Masz SSL? To jeszcze nie znaczy, że Twoja strona jest dobrze zabezpieczona

Widzisz kłódkę przy adresie swojej strony. Adres zaczyna się od https://. Certyfikat SSL jest ważny.

Czyli wszystko jest bezpieczne?

Niekoniecznie.

SSL jest dziś absolutną podstawą, ale odpowiada przede wszystkim za szyfrowanie komunikacji pomiędzy przeglądarką użytkownika a serwerem. Nie mówi przeglądarce, jakie skrypty może uruchomić, czy strona może zostać osadzona w obcej witrynie, jakie informacje może przekazać podczas przechodzenia do innego serwisu ani z jakich funkcji urządzenia może korzystać.

Do tego służą między innymi nagłówki bezpieczeństwa HTTP.

I właśnie dlatego w Monito zaczęliśmy je sprawdzać.

Czym właściwie są nagłówki bezpieczeństwa?

Kiedy otwierasz stronę internetową, serwer wysyła do Twojej przeglądarki nie tylko HTML, zdjęcia czy arkusze CSS. Odpowiedź zawiera również zestaw nagłówków HTTP.

Część z nich może pełnić bardzo ważną funkcję bezpieczeństwa.

W dużym uproszczeniu są to instrukcje przekazywane przeglądarce, które określają, w jaki sposób powinna obchodzić się z daną stroną i jej zasobami.

Można więc mieć:

• poprawnie działający HTTPS,
• ważny certyfikat SSL,
• zieloną kłódkę w przeglądarce,

a jednocześnie nie mieć skonfigurowanych podstawowych nagłówków bezpieczeństwa.

I jest to sytuacja, którą spotykamy bardzo często.

1. HSTS – skoro jest HTTPS, korzystajmy z niego zawsze

HSTS, czyli HTTP Strict Transport Security, informuje przeglądarkę, że z daną witryną powinna komunikować się wyłącznie przez HTTPS.

Serwer może wysłać przykładowo:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Po otrzymaniu takiej informacji przeglądarka wie, że przez określony czas nie powinna próbować łączyć się z witryną za pomocą zwykłego HTTP.

Po co to robić, skoro mamy SSL?

Bo posiadanie certyfikatu i wymuszenie korzystania z bezpiecznego połączenia to dwie różne rzeczy.

HSTS zmniejsza ryzyko sytuacji, w której użytkownik zostanie skierowany do niezabezpieczonej wersji strony i pomaga chronić przed atakami polegającymi na próbie obniżenia bezpieczeństwa połączenia.

W Monito sprawdzamy więc nie tylko, czy certyfikat SSL istnieje i jest ważny.

Sprawdzamy również, czy strona informuje przeglądarkę, że HTTPS powinien być używany konsekwentnie.

2. Content-Security-Policy – jeden z najważniejszych nagłówków

Content-Security-Policy (CSP) pozwala określić, z jakich źródeł strona może pobierać między innymi:

• JavaScript,
• CSS,
• obrazy,
• fonty,
• ramki,
• multimedia.

Dlaczego jest to istotne?

Wyobraźmy sobie stronę, która normalnie korzysta ze skryptów pochodzących z własnej domeny oraz kilku zaufanych usług.

CSP może powiedzieć przeglądarce:

„Uruchamiaj skrypty tylko z tych źródeł.”

Jeżeli na stronie w wyniku podatności pojawi się kod próbujący załadować skrypt z innego, niedozwolonego źródła, odpowiednio skonfigurowana polityka CSP może uniemożliwić jego wykonanie.

To istotna dodatkowa warstwa ochrony m.in. przed skutkami niektórych ataków XSS.

Jest jednak pewien haczyk

CSP nie powinno się wdrażać metodą:

„Wklejamy gotowy nagłówek znaleziony w Internecie i mamy zabezpieczoną stronę.”

Źle skonfigurowana polityka może zablokować:

• formularz,
• Google Analytics,
• mapę Google,
• reCAPTCHA,
• płatności,
• filmy,
• zewnętrzne fonty,
• inne potrzebne skrypty.

Dlatego w Monito brak CSP traktujemy jako element wymagający uwagi, ale samo jego dodanie powinno być poprzedzone analizą konkretnej witryny.

3. X-Content-Type-Options – nie zgaduj, czym jest ten plik

Kolejny nagłówek ma bardzo prostą postać:

X-Content-Type-Options: nosniff

Jego zadaniem jest ograniczenie tzw. MIME sniffingu.

Przeglądarka powinna respektować zadeklarowany typ zasobu zamiast próbować samodzielnie interpretować go jako coś innego.

Brzmi technicznie, ale idea jest prosta:

Jeżeli serwer mówi, czym jest dany plik, przeglądarka nie powinna próbować zgadywać, że jest czymś innym.

To niewielkie ustawienie, które może stanowić dodatkową warstwę ochrony.

4. Ochrona przed osadzaniem strony – czyli clickjacking

Wyobraź sobie, że ktoś umieszcza Twoją stronę w niewidocznej lub odpowiednio spreparowanej ramce na własnej stronie.

Użytkownikowi wydaje się, że klika jeden element, ale w rzeczywistości wykonuje akcję na innej stronie.

To jeden ze scenariuszy określanych jako clickjacking.

Ochronę można realizować między innymi za pomocą:

X-Frame-Options

lub nowocześniejszej dyrektywy:

frame-ancestors

w Content-Security-Policy.

Nie każda strona musi całkowicie blokować osadzanie. Czasami iframe jest świadomie wykorzystywany.

Istotne jest natomiast, żeby była to świadoma decyzja wynikająca z konfiguracji, a nie przypadkowy brak zabezpieczenia.

5. Referrer-Policy – ile informacji przekazujesz innym stronom?

Klikasz link prowadzący z jednej strony do drugiej.

Przeglądarka może przekazać witrynie docelowej informację o stronie, z której przyszedłeś.

Nagłówek:

Referrer-Policy

pozwala kontrolować zakres tych informacji.

Jedną z często stosowanych polityk jest:

Referrer-Policy: strict-origin-when-cross-origin

To kolejny przykład zabezpieczenia, którego użytkownik nigdy nie zobaczy na stronie, ale które wpływa na sposób, w jaki przeglądarka obchodzi się z jego danymi.

6. Permissions-Policy – czy Twoja strona naprawdę potrzebuje dostępu do wszystkiego?

Współczesne przeglądarki potrafią udostępnić witrynom wiele funkcji urządzenia, między innymi związanych z:

• kamerą,
• mikrofonem,
• geolokalizacją,
• pełnym ekranem,
• innymi możliwościami przeglądarki.

Permissions-Policy pozwala administratorowi określić, które funkcje powinny być dostępne i w jakim zakresie.

Zasada jest podobna jak w wielu innych obszarach bezpieczeństwa:

Jeżeli strona nie potrzebuje jakiegoś uprawnienia, po co pozostawiać je dostępne?

Czy brak jednego z tych nagłówków oznacza, że strona została zhakowana?

Nie. I to bardzo ważne.

Nie chcemy straszyć właścicieli stron czerwonym komunikatem tylko dlatego, że nie znaleźliśmy konkretnego nagłówka.

Brak CSP czy HSTS nie oznacza automatycznie, że:

• strona została zaatakowana,
• dane użytkowników wyciekły,
• witryna jest niebezpieczna,
• za chwilę wydarzy się incydent.

Oznacza natomiast, że nie została wykorzystana określona dodatkowa warstwa ochrony albo jej konfiguracji nie udało się potwierdzić.

To istotna różnica.

Dlatego Monito ma nie tylko wykrywać problemy, ale również tłumaczyć ich znaczenie.

Nagłówki bezpieczeństwa to tylko połowa historii

Jest jeszcze jeden obszar, o którym właściciele firm często zapominają.

Możesz bardzo dobrze zabezpieczyć stronę internetową, a ktoś może próbować zaatakować Twoich klientów zupełnie inną drogą:

podszywając się pod firmową pocztę.

Dlatego drugim ważnym obszarem konfiguracji domeny są:

SPF, DKIM i DMARC.

Pełnią inną funkcję niż nagłówki HTTP.

W uproszczeniu:

nagłówki HTTP pomagają chronić komunikację użytkownika ze stroną, natomiast SPF, DKIM i DMARC pomagają serwerom pocztowym ocenić autentyczność wiadomości wysyłanych z wykorzystaniem domeny.

SPF

Określa, jakie serwery są uprawnione do wysyłania poczty dla danej domeny.

DKIM

Dodaje do wiadomości podpis kryptograficzny, którego poprawność może zostać zweryfikowana przez serwer odbiorcy.

DMARC

Pozwala właścicielowi domeny określić politykę postępowania z wiadomościami, które nie przechodzą odpowiednich kontroli SPF/DKIM, oraz umożliwia otrzymywanie raportów.

To ma realne znaczenie biznesowe.

Bo atak nie musi wyglądać jak włamanie na stronę.

Może wyglądać jak wiadomość:

„Dzień dobry, w załączniku przesyłamy poprawioną fakturę. Prosimy zwrócić uwagę na zmianę numeru rachunku bankowego.”

A nadawcą na pierwszy rzut oka może wydawać się Twoja firma.

A co z dostarczalnością wiadomości?

SPF, DKIM i DMARC są również ważnymi elementami współczesnego ekosystemu poczty.

Duzi operatorzy pocztowi zaostrzają wymagania wobec nadawców, szczególnie tych wysyłających duże wolumeny wiadomości. Poprawne uwierzytelnianie domeny pomaga budować wiarygodność poczty i ograniczać problemy z jej dostarczaniem.

Nie oznacza to jednak, że samo dodanie trzech rekordów gwarantuje, że wiadomość nigdy nie trafi do spamu. Na dostarczalność wpływa znacznie więcej czynników, m.in. reputacja domeny i IP, jakość bazy odbiorców, treść wiadomości czy zachowanie użytkowników.

To kolejny przypadek, w którym warto unikać prostych obietnic i zamiast tego sprawdzać rzeczywistą konfigurację.

Dlaczego zaczęliśmy sprawdzać nagłówki bezpieczeństwa w Monito?

Początkowo monitoring strony kojarzył się przede wszystkim z jednym pytaniem:

Czy strona działa?

To nadal najważniejsza informacja.

Ale z czasem doszliśmy do wniosku, że to za mało.

Strona może przecież:

• odpowiadać kodem HTTP 200,
• posiadać ważny SSL,
• ładować się szybko,

a jednocześnie mieć istotne braki konfiguracyjne.

Dlatego Health Check w Monito sprawdza obecnie m.in.:

• HSTS,
• Content-Security-Policy,
• X-Content-Type-Options,
• Referrer-Policy,
• Permissions-Policy,
• ochronę przed osadzaniem strony poprzez X-Frame-Options lub frame-ancestors.

Co ważne, nie ograniczamy kontroli wyłącznie do strony głównej. Sprawdzamy również wybrane podstrony, ponieważ konfiguracja nagłówków może różnić się pomiędzy poszczególnymi częściami serwisu.

Sprawdź swoją stronę. Możesz się zdziwić.

Jeżeli masz SSL, to świetnie.

Ale SSL powinien być początkiem rozmowy o bezpieczeństwie strony, a nie jej końcem.

Możesz mieć piękną stronę, aktualnego WordPressa, dobry hosting i ważny certyfikat, a jednocześnie nie wykorzystywać kilku stosunkowo prostych mechanizmów bezpieczeństwa dostępnych we współczesnych przeglądarkach.

I właśnie dlatego warto to sprawdzać.

Monito analizuje nagłówki bezpieczeństwa automatycznie w ramach Health Check i pokazuje, których zabezpieczeń brakuje oraz do czego każde z nich służy.

Nie musisz wiedzieć, czym jest frame-ancestors, nosniff czy strict-origin-when-cross-origin.

Od tego jest Monito.

Ty powinieneś wiedzieć przede wszystkim jedno: czy Twoja strona działa prawidłowo i co wymaga Twojej uwagi.