X-Content-Type-Options

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.

X-Frame-Options

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.

Strict Transport Security

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.

Permissions Policy

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.