Vývoj obrany proti Session Hijackingu
Školení, která pořádám 
O útoku Session Hijacking mluvíme, pokud se útočníkovi podaří získat session identifikátor a díky tomu se začít vydávat za svou oběť. Jak vypadá současnost a blízká budoucnost obrany proti tomuto útoku?
V minulosti některé webové aplikace přenášely session identifikátor v URL. Tam je velmi snadno dostupný – v hlavičce Referer se posílá na ostatní servery, ukládá se do logů, je přístupný z JavaScriptu a tak dále. Většina aplikací proto session identifikátor posílá v cookie. V PHP to zajistí nastavení session.use_cookies.
V cookie byl session identifikátor v minulosti také snadno dostupný, ale díky HttpOnly cookies ho můžeme snadno znepřístupnit z JavaScriptu. Pomocí secure cookies můžeme prohlížeč navíc instruovat, aby cookie nepřenášel na nezabezpečeném připojení. V PHP jsou tyto volby dostupné pomocí session.cookie_httponly a session.cookie_secure.
O ochranu session identifikátorů se musíme postarat také na serveru. PHP ve výchozím nastavení bohužel ukládá session data do souborů pojmenovaných podle session identifikátoru. Útočníkovi tedy stačí získat seznam souborů v daném adresáři a rázem má přístup k sezením všech přihlášených uživatelů. Ve své knize ukazuji, jak session data ukládat do souborů pojmenovaných podle hashe session identifikátoru. Je to celkem snadné, stačí implementovat jednoduchý handler a zavolat funkci session_set_save_handler.
Blízká budoucnost
Takhle vypadá současnost obrany proti Session Hijacking. Jak vypadá budoucnost? Prohlížeč Google Chrome testuje možnost podepisování cookies. Předpokladem této obrany je, že každá instalace prohlížeče obsahuje unikátní identifikátor (říká se mu Channel ID). Prohlížeč potom při posílání cookie pošle taky podpis potvrzující, že pochází skutečně z něj. Pokud se útočníkovi podaří session identifikátor získat, tak je mu to k ničemu, protože z jeho prohlížeče se pošle jiný podpis (nebo se nepošle žádný). Pokud útočník získá i původní podpis, tak je mu to taky k ničemu, protože ve zprávě je proměnlivá část, takže i podpis se musí při dalších požadavcích lišit.
Podepisování cookies zatím nepodporuje žádný prohlížeč ani server. Google Chrome jeho podporu testuje, Mozilla Firefox ho nejspíš také zařadí, ostatní prohlížeče se snad časem přidají. Z webových serverů jsou připraveny zatím jen proprietární servery Googlu. Ale celý projekt je otevřený, takže globálnímu rozšíření snad nebude nic bránit.
Přijďte si o tomto tématu popovídat na školení Bezpečnost PHP aplikací.
Diskuse
Franta:
Ad „ukládat do souborů pojmenovaných podle hashe session identifikátoru. Je to celkem snadné, stačí implementovat jednoduchý handler a zavolat funkci“
Kdy se stane, že by útočník měl k dispozici výpis souborů a ne jejich obsah? I když takhle práva k souborům nastavená být můžou, musel by útočník být jiný uživatel než webový server. Není jednodušší na daný adresář udělat chmod 700? V čem jsou lepší změněné názvy souborů?
Jakub Vrána 
:
Obsah souboru (např. a:1:{s:5:"login";s:5:"vrana";}) je často bezcenný.
Jakub Vrána : Franta:
Když ale nemáš práva k souborům pod kontrolou, tak hrozí, že si tam útočník zapíše vlastní údaje (uživatelské jméno, administrátorská práva…) a v tom případě ani nemusí krást session – vytvoří si vlastní a zapíše si tam, co potřebuje. A ten uživatel ani nemusí být přihlášený jinde.
Jakub Vrána :
Útočník může mít práva čtení, ale nikoliv zápisu.
Na adresář se session soubory je lepší dát práva 300, ne? Tedy aby nikdo neměl právo přečíst seznam souborů. To se ale nijak nevylučuje se změnou názvů souborů, což je užitečné třeba v situaci, kdy se někdo dostane k záloze.
Spíš bych se na to podíval naopak – existuje nějaký důvod ukládat session data do souborů pojmenovaných podle session identifikátorů? Ne, jenom to zbytečně zvyšuje riziko, takže není jediný důvod to dělat.
Jakub Vrána : Michal Špaček:
Při právech 300 asi bude problém s externím async garbage collectorem, který seznam souborů potřebuje.
Michal Špaček:
Prosím všechny, kterých se to týká, aby si nastavili direktivu session.cookie_httponly. Teď hned. TEĎ. HNED. Případně si aspoň ověřte, že to tak máte nastaveno.
Díky tomuto nastavení bude o dost složitější session ukrást, šlo by to pak pomocí Cross-Site Tracingu (XST), ale to standardně většina prohlížečů blokuje a bylo by k tomu potřeba použít Javu nebo Flash.
Ukrást session administrátorovi na většině českých e-shopů je otázkou několika minut (maximálně hodin, většinu času ovšem jen čekáte, než se admin přihlásí), stačí vhodně provést útok Cross-Site Scripting (XSS). S admin session je pak možné ovládat celej e-shop jako administrátor, překvapivě.
A jen pro úplnost, session hijacking často používá XSS pro získání session id, ale s XSS jde dělat spousta dalších věcí a i session id lze získat jinak, třeba pro .NET aplikace je občas k nalezení v ELMAH logách: https://www.google.com/search?q=error+log+….axd+site:cz
(úplně ten komentář nesouvisí s vývojem obrany jako spíš se samotných session hijackingem, ale tak snad mi prominete)
Aichi:
Rad bych zminil CSP hlavicku a jeji moznost nabonzovat XXS utok, kterym se da ziskat cookie. https://developer.mozilla.org/en-US/docs/…_violation_reports
Aichi: Diskuse je zrušena z důvodu spamu.
© 2005-2024 