TL; 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łego Content-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łówek X-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ż linii var 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 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 1
nieco 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-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