Přeskočit na hlavní obsah

Předávání SID pomocí cookies

Jak jsem ukázal v článku Session ID do URL nepatří, základním pravidlem je uchovávat a předávat si session ID výhradně s pomocí cookies. Dneska bych rád zmínil některá důležitá nastavení, která s tím souvisí.

Chceme jenom koláčky

Nejprve bych rád shrnul všechny základní konfigurační direktivy, které je vhodné v tomto ohledu nastavit nebo alespoň pohlídat. Optimální nastavení je následující:

session.use_cookies = 1
session.cookie_lifetime = 0
session.use_trans_sid = 0
url_rewriter.tags = ''
session.use_only_cookies = 1
session.cookie_httponly = 1

Jejich význam je následující:

  • Direktiva session.use_cookies zapíná ukládání SID do cookies. Defaultně je zapnutá a za normálních okolností není prakticky žádný důvod ji vypínat.
  • Stejně tak session.cookie_lifetime by měla zůstat na své výchozí nulové hodnotě. Určuje, že pro uchování SID se má v prohlížeči použít relační cookie, jejíž platnost končí se zavřením prohlížeče.
  • Smysl dalších dvou, tedy session.use_trans_sid a url_rewriter.tags, jsem podrobněji popsal už v předchozím článku.
  • Nastavení session.use_only_cookies souvisí částečně s ochranou před zneužitím již ukradené SID a zejména s něčím, čemu se říká session fixation. O tom se podrobně rozepíšu příště a přespříště. Zatím tedy vezměte jenom jako prostý fakt, že je dobré to mít zapnuté.
  • Jako poslední zůstává direktiva session.cookie_httponly. Pojďme na ni.

Chráníme cookies pomocí HTTPOnly

Ukládání session ID do cookies je výrazně bezpečnější než posílání v rámci URL. Ale i tak samozřejmě existují možnosti, jak se ho zmocnit.

Jednou z nich je využití XSS zranitelnosti, kdy útočník do zdrojivého kódu stránky propašuje vlastní skript. Ten se totiž spouští v kontextu naší stránky. Má tedy plný přístup i ke všem uloženým cookies. Pro skript není nic jednoduššího, než si z nich SID přečíst a poslat útočníkovi.

Proto už před sedmi lety přišel Internet Explorer s nestandardním rozšířením specifikace cookies o vlastnost HTTPOnly. Cookie, u které je tato vlastnost nastavena, se sice normálně posílá mezi prohlížečem a serverem, ale není dostupná pomocí JavaScriptu. Což je přesně to, co po SID cookie požadujeme.

Dalším opatřením proto je pro SID cookie používat důsledně příznak HTTPOnly. Ten se dá v PHP od verze 5.2.0 nastavit pomocí direktivy session.cookie_httponly:

session.cookie_httponly = 1

Přímo ve skriptu pak lze místo analogického ini_set využít i speciální funkci session_set_cookie_params() a její pátý parametr:

session_set_cookie_params(0NULLNULLNULLTRUE);

Jenom na okraj, v PHP lze explicitně nastavit příznak HTTPOnly i pro jakoukoliv jinou zasílanou cookie. U funkce setcookie() k tomu slouží její sedmý parametr.

Nebezpečí starých prohlížečů

Celá věc má jeden drobný háček, který spočívá v podpoře příznaku HTTPOnly jednotlivými prohlížeči. Aktuální vydání všech hlavních prohlížečů už s HTTPOnly pracovat umí. Spousta starších verzí ale příznak nezná. To samozřejmě neznamená, že by v nich takto nastavené cookies vůbec nefungovaly. Příznak budou jednoduše ignorovat a s danými cookies budou nakládat jako s jakýmikoliv jinými.

MSIE implementoval podporu HTTPOnly ve verzi 6 SP1, Firefox ve své verzi 2.0.0.5, Opera dokonce až v 9.50. Prohlížeče ale zpočátku zapomněly na jeden způsob, jak se k požadovaným cookies z JavaScriptu stejně dostat. Jedná se o dotaz zaslaný pomocí Ajaxu, přesněji řečeno pomocí XmlHttpRequest. Touto cestou jde i v několika následujících verzích SID z cookies ukrást bez ohledu na to, jestli je HTTPOnly nastaveno či nikoliv.

Plně se spolehnout na zabezpečení pomocí příznaku se tak dá až od Firefoxu 3.1 a MSIE 8, kdy už bylo opomenutí opraveno. Uživatelé, kteří používají starší než tyto verze prohlížečů, jsou k XSS útoku na SID v cookies stále náchylní.

Tak jako tak, nejlepší ochranou je nemít ve svém webu vůbec žádnou díru, skrz kterou by do něj mohl útočník svůj skript vložit.

Nepřítel na hradbách

I když uděláte všechno bezchybně, ukradení session ID nemůžete už z principu nikdy stoprocentně vyloučit. Příště proto ukážu, jak lze aplikaci bránit v okamžiku, kdy se už útočník SID nějakým způsobem zmocnil.

Seriál o bezpečnosti sessions

  1. Nenechte si uhodnout Session ID
  2. Session hijacking aneb ukradení SID
  3. Sidejacking aneb nasloucháme v síti
  4. Session ID do URL nepatří
  5. Předávání SID pomocí cookies (právě čtete)
  6. Bráníme se zneužití ukradeného SID
  7. Session fixation aneb nenechte si podstrčit SID

Napište komentář

  • Jméno a e-mail jsou povinné. E-mail nebude zobrazen.
  • V textu komentáře můžete používat Texy!
  • Tykejme si.
  • Příležitostné mazání zhůvěřilých komentářů nevylučuji.