Dodanie zalecanych nagłówków bezpieczeństwa jest jednym z najprostszych i najszybszych sposobów na podniesienie poziomu bezpieczeństwa aplikacji webowej. Na temat nagłówków bezpieczeństwa można znaleźć bardzo wiele artykułów, jednak warto podejść do nich z pewną ostrożnością, ponieważ jak wszystko w świecie IT i bezpieczeństwa także ten obszar podlega ciągłym zmianom. W tym artykule chciałabym przybliżyć nagłówki bezpieczeństwa, które obecnie są uznawane przez organizację OWASP za standard w tym zakresie oraz wspomnieć o tych, które od kilku lat nie powinny być już stosowane. Zacznijmy jednak od początku, czyli przypomnienia czym są nagłówki odpowiedzi w protokole HTTP.
Czym są nagłówki odpowiedzi HTTP?
Komunikacja HTTP polega na przesłaniu żądania do serwera, który następnie generuje i wysyła odpowiedź na to żądanie. Przykładowo, aby wyświetlić ten artykuł przeglądarka wykonuje żądanie HTTP GET a w odpowiedzi otrzymuje stronę HTML z treścią artykułu oraz dodatkowe informacje w nagłówkach odpowiedzi HTTP. Domyślnie informacje z nagłówków HTTP nie są prezentowane przez przeglądarkę, ale są przez nią wykorzystywane np. do poprawnego wyświetlania strony oraz konfiguracji zabezpieczeń podczas wyświetlania tej strony.
Aby zobaczyć nagłówki odpowiedzi o których mowa, wystarczy wykorzystać narzędzia deweloperskie dowolnej przeglądarki. Jeśli korzystasz z przeglądarki Chrome należy przejść do Chrome menu (trzy kropki w prawym rogu), a następnie wybrać Więcej narzędzi > Narzędzia dla deweloperów. Nagłówki odpowiedzi można zobaczyć po zaznaczeniu żądania, w zakładce Response Headers.
Zwrócone nagłówki odpowiedzi pełnią różne role, w tym artykule interesują nas nagłówki związane z konfiguracją zabezpieczeń.
Jakie nagłówki bezpieczeństwa powinny być stosowane i gdzie szukać aktualnych informacji na ten temat?
Aktualny standard w zakresie nagłówków bezpieczeństwa wyznacza organizacja OWASP, a informacji na ten temat można szukać w jej licznych dokumentach i projektach takich jak OWASP Secure Headers Project, OWASP ASVS oraz OWASP Cheat Sheet Series.
W niniejszym artykule przedstawię moim zdaniem najistotniejsze nagłówki bezpieczeństwa, których stosowanie pozwoli w łatwy sposób znacząco zwiększyć bezpieczeństwo aplikacji webowej. Nagłówki te znajdują się na liście zalecanych według OWASP Secure Headers Project oraz OWASP ASVS, czyli standardu dotyczącego zabezpieczania i testowania aplikacji webowych (wersja 4.0.3 aktualna w lutym 2022 rozdział dotyczący konfiguracji - V14 Configuration, w sekcja V14.4 HTTP Security Headers).
Nagłówki Content-Type oraz X-Content-Type-Options
Nagłówek Content-Type ma za zadanie poinformować przeglądarkę o typie MIME zwracanego w odpowiedzi HTTP dokumentu oraz jego kodowaniu, dzięki czemu przeglądarka będzie mogła go poprawnie zinterpretować i wyświetlić. Nagłówek ten powinien być zwracany dla każdego zasobu, czyli w każdej odpowiedzi na żądanie. W niektórych przypadkach, jeśli typ nie pasuje do zwracanego dokumentu, przeglądarka może próbować odgadnąć typ dokumentu i zinterpretować właściwie do odgadniętego typu ignorując informacje przesłane w nagłówku Content-Type.
Zabezpieczeniem przed takim problemem jest nagłówek X-Content-Type-Options. Jego konfiguracja jest prosta ponieważ może on przyjąć tylko jedną zalecaną wartość tj. X-Content-Type-Options: nosniff.
Celem zabezpieczenia jest uniknięcie sytuacji, gdzie przeglądarka przekształci z założenia niewykonywalny typ dokumentu do dokumentu wykonywalnego w wyniku zgadywania jego zawartości (typu MIME).
Nagłówek HTTP Strict Transport Security
Zwrócenie nagłówka HSTS informuje przeglądarki internetowe wspierające HSTS (obecnie wszystkie nowoczesne przeglądarki) o możliwości połączenia tylko z wykorzystaniem połączenia szyfrowanego, czyli HTTPS.
Nagłówek powstał aby zapewnić korzystanie z protokołu szyfrowanego nawet w przypadku problemów konfiguracyjnych i błędów implementacji (np. błędnych przekierowań na adres po http wynikające z zahardkodowanych adresów). Po stronie przeglądarki jest zapewnienie, że nigdy nie dojdzie do połączenia z wykorzystaniem nieszyfrowanego protokołu HTTP. Jest to realizowane przez automatyczną zmianę http na https.
Dodatkowo zastosowanie nagłówka powoduje wyłączenie łatwych do zaakceptowania przez użytkownika ostrzeżeń dotyczących bezpieczeństwa certyfikatu np. nieważny lub niepoprawny certyfikat, które bywają akceptowane bez dokładnej analizy.
Rekomendowana jest następująca konfiguracja nagłówka ustawiająca go na dwa lata (max-age): Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Nagłówek powinien zostać skonfigurowany dla głównej domeny, a domena powinna zostać dodana do listy domen HSTS Preload, czyli listy domen stosujących nagłówek HSTS.
Nagłówek Content-Security-Policy
Nagłówek Content Security Policy (CSP) pozwala na zdefiniowanie, skąd mogą pochodzić dodatkowe zasoby, z których korzysta aplikacja www (pliki zewnętrzne JavaScript czy CSS, obrazki i inne elementy multimedialne) poprzez utworzenie listy dopuszczalnych lokalizacji takich zasobów. Wszystkie zasoby spoza listy będą przez przeglądarkę odrzucone. Zabezpieczenie to pozwala m. in. na zapobieganie przed XSS, które dołączają do źródeł strony skrypty z innych lokalizacji. Ze względu na złożoność i rozbudowanie standardu CSP można by napisać o nim osobny artykuł. W tej publikacji jedynie zaznaczam konieczność jego stosowania.
Nagłówek X-Frame-Options lub dyrektywa CSP frame-ancestors
Nagłówek X-Frame-Options chroni przed kradzieżą kliknięć, czyli atakiem Clickjacking. Nagłówek informuje przeglądarkę, czy aplikacja może być wyświetlona w ramce na innej domenie. Zazwyczaj w ataku Clickjacking w miejscu wskazanym użytkownikowi do kliknięcia na innej domenie znajduje się niewidoczna ramka zawierająca podatną aplikację. Użytkownik klikając w odnośnik nieświadomie wykonuje pewną akcję w podatnej aplikacji. Aby zabezpieczyć aplikację przed tego typu atakami należy ustawić nagłówek z wartością X-Frame-Options: DENY (brak możliwości umieszczania w ramce) lub X-Frame-Options: SAMEORIGIN (ramka pochodzi z tej samej domeny). Nagłówek nadal jest stosowany jednak obecnie jest wypierany przez nagłówek CSP i dyrektywę CSP frame-ancestors. Ustawienie w postaci Content-Security-Policy: frame-ancestors 'none'; jest praktycznie odpowiednikiem DENY, a ustawienie Content-Security-Policy: frame-ancestors 'self'; opcji SAMEORIGIN (więcej informacji na temat niewielkich różnic można znaleźć tutaj. W przypadku stosowania obu nagłówków to dyrektywa CSP będzie stosowana.
Nagłówek X-XSS-Protection i dlaczego już go nie stosujemy
Nagłówek X-XSS-Protection jeszcze kilka lat temu był jednym z zalecanych zabezpieczeń przed atakami XSS typu Reflected. Przeglądarki (z wyjątkiem Firefox) posiadały wbudowany filtr mający na celu wyłapywanie ataków XSS typu Reflected poprzez weryfikację, czy w żądaniu HTTP nie pojawiają się fragmenty HTML lub JS, które później w niezmienionej postaci znajdują się w odpowiedzi. Nagłówek ma dosyć ciekawą historię, ponieważ wielokrotnie badacze bezpieczeństwa pokazywali, że może ono zostać wykorzystany do wprowadzenia podatności tam gdzie jej nie było, co nie świadczy za dobrze o takim zabezpieczeniu ☺. Ze względu na pojawianie się tego typu problemów z filtrami anty-XSS przeglądarek, z czasem przeglądarki zaczęły odchodzić od tego zabezpieczenia. Chrome oraz Edge kilka lat temu wycofały filtry z przeglądarek.
Obecnie wsparcie przeglądarek dla nagłówka X-XSS-Protection wygląda w następujący sposób (źródło):
Jak widać najbardziej popularne przeglądarki wycofały wsparcie dla tego nagłówka, wyjątkiem jest Safari i IE. Serwis caniuse.com wskazuje, że nagłówek jest wspierany przez 6.87% przeglądarek. Są to przeglądarki Safari i IE lub nieaktualne wersje innych przeglądarek. Co patrząc na statystyki użycia prezentuje się w następujący sposób:
Mimo braku wsparcia ze strony większości nowoczesnych przeglądarek nagłówek nadal jest często wykorzystywany przez aplikacje webowe. Shodan dla zapytania "x-xss-protection:1" country:"PL" zwraca ponad 122 tysiące wyników, a wśród aplikacji wykorzystujących nagłówek z włączonym filtrem są m. in. popularne aplikacje bankowe. Bywa też że spotykam się z raportami z testów bezpieczeństwa zawierających nieaktualne rekomendacje w zakresie wykorzystanie tego nagłówka. Dlatego jeśli wasze checklisty do testów nadal wskazują na ten nagłówek to warto je zaktualizować.
W rozdziale dotyczącym nagłówka X-XSS-Protection dokumentu OWASP Cheat Sheet Series mamy rekomendację dotyczącą ustawienia go z wartością X-XSS-Protection: 0, czyli wyłączeniem filtrów przeglądarek. Takie wyłączenie jest korzystne w przypadku starszych wersji przeglądarek, które jeszcze wspierają ten nagłówek (w szczególności będzie to korzystne dla użytkowników starych wersji przeglądarek z domyślnie włączonym filtrem XSS).
Poniżej dokładna treść rekomendacji:
„ The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. As such, it is recommended to set the header as X-XSS-Protection: 0 in order to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response.”
Autorzy dokumentu przyjęli podejście, że dopóki część użytkowników może jeszcze korzystać z przeglądarek wspierających nagłówek X-XSS-Protection warto konfiguracją nagłówka wyłączyć działanie ich filtrów anty-XSS, aby uniknąć ewentualnych podatności wprowadzonych przez błędy w implementacji takich filtrów. Obecnie jest to najrozsądniejsze podejście, w przyszłości kiedy wszystkie przeglądarki zrezygnują ze wspierania tego nagłówka będzie można z niego zrezygnować.
Jeśli ze specyfiki aplikacji wynika, że użytkownicy korzystają z aktualnych wersji konkretnych przeglądarek, które nie wspierają nagłówka (np. aplikacje wewnętrzne) sensowna wydaje się rezygnacja z niego już teraz.
Weryfikacja konfiguracji nagłówka
Weryfikacja w zakresie nagłówków bezpieczeństwa jest prosta, wystarczy wyświetlić nagłówki odpowiedzi HTTP np. korzystając z narzędzi deweloperskich przeglądarki. Taki prosty test można wykonać np. w trakcie wykonywania innych testów. Weryfikację nagłówków odpowiedzi wykonują również skanery automatyczne, np. OWASP ZAP, Burp Suite. Jeżeli testowana aplikacja jest dostępna z Internetu do weryfikacji nagłówków można wykorzystać narzędzie Security Headers. Po podaniu adresu naszej aplikacji i wykonaniu skanowania dostajemy ogólną ocenę poprawności konfiguracji nagłówków (w zakresie kompletności oraz konfiguracji nagłówków). Narzędzie informuje nas jakich nagłówków brakuje i z jaką wartością powinniśmy je ustawić.
Przykładowe wyniki skanowania jedna z lepszych konfiguracji oceniona na A, a następnie brak konfiguracji nagłówków skutkujący oceną F.
Podsumowanie
Jednym z prostych sposobów na zwiększenie ogólnego poziomu bezpieczeństwa aplikacji webowej jest stosowanie nagłówków bezpieczeństwa. Ważne aby pamiętać o ich odpowiedniej konfiguracji zgodnej z obowiązującymi rekomendacjami w tym zakresie. Wymienione w artykule nagłówki bezpieczeństwa stanowią jedynie część nagłówków, które należy stosować w aplikacjach webowych. Po pełne rekomendacje w tym zakresie odsyłam do wspomnianych dokumentów OWASP Secure Headers Project, OWASP ASVS oraz OWASP Cheat Sheet Series.
