Czym są nagłówki bezpieczeństwa (security headers) cz. 1

Szacunkowy czas czytania: 3 minuty

 

Przy okazji zabezpieczania stron certyfikatem SSL, potwierdzającym bezpieczeństwo szyfrowania danych, natrafiłam na temat tzw. nagłówków bezpieczeństwa (security headers). Postanowiłam zagłębić się w temat, choć wydawało mi się, że SSL to dostateczne zabezpieczenie. Okazuje, że nic bardziej błędnego.

Czym są nagłówki bezpieczeństwa?

Nagłówki bezpieczeństwa to komendy, które informują przeglądarkę jak ma zachowywać się podczas obsługi zawartości danej strony.  Możemy je dodać do naszej strony ręcznie w pliku .htaccess lub używając wtyczki Security Headers. Rekomenduję jednak dodawanie nagłówków ręcznie, ponieważ wtyczka Security Headers gryzie się z większością wtyczek do cache. W moim przypadku Hummingbird po wyczyszczeniu cache przepuszczał ustawione wtyczką nagłówki, natomiast po chwili już nie działały. Zmusiło mnie to do ręcznej konfiguracji.
Dla fanów wtyczkowej implementacji:
Z informacji znalezionej w sieci wynika, że wtyczka Comet Cache współpracuje z Security Headers. Inne popularne – raczej nie.

Jak sprawdzić czy strona jest zabezpieczona nagłówkami?

Na stronie https://securityheaders.com można przetestować swoją witrynę. Oczywiście, gdy zabierałam się do tematu otrzymałam taki oto groźny screen (ocena F):

Stronka sprawdza witrynę pod kątem sześciu najpopularniejszych nagłówków. Dziś opiszę dwa z nich.

Strict-Transport-Security

Przez Google opisywany jako mechanizm HSTS. Jest zalecany dla stron posiadających certyfikat SSL. Według informacji podanych przez Google, witryny z tym nagłówkiem będą lepiej się pozycjonować.
Nagłówek wymusza użycie bezpiecznego połączenia HTTPS i chroni strony przed atakami typu man in the middle (który polega na podsłuchu i zmianie informacji przesyłanych między dwiema stronami). Zapobiega także kradzieżom cookies.
Korzystając z HSTS, można włączyć obsługę wstępnego ładowania HSTS (preload). Można to zrobić na stronie hstspreload.org spełniając wymienione tam warunki. Chrome (i docelowo także inne przeglądarki) zapamiętają wtedy, że Twoja strona ma się wczytywać tylko po zabezpieczonym łączu. Dzięki temu można uniknąć sytuacji, gdy ktoś podszywa się pod naszą witrynę. Jeśli jednak planujesz zrezygnować z SSL nie zgłaszaj się na listę wstępnego ładowania, ponieważ preload będzie ciężko cofnąć. 

Nagłówek Strict-Transport-Security można wdrożyć:

  • wymienioną wcześniej wtyczką Security Headers,
  • płatną wersją wtyczki Really Simple SSL,
  • ręcznie w pliku .htaccess – dodając przykładową linijkę (max-age sugerowany przez Google, ale możecie poszukać w sieci innych opcji)
    Header set Strict-Transport-Security „max-age=31536000” env=HTTPS
    (przykład nie uwzględnia wymagań na listę preload)

Ostatnia opcja jest wdrożona u mnie na stronie i działa 🙂

Content-Security-Policy

Nagłówek ten pozwala autorowi lub administratorowi strony określić z jakiego źródła mają pochodzić dodatkowe zasoby (np. skrypty, obrazki, pliki CSS, fonty). Ogranicza to zagrożenie ze strony ataków XSS, czyli polegających na osadzeniu w treści zaatakowanej witryny złośliwego kodu/skryptu. Niestety wdrożenie tego nagłówka nie jest tak proste jak Strict-Transport-Security, zwłaszcza jeśli mówimy o WordPressie.
Wtyczki i sam WordPress zaciągają zasoby z wielu źródeł, więc dodanie standardowego nagłówka do .htaccess (Header set ContentSecurityPolicy „default-src ‚self'”), który ogranicza zasoby do własnych (self), najprawdopodobniej zepsuje nam wygląd witryny. Tak też stało się w moim przypadku – przestały działać style (nagłówek wyłącza style inline), a także niektóre skrypty. Zostałam zmuszona stworzyć bardziej spersonalizowany tekst polityki Content-Security-Policy, podając źródła zewnętrzne dla takich dyrektyw jak script-src oraz style-src.

Przy wdrożeniu Content-Security-Policy wymagana jest analiza źródeł, z których pochodzą nasze zasoby (np. skrypt Google Analytics, fonty Google). Nagłówek najczęściej ingeruje w funkcjonalność kokpitu WordPressa, dlatego najłatwiejszym sposobem jest wyłączenie go dla katalogu wp-admin – czyli po prostu dodajemy w nim osobny plik .htaccess z treścią: Header unset Content-Security-Policy

Przykłady jak może wyglądać nagłówek Content-Security-Policy znajdziecie między innymi tutaj: Walter Ebert, a dostępne dyrektywy tutaj: Content Security Policy.

Po wprowadzeniu dwóch nagłówków ocena mojej strony po skanie wygląda tak (ocena C):

 

Kolejne nagłówki, czyli:

  • X-Frame-Options
  • X-XSS-Protection
  • X-Content-Type-Options
  • Referrer-Policy

opiszę w następnym wpisie.

Jeden komentarz

Możliwość komentowania jest wyłączona.