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

Komentáře

  1. Dodám, že httponly je spíš jistota, než něco bezpodmínečně nutného. Především, útočník nemusí krást session id, když to, co chce, může přes XSS provést krásně pomocí XMLHttpRequest. Ale v některých případech může útok znesnadnit.

  2. Koukám, že manželský svazek Tvému psaní svědčí. Jen tak dál ;)

  3. Jen doplním, že prohlížeč Safari má podporu httpOnly od verze 4.
    Google Chrome zřejmě od své první verze.

  4. Moc dík za praktický seriál s velmi užitečnými informacemi!
    Věřím, že času je málo, ale pokud se podaří dopsat zbývající dva články, budu (a jistě nejen já) vděčný.
    Ještě jednou děkuji a přeji hodně elánu do další práce ;o)
    Dady