Bezpieczne ciasteczka – 5 rzeczy, o których warto pamiętać

Co to są ciasteczka (z ang. Cookies)? Zostały one wymyślone, żeby dołożyć mechanizm ciągłości w naszym bezstanowym protokole HTTP. Są to informacje, które serwer może wysłać do naszej przeglądarki. Przeważnie zawierają one konfigurację aplikacji oraz / lub dane identyfikujące użytkownika (jego identyfikator sesji tzw. Token sesyjny). Ich zawartość może być bardzo interesująca z punktu widzenia osoby atakującej, więc warto zadbać o to, żeby nasze ciasteczka były bezpieczne. Istnieje wiele mechanizmów do poprawienia ich bezpieczeństwa. Zacznijmy więc od podstaw.

Co my tam wysyłamy?

Warto zastanowić się, co przesyłamy w ciasteczkach i czy na pewno chcemy to przesyłać. Przez używanie ciasteczek możemy wpłynąć na wydajności naszej aplikacji (m.in. nie przesyłając non stop dużych Requestow z konfiguracją). Trzeba jednak pamiętać, że te dane są zapisywane po stronie klienta, a to może znacząco wpływać na ich bezpieczeństwo. Na szczęście, ciasteczka mają atrybuty, tzw. Flagi, które mogą to bezpieczeństwo poprawić.

Ciastko sesyjne czy takie na stałe?

Kiedy już określimy, jakie dane chcemy przesyłać w naszych ciasteczkach, warto zastanowić się jak długo poszczególne ciasteczka powinny być ważne. Co innego, gdy ciasteczko sesyjne jest wykorzystywane w aplikacji bankowej, a co innego, gdy użyjemy go np. dla Facebook’a. W przypadku tego drugiego wkurzałoby nas, gdyby sesja wygasała co 10 min, z kolei gdybyśmy w aplikacji bankowej byli zalogowani non stop, nawet po odejściu od komputera to na pewno nie czulibyśmy się bezpieczni… Mamy takie atrybuty jak “expires” i “max-age”. Poprzez ustawienie obu z nich, nasze ciasteczko staje się ciasteczkiem „persistent”. To znaczy, że będzie tak długo ważne jak jego data w expires albo “wiek” w max-age, oczywiście jeśli data jest ustawiona w przyszłości. Co ważniejsze to takie ciasteczko “przeżyje” restart przeglądarki. Jeżeli obydwa te atrybuty są pominięte, to ciasteczko staje się ciasteczkiem sesyjnym (session cookie lub non-persistent cookie) i będzie ważne aż do zamknięcia przeglądarki. Warto więc zapamiętać, że im ważniejsze dane przesyłamy w ciasteczkach tym mniejszy powinien być okres ich istnienia 🙂 tzn., sesje powinny wygasać, a ustawienia kolorków w aplikacji mogą zostać na zawsze.

Secure – czyli bezpieczne przesyłanie

Zawsze istnieje możliwość podsłuchania niezabezpieczonego połączenia przez atakującego. Jeżeli więc tym kanałem przesyłane jest nasze ciasteczko, to atakujący może je przeczytać lub nawet, o zgrozo, zmienić. Żeby temu zapobiec musimy wysyłać nasze ciasteczka używając bezpiecznego połączenia. Ustawienie flagi “secure” powie przeglądarce, żeby nigdy nie dodawać ciasteczka do requestu wysyłanego do serwera poprzez nieszyfrowane połączenie. Takie ciasteczko będzie wysyłane tylko przy pomocy HTTPS (HTTP over Transport Layer Security (TLS)). Niestety, nie mamy wpływu na to, co przeglądarka uzna za zabezpieczony kanał, stąd też ciasteczka mogą być wysyłane w połączeniu zabezpieczonym certyfikatem self-signed albo takim, który wygasł (expired).

HTTPOnly – No way JavaScript

Domyślnie zawartość ciasteczka może być odczytywana przez JavaScript. Flaga HTTPOnly nie pozwala skryptom na czytanie ciasteczek. Nazwa tej flagi wskazuje na używanie ciasteczek tylko w Requestach HTTP/S i nigdzie indziej. Dzięki tej fladze nasze ciasteczka nie będą mogły być odczytane, gdy ktoś znajdzie na naszej stronie podatność XSS (Cross Site Scripting).

SameSite – z innej strony wstęp wzbroniony

Celem tej flagi jest zabezpieczenie ciasteczka (również całej aplikacji) przed atakami typu CSRF – Cross Site Request Forgery. Jeżeli serwer ustawi flagę SameSite jako strict, to przeglądarka nie prześle ciasteczka jeśli Request pochodzi z innej domeny. Dla przykładu, aplikacja bankowa nie może pozwolić na wykonanie przelewu poprzez kliknięcie w jakiś link na innej domenie niż domena banku. Flaga SameSite może przyjmować wartość “lax” i przez to staje się bardziej “pobłażliwa” w stosunku do Requestów z innych domen tzn. blokuje ciasteczka przed użyciem w “niebezpiecznych” metodach HTTP jak np. POST. Przed użyciem tej flagi w naszej aplikacji warto sprawdzić, które przeglądarki i w jakich wersjach ją wspierają np. tu: https://caniuse.com/#search=samesite.

Host Only

Flaga ta mówi o tym, czy ciasteczko ma być dostępne z innych subdomen naszej aplikacji czy nie. Przeglądarka ustawia tą flagę wtedy, gdy widzi, że w parametr domain jest pusty. Przykładowo, jeżeli nasza domena example.com ustawia ciasteczko bez podania parametru “domain” to wtedy flaga HostOnly zostaje ustawiona. Teraz dostęp do tego ciasteczka będą miały tylko strony z dokładnie tą samą nazwą co główna domena (w naszym przykładzie example.com). Z kolei, jeżeli ustawimy ciasteczko i określimy mu parametr domain=example.com, to to ciasteczko przestaje być HostOnly i wszystkie subdomeny example.com (np. admin.example.com, settings.example.com itd.) będą miały do niego dostęp. Warto więc zostawić parametr Domain pusty, chyba że chcemy dzielić nasze ciasteczko ze wszystkimi subdomenami i dodatkowo mamy do nich zaufanie.

Gdzie są moje ciasteczka?

Najprostszym sposobem na sprawdzenie jakie ciasteczka i jakie flagi są na nich ustawione, jest uruchomienie Dev Tools na stronie badanej aplikacji a następnie przejście do zakładki Application. Po prawej mamy drzewko Storage, a w nim sekcję Cookie. Po kliknięciu na konkretną stronę widzimy listę ciasteczek oraz ich atrybuty.

Jeżeli chcemy jeszcze szybciej docierać do ciasteczek a dodatkowo w łatwy sposób manipulować ich parametrami to polecam dodatek do Chrome: Cookie Editor (https://chrome.google.com/webstore/detail/cookie-editor/hdhngoamekjhmnpenphenpaiindoinpo?hl=en)

Ciasteczka – rozmowa rekrutacyjna.

Pytań, z jakimi możecie się spotkać odnośnie ciasteczek, jest wiele. Od takich najprostszych jak:

• Co to są ciasteczka i do czego służą?
• Jakie znasz flagi ciasteczek?

Aż do bardziej zaawansowanych:

• Co daje parametr „lax” w przypadku flagi SameSite?

Warto zapamiętać

– Nie trzymajmy w ciasteczkach wrażliwych danych, jeśli nie musimy.

– Używajmy ciasteczek sesyjnych lub jeśli nie możemy to określajmy ich date końca.

– Ustawmy flagę HTTPOnly i Secure

– Tam, gdzie to możliwe używajmy też SameSite

Wszystkie te rekomendacje oczywiście są zależne od wymagań aplikacji. Robiąc pentesty zgłaszajmy braki w ciasteczkach, ale miejmy na uwadze to jak działa aplikacja.

P.S.

Mam nadzieję, że takie zestawienie się przyda. W tym artykule użyłem słowa „ciasteczko”w różnych odmianach 44 razy. edit: 47 razy (fraza: ciastecz) i 6 razy cookie. Dzięki Barłomiej Kaliński za podpowiedź!