Tag Archive for: nagłówki bezpieczeństwa

projektowanie stron - security

X-Content-Type-Options

/0 Komentarze/w /Autor

Nagłówek HTTP X-Content-Type-Options pokrótce opisałem w artykule Nagłówki bezpieczeństwa strony internetowej.
W tym artykule przedstawię go trochę szerzej.

X-Content-Type-Options jest znacznikiem używanym przez serwer do wskazania, że typy MIME (ang. Multipurpose Internet Mail Extensions), które znajdują się w nagłówkach Content-Type, powinny być przestrzegane i nie można ich zmieniać. Pozwala on uniknąć podsłuchiwania typu MIME. Jednocześnie przekazuje informacje, że typy MIME są celowo skonfigurowane. Ten nagłówek wprowadził Microsoft w IE 8 jako sposób dla webmasterów na blokowanie podsłuchiwania treści, które miało miejsce i może przekształcić niewykonywalne typy MIME w wykonywalne typy MIME. Od tego czasu inne przeglądarki wprowadziły go, nawet jeśli ich algorytmy sniffingu MIME były mniej agresywne. Począwszy od Firefoksa 72, dokumenty najwyższego poziomu również unikają sniffingu MIME (jeśli podano Content-type). Może to spowodować, że strony internetowe HTML będą pobierane zamiast renderowane, gdy są obsługiwane z typem MIME innym niż text/html.

Składnia

X-Content-Type-Options: nosniff

Dyrektywa

nosniff

Blokuje żądanie, jeśli miejsce docelowe żądania jest typu style a typem MIME nie jest text/css, lub typu script, a typem MIME nie jest typ MIME JavaScript.

Jest to łatwy do skonfigurowania nagłówek, który ma tylko jedną poprawną wartość – nosniff. X-Content-Type-Options w tej konfiguracji wymusi na przeglądarce odpowiedni sposób zachowania. Efekt jest taki, że przeglądarka nie „zgaduje” jaki rodzaj danych jest do przekazania. Jeśli rozszerzeniem jest „zip”, przeglądarka powinna otrzymać plik .zip, a nie coś innego (.exe). W przeciwnym razie przeglądarka może być narażona i podstępnie zmuszona do wykonania skryptu, podczas gdy użytkownik jest przekonany, że pobiera bezpieczny plik.

Konfiguracja X-Content-Type-Options

Dla serwera NginX:

add_header X-Content-Type-Options "nosniff" always;

Dla serwera Apache:

Header always set X-Content-Type-Options "nosniff"

Podsumowanie X-Content-Type-Options

Jeśli wcześniej ustawiliśmy nagłówek Permissions Policy, Strict Transport Security oraz X-Frame-Options przystępujemy do konfiguracji obecnego. Efekty widzimy na stronie https://securityheaders.com/ i kolejny z obszarów zaświeci się na zielono.

X-Content-Type-Options
Konfiguracja X-Content-Type-Options na stronie testowej

Jest to kolejny z elementów mających na celu poprawę bezpieczeństwa naszej witryny. Jest to też kolejny z kroków do uzyskania końcowego efektu, jaki opisałem w artykule Strona internetowa – jak ją założyć?

Jeżeli potrzebujesz więcej informacji na temat tego nagłówka, znajdziesz je w artykule.

projektowanie stron - security

X-Frame-Options

/0 Komentarze/w /Autor

Nagłówek odpowiedzi HTTP X-Frame-Options może być użyty do wskazania, czy przeglądarka powinna mieć możliwość renderowania strony w kodach  <frame>,  <iframe>,  <embed>  lub <object>. Witryny mogą z tego korzystać, aby uniknąć ataków typu click-jacking. Muszą się wtedy upewnić, że ich zawartość nie jest osadzona w innych witrynach.

Atakujący może załadować ramkę iframe na swojej stronie i ustawić Twoją stronę jako źródło. Używając sprytnego CSS, może ukryć Twoją witrynę w tle i stworzyć autentycznie wyglądające nakładki. Kiedy odwiedzający klikają na to, co wydaje im się nieszkodliwym linkiem, w rzeczywistości klikają na linki na Twojej stronie w tle. To może nie wydawać się takie złe, dopóki nie uświadomimy sobie, że przeglądarka wykona te żądania w kontekście użytkownika, który może być zalogowany i uwierzytelniony na Twojej stronie.

Dyrektywy X-Frame-Options

Istnieją dwie możliwe dyrektywy dla X-Frame-Options

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

Jeśli wprowadzisz DENY, to strona nie będzie się wyświetlać w ramce. Przy wprowadzeniu dyrektywy SAMEORIGIN witryna będzie się wyświetlać tylko w ramce o tym samym pochodzeniu co sama strona. Możesz zobaczyć także artykuł Zgodność z przeglądarkami, aby uzyskać szczegółowe informacje na temat pomocy technicznej.

Niektóre starsze wersje przeglądarek dopuszczały jeszcze dyrektywę ALLOW-FROM. Jest to przestarzała dyrektywa, która nie działa już w nowoczesnych przeglądarkach. Nie zalecam używania jej. W przypadku obsługi starszych przeglądarek strona będzie się wyświetlać w ramce tylko o określonym pierwotnym identyfikatorze uri.

Konfigurowanie serwera Apache

Aby skonfigurować Apache do wysyłania nagłówka dla wszystkich stron, dodaj do konfiguracji witryny X-Frame-Options poniższy kod:

Header always set X-Frame-Options "SAMEORIGIN"

Aby skonfigurować Apache do ustawienia DENY, dodaj do konfiguracji witryny X-Frame-Options poniższy kod:

Header set X-Frame-Options "DENY"

Konfiguracja Nginx

Aby skonfigurować Nginx do wysyłania nagłówka, dodaj do konfiguracji http, serwera lub lokalizacji X-Frame-Options następujący kod:

add_header X-Frame-Options SAMEORIGIN always;

Konfigurowanie usług IIS

Aby skonfigurować usługi IIS do wysyłania nagłówka X-Frame-Options, dodaj do pliku Web.config witryny:

<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>

X-Frame-Options – podsumowanie

Jeśli wcześniej ustawiliśmy nagłówek Permissions Policy oraz Strict Transport Security, przystępujemy do konfiguracji obecnego. Efekty widzimy na stronie https://securityheaders.com/ i kolejny z obszarów zaświeci się na zielono.

X-Frame-Options
Konfiguracja X-Frame-Options na stronie testowej

Jest to kolejny z elementów mających na celu poprawę bezpieczeństwa naszej witryny. Jest to też kolejny z kroków do uzyskania końcowego efektu, jaki opisałem w artykule Strona internetowa – jak ją założyć?

Jeżeli potrzebujesz więcej informacji na temat tego nagłówka, znajdziesz je w artykule.

projektowanie stron - security

Strict Transport Security

/0 Komentarze/w /Autor

Wstępne przekierowanie ruchu

W artykule Nagłówki bezpieczeństwa strony internetowej pokrótce opisałem nagłówek Strict Transport Security. Tak jak wspomniałem, konfiguracja tego nagłówka wymaga wcześniejszego zainstalowania certyfikatu SSL. Nawet jeśli masz zainstalowany certyfikat SSL w swojej domenie, każdy może nadal korzystać z Twojej witryny przez http. Może to być wykorzystane przez inną witrynę, która podszywa się pod Twoją. Wygląda to mniej więcej tak, że użytkownik wpisuje adres domena.com, ale złośliwe oprogramowanie kieruje żądanie do witryny podszywającej się pod ten adres. W tym momencie użytkownik jest narażony na ataki. Aby temu zapobiec, najprostszym rozwiązaniem jest dodanie przekierowania, które wymusza korzystanie z SSL. Następnie należy ustawić przekierowanie z przeglądania stron z HTTP na HTTPS. W tym celu w pliku .htaccess umieszczamy odpowiednie polecenia:

RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Dyrektywy nagłówka Strict Transport Security

Nagłówek HTTP Strict Transport Security wykorzystuje 3 dyrektywy, które poniżej krótko przedstawię:

  • max-age
  • includeSubDomains
  • preload

Dyrektywa max-age jest obowiązkowa i może mieć dowolną wartość od 0 wzwyż. Wskazuje ona liczbę sekund po otrzymaniu polityki. Ja proponuję ustawić wartość 31536000, co jest równe 365 dniom. Wartość dyrektywy max-age wynosząca 0 informuje o zaprzestaniu traktowania hosta, który go wystawił jako hosta HSTS i usunięciu wszystkich zasad. Nie implikuje nieskończonej wartości dyrektywy max-age.
Dyrektywa includeSubDomains, jest funkcją opcjonalną, którą można dołączyć według uznania. Gdy ją ustawimy, to wszystkie subdomeny będą traktowane jako hosty HTTP Strict Transport Security.
Dyrektywę preload przedstawiam w dalszej części tekstu.

Konfiguracja nagłówka Strict Transport Security

HTTP Strict Transport Security (HSTS) informuje przeglądarkę, że zawsze chcesz, aby użytkownik łączył się za pomocą HTTPS zamiast HTTP. Oznacza to, że wszelkie zakładki, linki lub adresy, które użytkownik wpisuje, będą zmuszone do korzystania z HTTPS, nawet jeśli użytkownik wpisze HTTP. Po ustawieniu HSTS komunikacja przeglądarki z serwerem odbywa się wyłącznie przez bezpieczne połączenie. Wstawiamy więc kod:

Header always set Strict-Transport-Security max-age=31536000; includeSubDomains

Jeśli ustawisz ten nagłówek w swojej domenie, przeglądarka od tej pory będzie wykonywać wszystkie żądania przez https. Tak więc w przypadku, gdy haker przekierowuje użytkownika do fałszywej domeny.com, przeglądarka pamięta o użyciu SSL z powodu HSTS. Żąda połączenia z bezpieczną witryną. W efekcie nie połączy użytkownika z fałszywą domeną, gdyż żaden certyfikat SSL nie będzie autoryzował fałszywej witryny.

Ponieważ przeglądarka musi najpierw odwiedzić Twoją witrynę, aby zobaczyć ten nagłówek, będzie on aktywny dopiero po pierwszej wizycie. Jest to pewnego rodzaju luka w zabezpieczeniach. Jeśli użytkownik odwiedza Twoją witrynę po raz pierwszy, to HSTS nie zostanie ustawiony. Tak więc odwiedzający nadal może zażądać witryny przez http. Rozwiązaniem tego problemu jest dopisanie dyrektywy preload. Kod będzie wtedy wyglądał tak:

Header always set Strict-Transport-Security max-age=31536000; includeSubDomains; preload

Lista preload HSTS jest to lista domen HSTS, które wstępnie ładują się w przeglądarkach.

Jeśli umieścisz swoją witrynę na tej liście, to przeglądarka będzie wiedziała, że powinna ładować Twoją witrynę tylko przez https. Dzieje się tak nawet zanim zażąda ona pierwszego połączenia z Twoją witryną. Ale trzeba rozważnie stosować tę funkcję, gdyż wszystkie subdomeny (takie jak sub.domain.com) będą również wymuszone przez https. A jeśli po jakimś czasie uznasz, żeby usunąć swoją witrynę z listy preload, to musisz wiedzieć, że jest to bardzo trudne i może nie rozprzestrzeniać się zbyt szybko. Więc nawet jeśli usuniesz swoją witrynę z tej listy, przeglądarki mogą mieć ją na liście jeszcze przez kilka miesięcy.

Strict Transport Security – podsumowanie

Mam świadomość, że przedstawiam kolejny artykuł, który jest bardziej techniczny. Ale zgodnie z mottem mojej witryny „WordPress dla laików„, staram się w przystępny sposób przedstawić funkcjonalność kolejnego nagłówka bezpieczeństwa.

Jeśli wcześniej ustawiliśmy nagłówek Permissions Policy, przystępujemy do konfiguracji obecnego. Efekty widzimy na stronie https://securityheaders.com/ i kolejny z obszarów zaświeci się na zielono.

Strict Transport Security
Konfiguracja Strict Transport Security na stronie testowej

Jest to kolejny z elementów mających na celu poprawę bezpieczeństwa naszej witryny. Jest to też kolejny z kroków do uzyskania końcowego efektu, jaki opisałem w artykule Strona internetowa – jak ją założyć?

Jak już wspominałem we wcześniejszym artykule, witryny, które wykorzystują HSTS, Google dodaje do listy najlepszych domen internetowych. W efekcie są wyżej pozycjonowane. Jest to więc jeden z kroków do optymalizacji SEO naszej witryny.

Jeżeli potrzebujesz więcej informacji na temat nagłówka Strict Transport Security, znajdziesz je na tej stronie.

projektowanie stron - security

Permissions Policy

/0 Komentarze/w /Autor

Permissions Policy, czyli Polityka uprawnień

Permissions Policy, czyli Polityka uprawnień jest jednym z nagłówków opisanych przeze mnie w artykule Nagłówki bezpieczeństwa.
Z założenia moja strona ma być WordPressem dla laików. Jednakże dla tych, którzy chcieliby trochę więcej dowiedzieć się o nagłówkach bezpieczeństwa, postaram się tematykę przybliżyć w kolejnych wpisach.

Nagłówek HTTP Permissions-Policy zastąpił istniejący dotychczas nagłówek Feature-Policy, który służył do kontroli delegacji uprawnień i zaawansowanych funkcji. Nagłówek ten używa ustrukturyzowanej składni i pozwala witrynom na ściślejsze ograniczenie tego, które źródła mogą uzyskać dostęp do funkcji.

Najważniejsze funkcje Permissions policy

Nagłówek Permissions Policy pozwala na precyzyjną kontrolę tego, z jakich funkcji przeglądarki może korzystać Twoja witryna. Istnieje wiele dyrektyw, które można kontrolować za pomocą nagłówka Permissions Policy. Ponieważ nie wszystkie dostępne funkcje są oczywiste, poniżej przedstawiam krótki opis poszczególnych dyrektyw:

  • Accelerometer: Zezwala lub zabrania żądania informacji o przyspieszeniu urządzenia,
  • Autoplay: Zezwala lub zabrania automatycznego odtwarzania mediów (wymagane przez interfejs HTMLMediaElement),
  • Camera: Zezwala lub zabrania korzystania z urządzeń wejściowych wideo,
  • Encrypted-media: Zezwala lub zabrania korzystania z interfejsu API „Encrypted Media Extensions” w celu kontrolowania odtwarzania treści podlegających cyfrowemu systemowi zarządzania ograniczeniami,
  • Fullscreen: Zezwala lub zabrania ramkom typu cross- i same-origin używania trybu pełnoekranowego,
  • Geolocation: Zezwala lub zabrania korzystania z interfejsu geolokalizacji,
  • Gyroscope: Zezwala lub zabrania zbierania informacji o orientacji urządzenia (za pomocą pomiarów przesunięcia kątowego wzdłuż trzech osi),
  • Magnetometer: Zezwala lub zabrania zbierania informacji o orientacji urządzenia (wykrywanej przez główny czujnik magnetometru urządzenia),
  • Microphone: Zezwala lub zabrania korzystania z urządzeń wejściowych audio,
  • Midi: Zezwala lub zabrania korzystania z interfejsu Web MIDI API, który zawiera metody wyświetlania i żądania informacji z podłączonych urządzeń MIDI,
  • Payment: Zezwala lub zabrania korzystania z API Payment Request (ma na celu zmniejszenie liczby kroków potrzebnych do ukończenia płatności poprzez zapamiętywanie informacji o płatności),
  • Picture-in-picture: Zezwala lub zabrania odtwarzania filmów w trybie Obraz w obrazie (Picture-in-Picture),
  • Sync-xhr: Zezwala lub zabrania synchronicznym żądaniom XMLHttpRequest na pobieranie danych z adresu URL bez konieczności pełnego odświeżania strony,
  • USB: Zezwala lub zabrania korzystania z interfejsu API WebUSB,
  • New Interest-cohort: Służy do uniemożliwienia Google wykorzystania Twojej witryny do fingerprintingu przeglądarki w ramach procesu FLoC. FLoC jest skrótem od Federated Learning of Cohorts, czyli metody pozwalającej grupować użytkowników internetu i docelowo tworzyć reklamy kierowane. Z założenia ma to nie pozyskiwać w oczywisty sposób informacji o pojedynczych osobach. Więcej w artykule Google chce cię „śledzić” przez FLoC, a nie ciasteczka. To ma być krok w stronę prywatności.

Wartości dyrektyw nagłówka Polityki uprawnień

Każda dyrektywa może mieć jedną z tych poniższych wartości:

  • *
  • ’self’
  • ’none’
  • <origin(s)>

W następnym kroku rozłożymy je na czynniki pierwsze i przyjrzyjmy się dokładnie temu, na co pozwoli każda z nich:

  • * – pozwoli bieżącej stronie korzystać z funkcji i wszelkich innych kontekstów przeglądania zagnieżdżonych wewnątrz niej, takich jak iframe;
  • ’self’ – pozwoli bieżącej stronie na użycie funkcji i wszelkich innych kontekstów przeglądania zagnieżdżonych wewnątrz niej, takich jak iframe, tylko jeśli pochodzą z tego samego źródła, więc na przykład ramka własnej strony na swojej stronie;
  • ’none’ – ta funkcja będzie wyłączona dla bieżącej strony i wszelkich zagnieżdżonych kontekstów przeglądania, takich jak iframe;
  • <origin(s)> – tylko określone źródła będą mogły używać tej funkcji. Na przykład https://example.com lub https://example.net, https://example.org.

Mam nadzieję, że w tym artykule w sposób w miarę czytelny przybliżyłem jeden z nagłówków, jakim jest Permissions Policy. Gdy skonfigurujemy go w odpowiedni dla naszej witryny sposób, to w efekcie na stronie https://securityheaders.com/ jeden z obszarów zaświeci się na zielono.

Permissions policy
Konfiguracja Permissions policy na stronie testowej

Będzie to jeden z elementów mających na celu poprawę bezpieczeństwa naszej witryny. Jest to też jeden z kroków do uzyskania końcowego efektu, jaki opisałem w artykule Strona internetowa – jak ją założyć?

Jeżeli chcesz dowiedzieć się więcej na temat powyższego nagłówka, odpowiednie informacje znajdziesz na przykład na stronie Mozilli.

nagłówki bezpieczeństwa

Nagłówki bezpieczeństwa strony internetowej

/0 Komentarze/w /Autor

Nagłówki bezpieczeństwa – wprowadzenie

Czasem poszukujemy informacji na temat poprawy poziomu bezpieczeństwa poszczególnych obszarów naszego życia i otaczającej nas rzeczywistości. Jednym z tych obszarów może być posiadana przez nas witryna internetowa. W tym artykule postaram się w prosty sposób opisać, jak zadbać o nagłówki bezpieczeństwa – bez zagłębiania się w szczegóły techniczne, tak aby każdy użytkownik WordPressa mógł sobie z tym poradzić.

Zacznijmy od podstawowych informacji – jak wiemy, każda strona komunikuje się z użytkownikiem przy użyciu protokołu HTTP (ang. Hypertext Transfer Protocol) – protokół przesyłania dokumentów hipertekstowych. Zazwyczaj są one używane do przekazywania informacji technicznych, takich jak sposób, w jaki przeglądarka powinna buforować zawartość, jaki jest typ zawartości, oprogramowanie działające na serwerze i wiele, wiele więcej. Obecnie nagłówki HTTP wykorzystuje się do przekazywania zasad bezpieczeństwa do przeglądarki. Dzięki przekazywaniu zasad bezpieczeństwa z powrotem do klienta w ten sposób, hosty mogą zapewnić znacznie bezpieczniejsze przeglądanie stron przez odwiedzających, a także zmniejszyć ryzyko dla wszystkich zainteresowanych.

Zabezpieczenie witryny – certyfikat SSL

Stronę internetową możemy zabezpieczyć certyfikatem SSL. Możemy użyć certyfikatów komercyjnych lub bezpłatnego certyfikatu Let’s Encrypt. W repozytorium WordPressa znajdziemy wtyczki, które pomagają zainstalować certyfikat SSL. Jedną z nich jest Really Simple SSL. Można to zrobić również bez instalacji wtyczki, ale jest to zadanie bardziej złożone. Po instalacji certyfikatu SSL podstawowy nagłówek komunikacji HTTP przyjmuje wartość HTTPS. Bezpłatna wersja wtyczki, o której wyżej wspomniałem poinformuje nas między innymi, że zalecane jest zabezpieczenie dodatkowych nagłówków – w tym przypadku opcje dostępne w wersji premium. Nie musimy od razu kupować wersji premium, gdyż możemy samodzielnie odpowiednio skonfigurować ustawienia w swojej witrynie.

Przedstawione poniżej nagłówki dają przeglądarce więcej informacji o tym, jak chcesz, aby zachowywała się w odniesieniu do Twojej witryny. Mogą one być używane do przekazywania zasad bezpieczeństwa, ustawiania opcji konfiguracyjnych i wyłączania funkcji przeglądarki, których nie chcesz włączać dla swojej witryny. Aby je wdrożyć, możesz dodać nagłówki wymienione poniżej do pliku .htaccess swojej witryny. Zaloguj się przez FTP do swojej witryny i znajdź plik .htaccess. Jeśli go nie ma, możesz go utworzyć w notatniku Windowsa, choć ja preferuję program Notepad++ i wyślij go na serwer. Pamiętajmy, że najważniejsze jest bezpieczeństwo naszej witryny, więc przed jakąkolwiek modyfikacją pliku .htaccess należy bezwzględnie utworzyć jego kopię, aby w przypadku niepowodzenia wrócić do wersji sprzed zmian. Po skonfigurowaniu każdego nagłówka, sprawdź go, używając skanera https://securityheaders.com/

HTTP Strict Transport Security

Konfiguracja tego nagłówka wymaga wcześniejszego zainstalowania certyfikatu SSL. Następnie przy użyciu wyżej wymienionej wtyczki następuje przekierowanie z przeglądania stron przez HTTP na HTTPS. Jeśli nie używamy wtyczek do przekierowania, w pliku .htaccess umieszczamy odpowiednie polecenia:

RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

HTTP Strict Transport Security (HSTS) informuje przeglądarkę, że zawsze chcesz, aby użytkownik łączył się za pomocą HTTPS zamiast HTTP. Oznacza to, że wszelkie zakładki, linki lub adresy, które użytkownik wpisuje, będą zmuszone do korzystania z HTTPS, nawet jeśli użytkownik wpisze HTTP. Po ustawieniu HSTS komunikacja przeglądarki z serwerem odbywa się wyłącznie przez bezpieczne połączenie. Wstawiamy więc kod:

Header always set Strict-Transport-Security max-age=31536000; includeSubDomains

Ta polityka będzie egzekwować TLS (ang. Transport Layer Security) – przyjęte jako standard w Internecie rozwinięcie protokołu SSL – na Twojej stronie i wszystkich subdomenach przez rok. Według informacji podawanych przez Google, witryny wykorzystujące HSTS dodawane są do listy najlepszych domen internetowych, co powoduje, że jednocześnie są wyżej pozycjonowane. Jest to więc jeden z kroków do optymalizacji SEO naszej witryny.

Content Security Policy

Dzięki CSP możesz zdefiniować, z jakich domen Twoja strona może ładować zasoby, takie jak obrazy, arkusze stylów, pliki javascript itp. Jest to jeden z bardziej zaawansowanych nagłówków. Ze względu na modułową naturę WordPressa, każda wtyczka i motyw może dodać własne zasoby, takie jak Google Fonts. Również usługi społecznościowe, takie jak Facebook, Instagram, Google Maps, itp, będą ładować zewnętrzne zasoby. Nagłówek CSP pozwala na zdefiniowanie białej listy zatwierdzonych źródeł treści dla Twojej witryny. CSP może działać jako skuteczny środek zaradczy dla ataków XSS (ang. Cross Site Scripting), czyli próby umieszczenia w witrynach internetowych kodu, który zmieni ich treść lub funkcjonalność. Poniżej przedstawiam podstawową politykę wymuszania TLS:

Header always set Content-Security-Policy default-src https: data: 'unsafe-inline' 'unsafe-eval'

CSP posiada ogromną liczbę funkcji, które mogą mieć wpływ na funkcjonalność Twojej witryny – należy stosować je z rozwagą. W razie konieczności pamiętamy o tym, że przed wprowadzeniem zmian wykonujemy kopię pliku .htaccess. Bezpieczeństwo nagłówków CSP możemy indywidualnie zdefiniować używając generatora online na stronie https://report-uri.com/home/generate.

X-Frame-Options

Nagłówek X-Frame-Options chroni odwiedzających przed atakami typu clickjacking. Atakujący może załadować ramkę iframe na swojej stronie i ustawić Twoją stronę jako źródło. Używając sprytnego CSS, może ukryć Twoją witrynę w tle i stworzyć autentycznie wyglądające nakładki. Kiedy odwiedzający klikają na to, co wydaje im się nieszkodliwym linkiem, w rzeczywistości klikają na linki na Twojej stronie w tle. To może nie wydawać się takie złe, dopóki nie uświadomimy sobie, że przeglądarka wykona te żądania w kontekście użytkownika, który może być zalogowany i uwierzytelniony na Twojej stronie. Poprawne wartości to DENY, co oznacza, że Twoja strona nie może być obramowana, SAMEORIGIN, co pozwala na obramowanie Twojej własnej strony lub ALLOW-FROM https://example.com/, co pozwala na określenie stron, które mogą być obramowane na Twojej wiytynie. Dopisujemy więc kod:

Header always set X-Frame-Options SAMEORIGIN

X-Xss-Protection

Ten nagłówek stosuje się do konfiguracji wbudowanej ochrony przed atakami XSS w Internet Explorerze, Chrome i Safari. Istnieją trzy wartości ustawienia dla tego nagłówka:
– 0 – wyłącza ochronę,
– 1 – włącza ochronę,
– 1; mode=block – który mówi przeglądarce, aby zablokować odpowiedź, jeśli wykryje atak, zamiast oczyszczać skrypt. Dopisujemy kolejny kod:

Header always set X-Xss-Protection 1; mode=block

X-Content-Type-Options

Jest to łatwy do skonfigurowania nagłówek, który ma tylko jedną poprawną wartość – nosniff. Ten nagłówek zmusi przeglądarkę, aby nie „zgadywała” jaki rodzaj danych jest przekazywany. Jeśli rozszerzeniem jest „.zip”, przeglądarka powinna otrzymać plik .zip, a nie coś innego (.exe). W przeciwnym razie przeglądarka może zostać podstępnie zmuszona do wykonania skryptu, podczas gdy użytkownik myśli, że pobiera bezpieczny plik. W naszym pliku .htaccess dopisujemy kod:

Header always set X-Content-Type-Options nosniff

Szerzej o tym nagłówku przeczytasz w tym artykule.

Permissions Policy

Permissions Policy jest dodatkową warstwą bezpieczeństwa, która pomaga ograniczyć nieautoryzowany dostęp lub wykorzystanie funkcji przeglądarki/klienta przez zasoby sieciowe. Nagłówek HTTP Permissions-Policy zastępuje istniejący nagłówek Feature-Policy do kontroli delegacji uprawnień. Używa on ustrukturyzowanej składni i pozwala witrynom na ściślejsze ograniczenie tego, które źródła mogą uzyskać dostęp do funkcji. Permissions Policy pozwala określić, które funkcje przeglądarek mogą być używane przez witrynę, takie jak kamera, mikrofon, lokalizacja, pełny ekran itp. Sam decydujesz o ograniczeniach umieszczonych na swojej stronie. Dla przykładu kod:

Header set Permissions-Policy: geolocation=(self "https://example.com"), microphone=()

pozwala na własną geolokalizację witryny https://example.com i nie zezwala na użycie mikrofonu.

Inne możliwości wykorzystania nagłówka tego przedstawiam w artykule Permissions Policy.

Referrer Policy

Referrer Policy pozwala witrynie kontrolować wartość nagłówka referrer w linkach odsyłających z ich stron. Jego funkcjonowanie można przedstawić następująco: gdy użytkownik klika link na jednej stronie, źródłowej, która przenosi go na inną stronę, docelową, strona docelowa otrzymuje informacje o źródle, z którego przyszedł użytkownik. W ten sposób otrzymujemy metryki, takie jak te dostarczane przez Google Analytics, dotyczące tego, skąd pochodzi nasz ruch. Dla bezpieczeństwa naszej witryny warto ustawić parametr:

Referrer-Policy: no-referrer-when-downgrade

który wymusza używanie tego samego protokołu i nie pozwala na jego obniżenie (HTTPS -> HTTP). W ten sposób przekierowanie nigdy nie będzie wymuszało zmiany przejścia na mniej bezpieczny protokół (http).

Expect-CT

Urząd Certyfikacji (wystawca certyfikatu SSL) musi rejestrować wydawane certyfikaty w osobnym dzienniku, w ramach CT (Certificate Transparency). Dzięki temu dziennikowi nieuczciwe Urzędy mogą być szybciej wykryte, a nieprawidłowo wystawione certyfikaty mogą być szybko usunięte. Do naszego pliku dodajemy kolejną linijkę kodu:

Expect-CT: enforce, max-age=30

Przeglądarka będzie teraz buforować i egzekwować tę politykę na wszystkich połączeniach z twoją witryną przez następne 30 sekund. Jeśli na stronie nie wystąpią problemy z funkcjonalnością, możesz stopniowo zwiększać tę wartość, np do minuty, potem 15 minut, godziny, dnia, tygodnia i tak dalej.

Inne nagłówki bezpieczeństwa

Inne nagłówki to Cross-Origin Resource Sharing (CORS), Cross-Origin Resource Policy (CORP), Cross-Origin-Embedder-Policy (COEP) i Cross-Origin-Opener-Policy (COOP). Nagłówki te zapobiegają kilku rodzajom ataków, z których najważniejszym jest Spectre. Korzystanie z niektórych web API może zwiększyć ryzyko ataków takich jak Spectre. Aby zmniejszyć to ryzyko, te nowe nagłówki próbują osiągnąć „cross origin isolation”. Nie jest to możliwe we wszystkich konfiguracjach, ale każdy dodany nagłówek poprawia bezpieczeństwo Twojej strony.
Powyższe nagłówki (CORS, CORP, COEP i COOP) nie mają aktualnie bezpośredniego wpływu na ocenę bezpieczeństwa Twojej witryny. Więcej informacji znajdziesz na stronie https://scotthelme.co.uk/coop-and-coep/.

Nagłówki bezpieczeństwa – podsumowanie

Każdy z użytkowników ma bezpośredni wpływ na bezpieczeństwo swojej witryny. Bywa tak, że użytkownik nie jest świadomy pewnych zagrożeń lub zdaje sobie sprawę, że istnieją, ale z różnych przyczyn je ignoruje. Uważam, że warto poświęcić trochę czasu, aby nasza witryna posiadała określone zabezpieczenia. Jednym z tych zabezpieczeń jest certyfikat SSL, innym nagłówki bezpieczeństwa. Zachęcam do stosowania obu rozwiązań. Można to obrazowo porównać do zabezpieczenia domu. Certyfikat SSL jest jak zamknięte na stosowny zamek drzwi do domu, natomiast nagłówki bezpieczeństwa jak inne miejsca w domu, przez które można się dostać, takie jak drzwi od garażu, okna, drzwi od strony tarasu itp. Jeżeli drzwi główne są zamknięte, a inne drzwi i okna otwarte, to nie zapewniamy właściwej ochrony naszego domu. Podobnie jest z witryną. Korzystając z powyższego artykułu, możesz osiągnąć indeks A+, o którym pisałem również w artykule Strona internetowa – jak ją założyć? Możesz też zamówić usługę Nagłówki bezpieczeństwa – konfiguracja.
W przypadku wątpliwości napisz do mnie.

Tag Archive for: nagłówki bezpieczeństwa