Co to jest nagłówek http „X-XSS-Protection”?

194

Więc bawię się teraz HTTP dla zabawy w Telnet (tj. Po prostu telnet google.com 80wpisuję i wprowadzam losowe GET i POST z różnymi nagłówkami itp.), Ale natrafiłem na coś, co google.com przesyła w swoich nagłówkach, które ja nie wiem

Przeglądałem http://www.w3.org/Protocols/rfc2616/rfc2616.html i nie znalazłem definicji tego konkretnego nagłówka http, który Google wydaje się wylewać:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

Czy ktoś wie co X-XSS-Protectionto jest?

midc111
źródło
6
FWIW, „poprawnym” miejscem do sprawdzania specyfikacji pól nagłówka nie jest specyfikacja HTTP (obecnie RFC 2616), ale rejestr pól nagłówka wiadomości IANA (to powiedziawszy, nie ma tam na liście)
Julian Reschke
1
@JulianReschke, dlaczego tak jest? Czy specyfikacja HTTP nie powinna być autorytatywna w przypadku HTTP?
Pacerier
1
Specyfikacja HTTP deleguje rejestr nagłówka do IANA.
Julian Reschke

Odpowiedzi:

107

X-XSS-Protection to nagłówek HTTP rozumiany przez Internet Explorer 8 (i nowsze wersje). Ten nagłówek pozwala domenom włączać i wyłączać „Filtr XSS” IE8, co zapobiega niektórym kategoriom ataków XSS. IE8 ma domyślnie włączony filtr, ale serwery mogą się wyłączyć, jeśli są ustawione

   X-XSS-Protection: 0

Zobacz także http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header. aspx

Luca Invernizzi
źródło
108
To jest bardzo niejasne. Dokładnie w jaki sposób ten nagłówek zapobiega XSS? Więc teraz IE widzi, X-XSS-Protection:1a następnie, jakiego algorytmu używa, aby zapobiec XSS?
Pacerier
11
Trudno znaleźć szczegóły, ponieważ jest to zastrzeżona technologia. Zasadniczo IE monitoruje, czy którykolwiek z podejrzanie wyglądających parametrów wysyłanych przez przeglądarkę do strony internetowej wraca w zdekodowanej odpowiedzi. Na przykład, jeśli użytkownik kliknie na attack-me.com/… (czyli „> <script> alert” („XSS”) </script>) i otrzyma w rezultacie stronę zawierającą ten skrypt, IE to zapobiegnie.
Luca Invernizzi
11
Jako takie wydaje mi się (trudno jest znaleźć dowód), że chroni on tylko przed Reflected XSS ( infosecisland.com/blogview/... ), również dlatego, że nie ma żadnego sposobu na wykrycie zapisanego XSS (zwanego również trwałym XSS).
Luca Invernizzi
11
hmm wydaje się puchnąć w marketingu przez Microsoft, aby IE wyglądał lepiej ....
Matej
5
Cóż, jest przedstawiony w puchu marketingowym, ale kod wydaje się działać. Możesz to przetestować tutaj enhie.com/test/xss/BlockMode.asp (również link w blogu MSDN).
Luca Invernizzi,
61
  • X-XSS-Protection: 1 : Wymuś ochronę XSS (przydatne, jeśli ochrona XSS została wyłączona przez użytkownika)

  • X-XSS-Protection: 0 : Wyłącz ochronę XSS

  • Token mode=blockuniemożliwi przeglądarce (IE8 + i przeglądarkom Webkit) renderowanie stron (zamiast czyszczenia) w przypadku wykrycia potencjalnego ataku odbicia XSS (= nietrwałego).

/! \ Warning, mode=blocktworzy lukę w IE8 ( więcej informacji ).

Więcej informacji: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx i http://blog.veracode.com / 2014/03 / wytyczne-do-ustawiania-nagłówków bezpieczeństwa /

Fabien Sa
źródło
6
Dla przypomnienia, błąd IE8 został naprawiony (CVE-2009-4074)
yakatz
developer.mozilla.org/es/docs/Web/HTTP/Headers/X-XSS-Protection W tym linku możemy znaleźć opis X-XSS-Protection
Maria Czarnogóra
1
Pamiętaj, że 0jest to jedyna bezpieczna wartość dla tego nagłówka. Szczegółowe informacje można znaleźć na stronie stackoverflow.com/a/57802070/334451 .
Mikko Rantalainen,
49

Tego nagłówka odpowiedzi można użyć do skonfigurowania wbudowanej ochrony odblaskowej XSS klienta użytkownika. Obecnie tylko Microsoft Internet Explorer, Google Chrome i Safari (WebKit) obsługują ten nagłówek.

Internet Explorer 8 zawiera nową funkcję, która pomaga zapobiegać atakom typu „cross-site scripting”, znanym jako Filtr XSS . Ten filtr działa domyślnie w strefach bezpieczeństwa Internet, Zaufany i Ograniczony. Strony strefy lokalnego intranetu mogą włączyć ochronę za pomocą tego samego nagłówka.

O nagłówku, który opublikowałeś w swoim pytaniu,

Nagłówek X-XSS-Protection: 1; mode=blockwłącza filtr XSS. Zamiast odkażać stronę, gdy zostanie wykryty atak XSS, przeglądarka uniemożliwi renderowanie strony.

W marcu 2010 r. Dodaliśmy obsługę IE8 nowego tokena w nagłówku X-XSS-Protection, mode = block.

X-XSS-Protection: 1; mode=block

Gdy ten token jest obecny, jeśli zostanie wykryty potencjalny atak odbicia XSS, Internet Explorer uniemożliwi renderowanie strony. Zamiast próbować zdezynfekować stronę w celu chirurgicznego usunięcia ataku XSS, IE wyświetli tylko „#”.

Internet Explorer rozpoznaje możliwy atak skryptu między witrynami. Rejestruje zdarzenie i wyświetla odpowiedni komunikat dla użytkownika. Artykuł MSDN opisuje sposób działania tego nagłówka.

Jak działa ten filtr w IE ,

Więcej na temat tego artykułu: https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

Filtr XSS działa jako komponent IE8 z widocznością wszystkich żądań / odpowiedzi przepływających przez przeglądarkę. Gdy filtr wykryje prawdopodobne XSS w żądaniu obejmującym wiele witryn, identyfikuje i neutralizuje atak, jeśli zostanie odtworzony w odpowiedzi serwera. Użytkownikom nie są zadawane pytania, na które nie są w stanie odpowiedzieć - IE po prostu blokuje wykonanie szkodliwego skryptu.

Dzięki nowemu filtrowi XSS użytkownicy IE8 Beta 2 napotykający atak XSS typu 1 zobaczą następujące powiadomienie:

Powiadomienie o ataku IE8 XSS

Strona została zmodyfikowana, a atak XSS jest zablokowany.

W takim przypadku filtr XSS wykrył atak skryptu między witrynami w adresie URL. Zneutralizował ten atak, ponieważ zidentyfikowany skrypt został ponownie odtworzony na stronie odpowiedzi. W ten sposób filtr działa bez modyfikowania początkowego żądania do serwera lub blokowania całej odpowiedzi.

Zdarzenie filtru skryptów krzyżowych jest rejestrowane, gdy program Windows Internet Explorer 8 wykrywa i łagodzi atak skryptów krzyżowych (XSS). Ataki typu cross-site scripting mają miejsce, gdy jedna strona internetowa, zazwyczaj złośliwa, wstrzykuje (dodaje) kod JavaScript do innych uzasadnionych żądań. Pierwotne żądanie jest generalnie niewinne, takie jak link do innej strony lub skrypt Common Gateway Interface (CGI) zapewniający wspólną usługę (np. Księga gości). Wstrzyknięty skrypt zazwyczaj próbuje uzyskać dostęp do uprzywilejowanych informacji lub usług, na które druga strona nie zamierza zezwolić. Odpowiedź lub żądanie zasadniczo odzwierciedla wyniki z powrotem na złośliwej stronie internetowej. Filtr XSS, funkcja nowa w Internet Explorerze 8, wykrywa JavaScript w żądaniach URL i HTTP POST. Jeśli zostanie wykryty JavaScript, Filtr XSS wyszukuje dowody odbicia, informacje, które zostałyby zwrócone na atakującą stronę, gdyby żądanie ataku zostało przesłane bez zmian. W przypadku wykrycia odbicia filtr XSS dezynfekuje pierwotne żądanie, aby nie można było wykonać dodatkowego kodu JavaScript. Następnie filtr XSS rejestruje tę akcję jako zdarzenie filtru skryptu krzyżowego. Poniższy obraz przedstawia przykład witryny zmodyfikowanej w celu zapobiegania atakowi skryptów między witrynami.

Źródło: https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Twórcy stron internetowych mogą chcieć wyłączyć filtr dla swoich treści. Mogą to zrobić, ustawiając nagłówek HTTP:

X-XSS-Protection: 0

Więcej informacji na temat nagłówków bezpieczeństwa w

Szczęściarz
źródło
1
Pamiętaj, że X-XSS-Protection: 0jest to jedyny bezpieczny nagłówek dla tej funkcji. Aby uzyskać szczegółowe informacje, patrz stackoverflow.com/a/57802070/334451
Mikko Rantalainen,
10

Możesz zobaczyć na tej liście przydatnych nagłówków HTTP .

Ochrona X-XSS: ten nagłówek włącza filtr skryptów krzyżowych (XSS) wbudowany w najnowsze przeglądarki internetowe. Zazwyczaj i tak jest on domyślnie włączony, więc rolą tego nagłówka jest ponowne włączenie filtra dla tej konkretnej witryny, jeśli został on wyłączony przez użytkownika. Ten nagłówek jest obsługiwany w przeglądarce IE 8+ i Chrome (nie wiadomo, które wersje). Filtr anty-XSS został dodany w Chrome 4. Nie wiadomo, czy ta wersja honoruje ten nagłówek.

Abdul Majid Sheike
źródło
Niestety, ta funkcja powoduje problemy z bezpieczeństwem i jest tylko bezpieczna wartość X-XSS-Protection: 0. Aby uzyskać szczegółowe informacje, patrz stackoverflow.com/a/57802070/334451
Mikko Rantalainen,
9

TL; DR: Wszystkie dobrze napisane strony internetowe (/ aplikacje) muszą emitować nagłówek X-XSS-Protection: 0i po prostu zapomnieć o tej funkcji. Jeśli chcesz mieć dodatkowe zabezpieczenia, które mogą zapewnić lepsze programy klienckie, użyj ścisłego Content-Security-Policynagłówka.

Długa odpowiedź:

Nagłówek HTTP X-XSS-Protectionto jedna z tych rzeczy, które Microsoft wprowadził w Internet Explorerze 8.0 (MSIE 8), które miały poprawić bezpieczeństwo nieprawidłowo napisanych stron internetowych.

Chodzi o zastosowanie pewnego rodzaju heurystyki, aby spróbować wykryć odbicie XSS i automatycznie nijaki atak.

Problematyczną częścią tego jest „heurystyka” i „sterylizacja”. Heurystyka powoduje fałszywe alarmy i kastracja nie może być bezpiecznie wykonana, ponieważ powoduje skutki uboczne, które można zastosować do zaimplementowania ataków XSS i DoS na całkowicie bezpiecznych stronach internetowych.

Złą stroną jest to, że jeśli strona internetowa nie emituje nagłówka, X-XSS-Protectionprzeglądarka będzie zachowywać się tak, jakby nagłówek X-XSS-Protection: 1został wysłany. Najgorsze jest to, że ta wartość jest najmniej bezpieczną wartością ze wszystkich możliwych wartości dla tego nagłówka!

W przypadku danej bezpiecznej witryny internetowej (tzn. Witryny nie ma podatności na błędy XSS odbicia) ta funkcja „ochrony XSS” umożliwia następujące ataki:

X-XSS-Protection: 1pozwala atakującemu na selektywne blokowanie części JavaScript i utrzymanie reszty skryptów w działaniu. Jest to możliwe, ponieważ heurystyka tej funkcji jest po prostu „jeśli wartość dowolnego parametru GET zostanie znaleziona w części skryptowej źródła strony, skrypt zostanie automatycznie zmodyfikowany w sposób zależny od agenta użytkownika”. W praktyce atakujący może np. Dodać parametr, disablexss=<script src="framebuster.js"a przeglądarka automatycznie usunie ciąg <script src="framebuster.js"z faktycznego źródła strony. Pamiętaj, że reszta strony nadal działa, a osoba atakująca właśnie usunęła tę część zabezpieczeń strony. W praktyce każdy JS w źródle strony może być modyfikowany. W niektórych przypadkach strona bez luki w XSS, która ma odzwierciedloną treść, może zostać użyta do uruchomienia wybranego JavaScript na stronie z powodu kastracjiniepoprawne przekształcanie danych tekstowych w wykonywalny kod JavaScript .

X-XSS-Protection: 1; mode=blockpozwala atakującemu na wyciek danych ze źródła strony, wykorzystując zachowanie strony jako boczny kanał. Na przykład, jeśli strona zawiera kod JavaScript wzdłuż linii var csrf_secret="521231347843", atakujący po prostu dodaje dodatkowy parametr, np. leak=var%20csrf_secret="3I jeśli strona NIE jest zablokowana, 3to pierwsza cyfra była niepoprawna. Atakujący spróbuje ponownie, tym razem leak=var%20csrf_secret="5ładowanie strony zostanie przerwane. Dzięki temu atakujący może wiedzieć, że jest to pierwsza cyfra tajemnicy 5. Atakujący następnie zgaduje następną cyfrę.

W końcu, jeśli Twoja witryna jest pełna ataków odbijających XSS, użycie domyślnej wartości 1nieco zmniejszy powierzchnię ataku. Jeśli jednak Twoja witryna jest bezpieczna i nie emitujesz jej X-XSS-Protection: 0, będzie ona narażona na atak w dowolnej przeglądarce obsługującej tę funkcję. Jeśli chcesz uzyskać dogłębną ochronę przed przeglądarkami przed nieznanymi jeszcze lukami XSS w swojej witrynie, użyj ścisłego Content-Security-Policynagłówka. To nie otwiera Twojej witryny na znane luki.

Obecnie ta funkcja jest domyślnie włączona w MSIE, Safari i Google Chrome. Kiedyś było to włączone w Edge, ale Microsoft już usunął tę wadliwą funkcję z Edge . Mozilla Firefox nigdy tego nie implementowała.

Zobacz też:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https: // bugs.chromium.org/p/chromium/issues/detail?id=498982

Mikko Rantalainen
źródło