31/8/2010
W czerwcu opisaliśmy kilka sposobów na ochronę serwisów internetowych przed atakimi typu clickjacking (por. clickjacking i framebusting). Dziś dowiedzieliśmy się, że najnowszy Firefox będzie wspierał rozwiązanie X-Frame-Options — warto sobie przypomnieć co to takiego, i zacząć z tego korzystać.
X-Frame-Options
X-Frame-Options to nagłówek HTTP, dodawany przez Webserwer przy odpowiedzi na żądanie przeglądarki. Przyjmuje dwie wartości:
- SAMEORIGIN – tylko strony z tej samej domeny mogą “zramkować” ten URL
- DENY – żadna strona nie może wrzucić w ramkę tego URL-a
Dzięki zastosowaniu powyższego nagłówka, unikamy zagnieżdżania naszej strony w ramkach, czyli ataków typu:
<html>
reklamy, phishing, clickjacking, itp
<iframe src="http://yoursite.com"></iframe>
</html>
Oczywiście, żeby nagłówek X-Frame-Options “działał”, potrzebna jest przeglądarka, która go rozumie. Obecnie, są to:
- Opera 10.50
- Firefox z dodatkiem NoScript
- IE 8+
- Safari 4
a od wersji 3.6.9 Firefox będzie wspierał X-Frame-Options natywnie.
Minusy X-Frame-Options
Warto wspomnieć, że nie zawsze użycie X-Frame-Options jest czymś, czego będziesz chciał. Przypomnijmy minusy, które wymieniliśmy w tekście o framebustingu:
- Trudności w implementacji
Masz duży serwis i chcesz dostosować wartości X-Frame-Options dla każdej z podstron z osobna. Pułapka: jeśli np. ustawisz X-Frame-Options także dla plików graficznych, to Google Images ich nie pokaże. - Masz kilka domen
I niektórym chciałbyś pozwolić na “ramkowanie”, a innym nie. Niestety SAMEORGIN bierze pod uwagę tylko domenę “macierzystą”. - Serwery PROXY
Nagłówek X-Frame-Options może nie dolecieć do użytkownika, serwery proxy często usuwają nagłówki HTTP…
Jeśli pierwsze dwa “problemy” Cię nie dotyczą, zdecydowanie zainteresuj się przekonfigurowaniem swojego webserwera tak, aby wysyłał nagłówek X-Frame-Options przynajmniej dla stron, na których dajesz użytkownikowi możliwość wprowadzania/modyfikowania danych.
Też jakiś czas temu opisywałem wykorzystanie nagłówka X-Frame-Options:
http://blog.kamilbrenk.pl/bezpieczne-naglowki-http/
może kogoś to zainteresuje :-)
Wiecie co mnie w tym wszystkim cieszy, ze czytaja was admini i od razu przejmuja sie rola, mam nadzieje ze tak to bedzie wygladalo i tutaj. Opiniotworczosc fajna jest, byle prawdziwa
A jak przeglądarka, z której korzystamy, zachowa się w połączeniu z nagłówkiem X-Frame-Options można sprawdzić na szybko w moim starym przykładzie poda adresem: http://bootcamp.threats.pl/lesson15/ Tam są dwie “ramki” zwracane z X-Frame-Options SAMEORGIN oraz DENY.
jest 3.8.9 – powinno byc 3.6.9
MSIE 8.0 pokazuje wewnątrz zablokowanej ramki pseudo-stronę:
“Ta zawartość nie może zostać wyświetlona w ramce
[…]
Otwórz tę zawartość w nowym oknie [to jest link]”
No i cała ochrona przed clickjackingiem poszła w las… ktoś na to klika i łapie się na “wyższą” warstwę… tyle tylko, że klikanie może być w innym punkcie ekranu, niż gdyby zawartość ramki się wyświetliła…
Zdaje się, że Chrome/Chromium też to obsługuje, a przynajmniej na stronie podanej przez Pawła widzę co innego pod Chrome i co innego pod IE 6.
“W czerwcu opisaliśmy kilka sposobów na ochronę serwisów internetowych przed atakimi typu calickjacking…”
Hmm… z tego, co pamiętam, to raczej jest clickjacking, bo łapie się click’i, a nie calick’i ;-)
@Bartek:
Przecież tu właśnie o to chodzi.. Żeby nie kliknąć w nic na docelowej stronie, która się nie otworzyła, tylko pojawił się komunikat..
@dzek
Tak, ale problem tkwi w tym linku wewnątrz takiego iframe’a – nie kliknę w nic na docelowej stronie (bo się nie otworzyła), ale mogę kliknąć na linku otwierającym tą stronę w nowym oknie, który się pokazuje… tylko jeśli to jest iframe z wierzchnią warstwą kradnącą kliknięcia, to właśnie to kliknięcie w link zostanie skradzione – zanim otworzę docelową stronę :)
@Bartek: ten link mogę Ci podstawić na kilka innych sposobów, bez użycia iframe. Choćby przez img src.
No właśnie. Twierdze tylko, że stosowanie X-Frame-Options (przynajmniej w przypoadku MSIE 8) w żaden sposób nie zabezpiecza nas przez clickjackingiem w ramce. Autor postu napisał:
“Dzięki zastosowaniu powyższego nagłówka, unikamy zagnieżdżania naszej strony w ramkach, czyli ataków typu:”
Unikamy zagnieżdżania naszej strony w ramkach, ale nie unikniemy pokazanego ataku – jedyne co, to użytkownik zobaczy komunikat o osadzeniu strony w ramce, ale jak kliknie w link w komunikacie, złapie się na wyżsżą warstwę, jeśli jest (kommunikat w MSIE ogranicza się do pseudo-strony wyświetlanej wewnątrz iframe’a).
@Bartek: ale to o czym piszesz, to nie jest clickjacking. W najlepszym przypadku CSRF, ale w bardzo “dziwnej” wersji.
Chyba w wolnej chwili jakiś prosty przykład clickjackingu zrobię.
[…] obsługuje ten nagłówek. Dziś na krótko wrócę do tego tematu, a to z uwagi na wpis X-Frame-Options: zacznij stosować oraz komentarz(e) Bartka. Mam wrażenie, że clickjacking oraz CSRF trochę się ze sobą […]
@Bartek: No właśnie, użytkownik złapie się na wyższą warstwę, którą już nie będzie nasza strona, tylko info, że zagnieżdżenie zostało zablokowane. Obrazowo: spójrz na obrazek wyżej (w artykule) – Twitter zostaje zastąpiony stroną z informacją, że strona nie może zostać osadzona w ramce. Natomiast ta druga strona (widoczna) z napisem “Play!” pozostaje nienaruszona. Tym razem kliknięcie na “Play” nie pozwoli atakującemu uzyskać zamierzonego efektu. Tak więc udało się zapobiec “clickjackingowi” :)
@Paweł: powiem krótko i z pokorą – dzięki za pouczający przykład :)
[…] innej domeny (o ile domena ta pozwala na “ramkowanie”, czyli nie ma ustawionego nagłówka X-Frame-Options zabezpieczającego przed […]
KIS:
if(top!=self) {
top.location.replace(location.href);
}
[…] Przeglądamy internet, i trafimy na stronę, która nakłoni nas do kliknięcia w jakiś link zarówno świadomie (fałszywie opisując link jako coś, co faktycznie nas interesuje i co chcemy zobaczyć), jak i nieświadomie, np. korzytając z ataku Click-Jackingu […]
[…] na osoby zalogowane do konta Google. Primaaprilisowa strona wymagała bowiem usunięcia nagłówka X-Frame-Options z oryginalnej strony Gogole, aby można było ją zaprezentować pod domeną […]