Więc bawię się teraz HTTP dla zabawy w Telnet (tj. Po prostu telnet google.com 80
wpisuję 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-Protection
to jest?
http
http-headers
xss
midc111
źródło
źródło
Odpowiedzi:
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
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
źródło
X-XSS-Protection:1
a następnie, jakiego algorytmu używa, aby zapobiec XSS?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ę XSSToken
mode=block
uniemożliwi przeglądarce (IE8 + i przeglądarkom Webkit) renderowanie stron (zamiast czyszczenia) w przypadku wykrycia potencjalnego ataku odbicia XSS (= nietrwałego)./! \ Warning,
mode=block
tworzy 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 /
źródło
0
jest to jedyna bezpieczna wartość dla tego nagłówka. Szczegółowe informacje można znaleźć na stronie stackoverflow.com/a/57802070/334451 .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=block
włącza filtr XSS. Zamiast odkażać stronę, gdy zostanie wykryty atak XSS, przeglądarka uniemożliwi renderowanie strony.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/
Ź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:
Więcej informacji na temat nagłówków bezpieczeństwa w
Wytyczne dotyczące ustawiania nagłówków bezpieczeństwa
Zabezpieczenia Nagłówki HTTP - OCHRONA X-XSS
MDN Docs X-XSS-Protection
źródło
X-XSS-Protection: 0
jest to jedyny bezpieczny nagłówek dla tej funkcji. Aby uzyskać szczegółowe informacje, patrz stackoverflow.com/a/57802070/334451Możesz zobaczyć na tej liście przydatnych nagłówków HTTP .
źródło
X-XSS-Protection: 0
. Aby uzyskać szczegółowe informacje, patrz stackoverflow.com/a/57802070/334451TL; DR: Wszystkie dobrze napisane strony internetowe (/ aplikacje) muszą emitować nagłówek
X-XSS-Protection: 0
i po prostu zapomnieć o tej funkcji. Jeśli chcesz mieć dodatkowe zabezpieczenia, które mogą zapewnić lepsze programy klienckie, użyj ścisłegoContent-Security-Policy
nagłówka.Długa odpowiedź:
Nagłówek HTTP
X-XSS-Protection
to 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-Protection
przeglądarka będzie zachowywać się tak, jakby nagłówekX-XSS-Protection: 1
został 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: 1
pozwala 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=block
pozwala 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ż liniivar csrf_secret="521231347843"
, atakujący po prostu dodaje dodatkowy parametr, np.leak=var%20csrf_secret="3
I jeśli strona NIE jest zablokowana,3
to pierwsza cyfra była niepoprawna. Atakujący spróbuje ponownie, tym razemleak=var%20csrf_secret="5
ładowanie strony zostanie przerwane. Dzięki temu atakujący może wiedzieć, że jest to pierwsza cyfra tajemnicy5
. 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
1
nieco zmniejszy powierzchnię ataku. Jeśli jednak Twoja witryna jest bezpieczna i nie emitujesz jejX-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łegoContent-Security-Policy
nagłó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
źródło