Zaproponowana przez Google’a wartość ALLOWALL
nagłówka X-Frame-Options
trafiła
pod strzechy bez standaryzacji. Sęk jednak w tym, że jest to zupełnie niepotrzebna
opcja.
Nagłówek X-Frame-Options
to mocno zubożona inkarnacja mechanizmu Content Security
Policy. Pozwala on serwerowi na poinformowanie przeglądarki o tym, że wysyłany do
niej dokument HTML powinien mieć zakaz lub ograniczoną zdolność do bycia ładowanym
i wyświetlanym w tzw. ramkach (ang. frames). Mówiąc o ramkach, mamy na myśli
znaczniki HTML o nazwie frame
oraz iframe
, które pozwalają w pewnym miejscu
wyświetlanej strony WWW wczytać kod dokumentu HTML pochodzącego z innej witryny.
Ramki są często punktem wejścia w przypadku ataków wymierzonych w przeglądarkę klienta. Umieszczona w ten sposób treść może po wyświetleniu przesłaniać oryginalną wersję dokumentu i w niewidoczny sposób podsuwać rozmaite elementy interaktywne, na przykład przechwytujące dane wprowadzane z klawiatury bądź śledzące lub zmieniające działania wynikające z użycia wskaźnika myszy. Warunkiem jest oczywiście zdolność intruza do umieszczenia ramki w zawartości oryginalnej witryny, jednak niektóre strony sieci Web pozwalają na takie działania ze względu na specyfikę świadczonych usług (np. wyświetlanie podglądów dodawanych stron, zewnętrznych reklam czy klipów wideo). Powstały więc mechanizmy, takie jak wspomniany nagłówek, aby pokrzyżować plany „szkodnikom” i sieciowym wandalom, nawet gdy uda im się przemycić własny kod HTML umieszczający ramkę lub skłonić aplikację webową, by zrobiła to za nich i wyświetliła w ramce zawartość pochodzącą np. z zainfekowanej witryny.
Jak to działa?
Ochrona z użyciem nagłówka X-Frame-Options
polega na tym, że serwer wysyła go wraz
z dokumentem, a przeglądarka otrzymuje informację, że dany zasób nie może być
umieszczany w ramkach (wartość DENY
), albo że jest to dopuszczalne pod
warunkiem, że zarówno ładowana zwartość ramki jak i strona, w której jest ona
osadzona, pochodzą z tej samej domeny (wartość SAMEORIGIN
).
Podczas prac nad standardem zaproponowano również trzecią, „magiczną” opcję:
ALLOW-FROM
, która została przyjęta przez komitet IETF i włączona z poprzedniczkami
w proces standaryzacji. Pozwala ona podać uniwersalny lokalizator zasobu (URL), który
będzie uprawniony do ładowania opatrzonej nagłówkiem zawartości w ramce.
Zaskoczenie
Ciekawostką jest fakt, że serwery wyszukiwarkowego giganta służące do emisji reklam
Google AdSense od jakiegoś czasu wysyłają klientom nigdzie nie opisaną
wartość nagłówka ALLOWALL
, chcąc poinstruować przeglądarkę, że powinna dopuszczać
ładowanie do ramek zasobów, bez względu na to, w jakiej witrynie się to zdarzy.
Problem zauważyli programiści silnika WebKit i rozpoczęli prace nad obsługą tej opcji. Zgłoszenie błędu nosi numer 110857 i powstała już odpowiednia, łatka. Co ciekawe, patch działa w ten sposób, że ukrywa ostrzeżenie wyświetlane w konsoli, nie dodając żadnej specjalnej obsługi.
W rezultacie mamy do czynienia z sytuacją, w której pojawiają się całkiem
niestandardowe sposoby wykorzystania X-Frame-Options
. Niestandardowe dlatego, że
wprowadzają precedens polegający na używaniu X-Frame-Options
do zezwalania na
potencjalnie groźne operacje, a nie do blokowania ich. Tymczasem wystarczyłoby po
prostu nie używać tego nagłówka, jeżeli chce się pozwolić na ładowanie wysyłanego
zasobu w ramkach.
Tak wyglądają ostrzeżenia wyświetlane na konsoli języka JavaScript w przeglądarce Chrome 25 (zbyt długie linie zostały złamane; ich kontynuacje zaczynają się podwójnym znakiem odstępu):
Poniżej wszystkie nagłówki odpowiedzi HTTP dołączone do zasobu widocznego pod adresem https://googleads.g.doubleclick.net/pagead/drt/si
:
Zobacz także
- X-Frame-Options response header, opis nagłówka w serwisie Mozilla Developer