X-Content-Type-Options

Nagłówek X-Content-Type-Options to parametr monitoringu stron internetowych, który sprawdza, czy odpowiedź serwera zawiera nagłówek X-Content-Type-Options. Pomiar kończy się jednym z trzech wyników: nagłówek obecny, brak nagłówka albo nie udało się pobrać odpowiedzi. Nagłówek z wartością nosniff mówi przeglądarce, że typy MIME podane w nagłówku Content-Type zostały ustawione celowo i należy ich przestrzegać, a nie zmieniać ^[3].

Jak działa

Nagłówek Content-Type ma wskazywać typ MIME odpowiedzi, ale wiele serwerów podaje wartość niezgodną z zawartością, dlatego przeglądarki od dawna badają także samą treść, żeby ustalić jej faktyczny typ ^[2]. To zgadywanie po bajtach zasobu nazywa się MIME sniffing; każda przeglądarka robi je inaczej, a część typów MIME oznacza treść wykonywalną ^[4]. O sposobie przetworzenia adresu decyduje typ MIME, a nie rozszerzenie pliku ^[4].

Standard Fetch definiuje nagłówek w dwóch krokach. Najpierw przeglądarka ustala, czy obowiązuje nosniff: liczy się tylko pierwsza wartość nagłówka, porównywana bez względu na wielkość liter ^[1]. Potem, jeśli nosniff obowiązuje, blokuje odpowiedź na żądanie skryptu, gdy typ nie jest typem JavaScript albo go brak, oraz odpowiedź na żądanie arkusza stylów, gdy typ nie jest text/css ^[1]. Specyfikacja wyjaśnia, że obejmuje tylko te dwa rodzaje żądań, bo to ich dotyczą znane ataki, a objęcie obrazów okazało się niezgodne z istniejącymi treściami ^[1]. Niezależnie od nagłówka Fetch blokuje jako skrypt odpowiedzi z typem image/*, audio/*, video/* i text/csv ^[1].

RYS. 1.1Plik z błędnym typem wczytany jako skrypt

Dla pozostałych odpowiedzi, także przy przejściu do nowego dokumentu, przeglądarka z nosniff używa podanego Content-Type bez badania treści ^[3]. Odpowiedź z typem text/plain nie zostanie wtedy potraktowana jako HTML, nawet jeśli zawiera znaczniki HTML ^[3]. Standard MIME Sniffing opisuje to szczegółowo: typ HTML lub XML podany przez serwer nigdy nie jest zmieniany ^[2]. Gdy typu brak albo jest nieznany, np. unknown/unknown lub */*, przeglądarka rozpoznaje go po początkowych bajtach, a wzorce typów „skryptowalnych” (HTML, XML, PDF) sprawdza tylko wtedy, gdy zgadywanie nie zostało wyłączone ^[2]. Przy wyłączonym zgadywaniu obliczony typ jest po prostu typem podanym przez serwer ^[2].

RYS. 1.2Decyzja przeglądarki o typie odpowiedzi

Standardy i specyfikacje

• Fetch Standard (WHATWG) definiuje algorytm ustalania nosniff i blokowania skryptów oraz stylów; jedyną poprawną wartością jest nosniff, bez rozróżniania wielkości liter ^[1].
• MIME Sniffing Standard (WHATWG) powstał, bo przeglądarki odtwarzały nawzajem swoje algorytmy zgadywania, co dawało rozbieżne zachowania, w części ze skutkami dla bezpieczeństwa ^[2]. Algorytm wywodzi się z badań Adama Bartha, Juana Caballero i Dawn Song ^[2]. Standard nie używa rozszerzeń plików do ustalania typu zasobu pobranego przez HTTP, bo są zawodne i łatwe do podrobienia ^[2].
• Historia. Microsoft w 2008 roku, przy Internet Explorer 8 Beta 2, zamienił zapowiadany wcześniej atrybut authoritative w nagłówku Content-Type na osobny nagłówek X-Content-Type-Options: nosniff, bo operatorzy serwerów uznali atrybut za trudny we wdrożeniu ^[6]. W IE6 i IE7 plik text/plain zawierający HTML był interpretowany jako HTML, a w IE8 z nosniff wyświetlany jako tekst ^[6].
• OWASP zaleca X-Content-Type-Options: nosniff i poprawne ustawianie Content-Type w całej witrynie ^[5]. MDN zauważa, że testerzy bezpieczeństwa stron zwykle oczekują tego nagłówka i prawidłowego Content-Type dla wszystkich zasobów ^[3].

Zagrożenia i skutki

Pomylenie typów. OWASP opisuje zgadywanie typu jako mechanizm, który może zamienić typ niewykonywalny w wykonywalny, i nazywa to atakami MIME confusion ^[5].

XSS przez przesłane pliki. Według standardu MIME Sniffing problem jest najpoważniejszy, gdy uczciwy serwer pozwala użytkownikom przesyłać pliki i serwuje je z typem o niskich uprawnieniach ^[2]. Jeśli serwer uważa plik za obraz, a przeglądarka za HTML, atakujący może ukraść dane uwierzytelniające użytkownika i przeprowadzić inne ataki XSS ^[2].

Dokumenty-kameleony. Barth, Caballero i Song (2009) opisali pliki, które są jednocześnie poprawne w nieszkodliwym formacie i zawierają HTML ^[7]. Autor mógł przesłać do systemu recenzji HotCRP pracę w PostScripcie, którą Internet Explorer 7 traktował jako HTML; skrypt działał wtedy w imieniu recenzenta i mógł wystawić pracy wysoką ocenę ^[7]. W Wikipedii podobny atak wykorzystywał plik będący jednocześnie obrazem GIF i dokumentem HTML ^[7]. Zasady bezpiecznego zgadywania z tej pracy przyjęły częściowo Internet Explorer 8, a w całości Google Chrome i grupa robocza HTML5 ^[7].

Pliki od użytkowników. Typ Content-Type przesłanego pliku podaje użytkownik, więc łatwo go podrobić ^[8]. Publicznie dostępne pliki mogą nieść aktywną treść po stronie klienta, np. XSS lub CSRF, groźną dla innych użytkowników ^[8]. OWASP zaleca przechowywanie ich na osobnym hoście i podkreśla, że żadna pojedyncza technika nie wystarcza ^[8].

Granice nagłówka. Blokada w Fetch dotyczy wyłącznie skryptów i arkuszy stylów ^[1]. Nagłówek nie naprawia błędnego Content-Type: skrypt serwowany z nieprawidłowym typem i nosniff przestaje się wczytywać ^[1], a źle skonfigurowane typy MIME psują działanie stron ^[4]. Decyzja zapada dla każdej odpowiedzi osobno, na podstawie jej własnej listy nagłówków ^[1].

Przykłady

Odpowiedź serwera	Kontekst	Skutek w przeglądarce
text/javascript + nosniff	skrypt	wczytany [1]
text/plain + nosniff	skrypt	zablokowany [1]
text/plain, bez nosniff	skrypt	Fetch nie blokuje [1]
image/png, bez nosniff	skrypt	zablokowany niezależnie od nagłówka [1]
text/html + nosniff	arkusz stylów	zablokowany, bo typ nie jest text/css [1]
X-Content-Type-Options: foo, nosniff	skrypt lub styl	nosniff nie obowiązuje, liczy się pierwsza wartość [1]
text/plain z treścią HTML + nosniff	dokument	wyświetlony jako tekst [3]
brak Content-Type, treść zaczyna się od <!DOCTYPE HTML, bez nosniff	dokument	może zostać rozpoznany jako text/html [2]
brak Content-Type + nosniff	dokument	wzorce HTML nie są sprawdzane [2] [3]
text/plain z treścią HTML w IE6 i IE7 (2008)	dokument	zinterpretowany jako HTML [6]