HTTP cookie

HTTP Cookie (tłumaczone czasem jako plik cookie, w skrócie cookie, również ciasteczko) – mały fragment tekstu, który serwis internetowy wysyła do przeglądarki i który przeglądarka wysyła z powrotem przy następnych wejściach na witrynę. Używane jest głównie do utrzymywania sesji np. poprzez wygenerowanie i odesłanie tymczasowego identyfikatora po logowaniu. Może być jednak wykorzystywane szerzej poprzez zapamiętanie dowolnych danych, które można zakodować jako ciąg znaków. Dzięki temu użytkownik nie musi wpisywać tych samych informacji za każdym razem, gdy powróci na tę stronę lub przejdzie z jednej strony na inną.

Zabezpieczenia przeglądarek pozwalają na odczyt cookie jedynie z domeny, na której zostały utworzone, lub domen niższego poziomu. Czyli cookie ustawione na witrynie w domenie „wikipedia.org” nie zostanie wysłane do „przykład.org”, ale może zostać wysłane do „pl.wikipedia.org”. Witryna ustawiająca cookie może dodatkowo określić opcje cookie, m.in. kiedy ono wygaśnie (np. po zamknięciu przeglądarki lub o określonej godzinie, określonego dnia), czy jest dostępne tylko poprzez zabezpieczony protokół (HTTPS) oraz czy ma być dostępne dla skryptów uruchamianych w przeglądarce (typowo JavaScript).

Mechanizm cookie został wymyślony przez byłego pracownika Netscape Communications – Lou Montulliego, a ustandaryzowany w ramach RFC 2109 ↓ we współpracy z Davidem M. Kristolem w 1997 roku. Bieżący standard opisuje dokument RFC 6265 ↓ z 2011 roku.

Zastosowanie

Cookie różnych rodzajów są stosowane najczęściej po logowaniu do utrzymywania sesji. Mogą jednak przechowywać inne tymczasowe dane jak stan elementów na stronie, czy historię odwiedzanych poprzednio stron (na danej witrynie). Umożliwia to tworzenie spersonalizowanych serwisów WWW (np. zapamiętanie stanu menu), obsługi logowania, prostych sond i liczników, „koszyków zakupowych” w internetowych sklepach, a także tworzenie statystyk użyteczności witryny oraz badanie preferencji użytkowników.

Zastosowanie cookies do sond i liczników internetowych może wyglądać następująco – serwer ustawia ciasteczko informujące, że z danego komputera oddano już głos lub też odwiedzono daną stronę. Na tej podstawie może wykonać odpowiednie operacje i wygenerować dla użytkownika zindywidualizowaną treść strony. Schematyczny sposób wykorzystywania ciasteczek przy obsłudze licznika internetowego, wykluczającego przeładowania (zwiększanie liczby odwiedzin przy odświeżeniu strony) przedstawiony jest poniżej:

Schemat działania prostego licznika internetowego

Problemy w stosowaniu

Istotne przy stosowaniu cookie jest to, że są to dane tymczasowe – wygasają automatycznie po pewnym czasie i w każdej chwili mogą być usunięte lub zablokowane przez użytkownika. Z tego powodu trwałe dane użytkowników muszą być przechowywane po stronie serwera. Także stosowanie ciasteczka jako „zabezpieczenie” sond i liczników należy traktować jako działanie pomocnicze – wynik takiego licznika może łatwo, nawet nieświadomie, zafałszować użytkownik, który ma trwale zablokowane ciasteczka.

Dodatkowym problemem jest to, że tak naprawdę rozpoznawana jest przeglądarka internetowa, a nie konkretny użytkownik. Z tego z kolei wynikają dwa problemy:

1. Dane zawarte w ciasteczkach nie są przenoszone między urządzeniami użytkownika.
2. Istnieje ryzyko przejęcia danych na współdzielonym komputerze (np. w wypadku logowania się w kawiarence internetowej).

Pierwszy problem można rozwiązać zapisując kopię preferencji po stronie serwera – po zalogowaniu na innym urządzeniu dane są wysyłane ponownie i ew. łączone (synchronizacja). Drugi problem częściowo rozwiązuje mechanizm wygasania ciasteczek (domyślnie po zamknięciu przeglądarki). Dodatkowo można wprowadzić wygasanie identyfikatora sesji po stronie serwera. Użytkownik może także wyczyścić wszystkie dane w przeglądarce (w paru przeglądarkach skrótem do tej opcji jest Ctrl+⇧ Shift+Delete).

Innym ważnym problemem związanym z bezpieczeństwem jest to, że ciasteczka nie są domyślnie szyfrowane i są za każdym razem wysyłane do serwera. Z tego powodu ciasteczka nie nadają się do bezpośredniego przesyłania danych poufnych (np. hasła). Nawet w formie zaszyfrowanej jest to ryzykowne ze względu na wielokrotne przesyłanie tej samej informacji. Stąd też typowym rozwiązaniem jest wysyłanie tymczasowego identyfikatora sesji (ważnego tylko przez określony czas). Sesję można dodatkowo zabezpieczyć, przypisując identyfikator np. do konkretnego IP, które użytkownik miał w trakcie logowania lub np. grupy IP, które użytkownik określi jako bezpieczne.

Dyrektywa UE – obowiązek informacyjny

Mechanizmy zarządzania cookies w niektórych przeglądarkach są dosyć ubogie. Część przeglądarek posiada zaawansowane narzędzia, które pozwalają kontrolować, które witryny mogą przechowywać dane w ciasteczkach i pozwalają selektywnie je usuwać lub blokować. Niektóre pozwalają nawet na włączenie opcji ostrzegającej każdorazowo o ich przesyłaniu.

Także z tych powodów w 2009 roku Unia Europejska nałożyła na właścicieli witryn obowiązek informowania o tego typu praktykach (w Polsce efektywnie regulacje weszły w życie 22 marca 2013 roku, czyli dwa lata po terminie wyznaczonym przez UE). Należy pamiętać, że ciasteczka nie są jedynym możliwym mechanizmem cichego obserwowania użytkowników i nie są to tylko dane przechowywane po stronie użytkownika – w bardzo podobny sposób można wykorzystywać informacje gromadzone po stronie serwera. Wbrew czasem używanej nazwie (ang. EU cookie law) dyrektywa unijna dotyczy wszystkich mechanizmów używanych do gromadzenia danych o użytkownikach, a nie tylko cookies. Z tego powodu prawnicy określają ją jako dyrektywę o prywatności (ang. E-privacy directive)

W związku z europejskimi wytycznymi w 2013 roku znowelizowana została ustawa Prawo Telekomunikacyjne, która swoim art. 173 nakłada obowiązek informowania o przechowywaniu i wykorzystywaniu ciasteczek. Za nieprzestrzeganie tych zasad grozi kara finansowa, która może być nałożona przez prezesa Urzędu Komunikacji Elektronicznej. Polska implementacja dyrektywy różni się od niektórych modeli zagranicznych brakiem wymogu wyraźnego wyrażenia zgody i akceptacji polityki cookies przez użytkownika końcowego. Ustawa pozostawia pole do braku takiej zgody poprzez zmianę ustawień przeglądarki. W praktyce więc stosowane na polskich stronach ostrzeżenia o ciasteczkach pełnią charakter wyłącznie informacyjny.

Sposób działania

Mechanizm cookie został wprowadzony po to, by w bezstanowym protokole HTTP umożliwić odróżnienie osób odwiedzających dany serwis. Cookies są informacjami zapisywanymi tymczasowo na żądanie serwera lub skryptu po stronie przeglądarki użytkownika. Sam sposób zapisu danych nie jest sformalizowany i – wbrew popularnej nazwie „plik cookie” – pojedyncze ciasteczko nie jest zapisywane w jednym pliku na dysku. Dla przykładu Internet Explorer przechowuje wszystkie ciasteczka z danej witryny w jednym pliku, ale już Firefox i Chrome przechowują ją w bazie danych SQLite.

Standaryzowany jest jednak sposób przesyłania ciasteczek. Serwer WWW chcąc wysłać żądanie utworzenia ciasteczka na dysku użytkownika dołącza do nagłówka HTTP polecenie „Set-Cookie”, po którym następuje ciąg przekazywanych danych i opcji. Zapamiętane ciasteczko jest wysyłane jedynie do serwera z którego pochodzi, a który jest rozpoznawany przez przeglądarkę według nazwy domeny.

W danych po poleceniu Set-Cookie określone są:

• nazwa i przypisana jej wartość (jedyne obowiązkowe),
• czas ważności danego ciasteczka (po jego upłynięciu przeglądarka przestanie je wysyłać i powinna je usunąć z komputera użytkownika),
• opcje ograniczenia widoczności ciasteczka (domena, ścieżka i poziom zabezpieczeń).

Do zapisania cookie wymagana jest jedynie jego nazwa i wartość. Niepodanie czasu ważności spowoduje wygaśnięcie ciasteczka po zamknięciu „sesji” (czyli zamknięciu przeglądarki). Ciasteczka, które wygasają po zakończonej sesji, zwane są ciasteczkami sesyjnymi. Pozostałe są „trwałe” w tym sensie, że po ponownym uruchomieniu przeglądarki są dalej dostępne. Nie ma jednak możliwości by ciasteczko nie wygasło nigdy – albo wygasają z sesją, albo wraz z przekroczeniem podanego czasu. Czas ważności może być jednak bardzo odległy – nawet kilkuletni. Ciasteczka nie są też w pełni trwałe dlatego, że użytkownik może je łatwo usunąć.

Składnia nagłówka HTTP

Nagłówek wysłany przez serwer ma następującą postać:

Set-Cookie: nazwa=wartość; expires=DATA; path=ŚCIEŻKA; domain=DOMENA; secure

nazwa=wartość

Wartość ta jest jedynym wymaganym atrybutem przy wysyłaniu ciasteczka. Składa się z dowolnych znaków z wyjątkiem średników, przecinków, białych spacji i slashów (/). Jeśli zajdzie potrzeba ich użycia, najczęściej koduje się je w formacie odpowiednim dla URL (%XX), gdzie XX to kod ASCII znaku (np. %2F to zakodowana postać slasha, a %20 – spacji).

expires=data

Atrybut expires informuje przeglądarkę o dacie wygaśnięcia danego ciasteczka. Gdy data ważności zostanie przekroczona, to przeglądarka nie może wysłać ciasteczka do serwera i powinna je usunąć.

Jeśli nie podano daty wygaśnięcia, to ciasteczko traci ważność z końcem sesji, czyli po zamknięciu wszystkich okien przeglądarki.

Jeśli data jest określona, to musi być podana w następującym formacie (przykład): „Tuesday, 05-Nov-2004 08:30:09 GMT”. Format ten oparty jest na RFC 822 ↓, RFC 850 ↓, RFC 1036 ↓, i RFC 1123 ↓ z drobną zmianą odnośnie do separatora daty – tu występuje kreska, podana jest również strefa czasowa GMT.

domain=domena

Ten parametr określa widoczność ciasteczka, to znaczy, dokąd może być ono wysłane, przy czym serwer może określić tylko swoją domenę lub domeny niższego stopnia. W momencie wywołania przez użytkownika adresu URL, przeglądarka sprawdza, czy ma ważne ciasteczka dla tej domeny (i pozostałe opcje ograniczenia widoczności).

W specyfikacji Netscape’a wprowadzone jest w tym zakresie dodatkowe ograniczenie. To znaczy domena zostanie dopasowana, jeśli zawiera minimum dwie kropki, albo minimum trzy – jeśli domena główna serwera nie jest jedną z domen specjalnych, czyli: „COM”, „EDU”, „NET”, „ORG”, „GOV”, „MIL”, „INT”. Ma to zapobiegać ustawianiu ciasteczek dla domen typu „.com”, „.edu”, czy „va.us”. Może to jednak powodować nieoczekiwane rezultaty, ponieważ ustawienie dla ciasteczka domeny w formacie „domena.org” spowoduje, że ciasteczka będę widoczne tylko dla danej domeny, ale nie będą wysyłane do domen niższego rzędu, czyli np. „forum.domena.org”. Problem ten omija się ustawiając domenę „.domena.org”.

Domyślnie domain przyjmuje wartość domeny strony, z której wysłano żądanie zapisu ciasteczka.

path=ścieżka

Atrybut path jest podawany w celu ograniczenia widoczności ciasteczka do danej ścieżki dostępu do katalogu (liczy się ścieżka widoczna w URL-u pliku, a nie rzeczywiste położenie na dysku serwera). Wszystkie strony umieszczone w tym katalogu i jego podkatalogach będą mogły je wykorzystać. Należy zauważyć, że podanie parametru path w postaci „/wiki” pozwoli na odczytanie danych z ciasteczek plikom w katalogach „/wikipedia”, „/wiki/Cookie” itp.

Widoczność ciasteczka będzie niezależna od położenia pliku, jeśli podana została ścieżka „/”. Natomiast domyślnie path przyjmuje wartość ścieżki do strony, z której wysłano żądanie zapisu ciasteczka.

secure

Ten parametr nie posiada wartości. Jeśli zostanie podany, to ciasteczko będzie widoczne (wysłane) tylko wtedy, gdy połączenie będzie szyfrowane (obecnie możliwe przy użyciu protokołu HTTPS).

Przed każdym wywołaniem żądania HTTP do serwera, przeglądarka szuka ciasteczek, które jeszcze nie wygasły. Z tych ciasteczek wybierane są te, dla których domena, ścieżka i poziom zabezpieczenia zgadzają się z adresem URL strony. Jeśli coś zostanie znalezione, to nazwa i wartość (bez opcji) dołączane są do nagłówka żądania HTTP w postaci:

Cookie: nazwa_ciasteczka_1=wartosc_ciasteczka_1; nazwa_ciasteczka_2=wartosc_ciasteczka_2;...

Właściwości

• Cookie o tej samej nazwie, ale o innych ścieżkach będą nadpisywane (zarówno w sensie wartości, jak i opcji).
• W celu skasowania należy wysłać ciasteczko o takiej samej nazwie i czasie wygaśnięcia z minioną datą.
• Możliwe jest wysyłanie kilku ciasteczek w jednym nagłówku (poprzez kilka poleceń Set-Cookie).
• Istnieją limity przy zapisywaniu ciasteczek na dysku (po ich przekroczeniu przeglądarka usuwa starsze ciasteczka).
  • maksymalna liczba ciasteczek: 300.
  • maksymalna wielkość ciasteczka: 4 kilobajty.
  • maksymalna liczba ciasteczek z jednego serwera lub z jednej ścieżki: 20.
• Gdy jest zainstalowany serwer Proxy, nagłówki Set-Cookie nie powinny być przechowywane w pamięci proxy.
• Jeżeli serwer Proxy dostanie odpowiedź z nagłówkiem zawierającym Set-Cookie, powinien go przekazać do klienta bez względu na rodzaj odpowiedzi np. 304 (nagłówek niezmieniony) czy 200 (nagłówek inny niż zapisany w cache’u).

Szczegóły działania tego mechanizmu zależą też od konfiguracji przeglądarki. Niektóre z nich umożliwiają odmowę zapisu, inne pozwalają na ustawienie daty wygaśnięcia innej od tej deklarowanej w nagłówku HTTP. Zaawansowaną kontrolę nad zachowaniem ciasteczek posiadają m.in. Firefox i Opera.

Alternatywy dla cookie

Dane w adresie URL lub formularzu

Gdy użytkownik ma wyłączoną obsługę cookies, wówczas dane należy przesłać w inny sposób. W ramach protokołu HTTP jest to możliwe przy użyciu metody GET bądź POST.

Zastosowanie metody GET wiąże się jednak z koniecznością podania danych w adresie URL. Jest to jednak zadaniem kłopotliwym i niebezpiecznym, ponieważ sprowadza się do konieczności dodawania odpowiednich parametrów do wszystkich wewnętrznych linków zawartych na stronach serwisu. Jest to problematyczne ze względu na potencjalną ilość takich danych, a niebezpieczne ze względu na to, że użytkownik może np. chcieć zachować taką stronę i nie będąc świadomy zawartych w niej poufnych danych, wysłać komuś mailem. Z tego powodu bardziej obszerne, bądź poufne dane praktyczniej przekazuje się poprzez zmienne w POST, które nie są bezpośrednio widoczne dla użytkownika, a zatem nie zaśmiecają adresu. Dane stricte adresowe pozwalające na powrót do tej samej strony powinny pozostać w adresie przekazane przez GET, lub bezpośrednio stać się częścią adresu np. poprzez wykorzystanie metod nadpisywania (mod_rewrite). Informacje przekazywane poprzez POST również można podsłuchać.

Ani GET, ani POST, ani cookies nie są zalecane do przechowywania informacji poufnych, np. takich jak hasło czy dane osobowe. Takie informacje powinny być przesyłane jednorazowo i pozostać umieszczone po stronie serwera, klientowi pozostawiając tylko identyfikator („token”) sesji przypisany do danych na serwerze.

Dane pozostające na urządzeniu użytkownika

Cookie są przesyłane za każdym razem, co zwiększa zarówno ryzyko przechwycenia tych informacji, jak i zwiększa ilość przesyłanych danych. Nie ma też możliwości ustawienia wartości ciasteczka bez ponownego podania pozostałych opcji (czyli wygasania itp). Z powodu tych ograniczeń wprowadzone zostały inne rozwiązania, które umożliwiają przechowywanie danych po stronie użytkownika i działają wyłącznie po jego stronie (nie są przesyłane do serwera). To umożliwia zarówno tworzenie aplikacji przeglądarkowych niemających w ogóle kontaktu z serwerem, jak i takich, które serwer wykorzystują do przechowywania części danych lub do synchronizacji danych między urządzeniami użytkownika.

Wśród takich rozwiązań można wymienić:

• Web storage – standard W3C dający skryptom JavaScript proste odpowiedniki ciasteczek sesyjnych (sessionStorage), jak i „trwałych” (localStorage). Przy czym – w przeciwieństwie do „trwałych” ciasteczek – dane w „localStorage” nie wygasają automatycznie.
• Web SQL Database – standard W3C, obecnie porzucony, dający bardziej zaawansowane możliwości bardziej typowe dla relacyjnych baz danych (oparty na SQLite).
• Indexed Database API – nowszy standard W3C dla zaawansowanych baz danych budowanych w JavaScript.
• Local shared object – stworzone przez Adobe i zwane także „ciasteczkami Flash” (ang. „Flash cookies”), ponieważ używane są przez Adobe Flash.

Blokowanie cookie

Wszystkie nowoczesne przeglądarki pozwalają na włączenie bądź wyłączenie mechanizmu cookies (domyślnie zazwyczaj jest on włączony).

Linki zewnętrzne

• Jakub Kralka, Czy ostrzeżenia o cookies są konieczne? (dostęp: 2014-02-12)
• D.D. Crocker D.D., STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES, STD 11, RFC 822, IETF, sierpień 1982, DOI: 10.17487/RFC0822, ISSN 2070-1721, OCLC 943595667  (ang.).
• M.R.M.R. Horton M.R.M.R., Standard for interchange of USENET messages, RFC 850, IETF, czerwiec 1983, DOI: 10.17487/RFC0850, ISSN 2070-1721, OCLC 943595667  (ang.).
• M.R.M.R. Horton M.R.M.R., R.R. Adams R.R., Standard for interchange of USENET messages, RFC 1036, IETF, grudzień 1987, DOI: 10.17487/RFC1036, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Braden R.R., Requirements for Internet Hosts - Application and Support, STD 3, RFC 1123, IETF, październik 1989, DOI: 10.17487/RFC1123, ISSN 2070-1721, OCLC 943595667  (ang.).