K zabezpečení session

Poznámka k doporučovanému způsobu zabezpečení session proti stealingu u webových aplikací.

Tu a onde čtu doporučené metody zabezpečení před session stealingem a jako mantra se v nich objevuje stále dokola rada "uložte si IP adresu klienta do session a kontrolujte". Doporučuju: Nedělejte to!

Já před pár lety nasadil na Bloguje podobnou ochranu session před "ukradením". Fungovala skvěle a byla opravdu účinná – až do doby, kdy se přihlásil uživatel, u něhož se zkombinovaly následující faktory:

1. Byl z USA
2. Byl připojen přes AOL
3. Byl dlouho přihlášený

 

A protože to byl člověk, který mne podezříval z Temných Machinací (jak neobvyklé), tak samosebou psal provozovateli, jak je možné, že mu systém pořád píše, že detekoval pokus o zneužití, když přitom nic špatného nedělá, a jestli by se tomuhle Dentovi nemělo sebrat adminské oprávnění či tak něco.

Naštěstí jsme se nakonec domluvili jako lidi a já zjistil fascinující (alespoň pro mne v té době) věc: AOL mění průběžně IP adresy. Nakonec – je to logické, při tom neskutečném počtu uživatelů je pochopitelné, že dělají nějaký "network balancing" (či kýho čerta), zkrátka že se IP adresa uživatelů mění, aniž by se odpojili a připojili. IP adresa se změnila třeba během tří minut.

Myslete na to, až budete implementovat ochranu proti session stealingu a budete koketovat s myšlenkou "vrznu tam (hash) IP"... Dokud se budete placatit po ČR a okolí, tak se pravděpodobně s žádnými potížemi nesetkáte, ale jakmile se otevřete světu, tak se může objevit uživatel, kterému se mění IP, aniž by se o to přičinil. Je dobré s tím počítat.

Tolik jsem jen chtěl říct.

Dne 14.09.2008

Twittni

Přidej do: asdf.sk StumbleUpon Toolbar Stumble It!

Komentáře

[1] (Tom ) 14.09.2008, 22:35:55 [X] [D]
Uzivatel ktery se spolcil s AOL je privrzencem Satanase a uziva jeho nastroj, detekce jako narusitele tedy funguje v poradku.

[2] (David ) 14.09.2008, 22:46:34 [X] [D]
A co tedy použít k identifikaci uživatele? Napadá mě leda tak user-agent, ale s tím to asi taky nebude žádná sláva...

[3] (paranoiq ) 14.09.2008, 23:24:52 [X] [D]
[0],[1] podobnou věc provádějí i někteří čeští ISP. už si nevzpomenu o koho šlo, ale jedenkrát už jsem se s proměnlivou ip adresou setkal i u nás.

[4] (matejcik [openID] - WWW) 14.09.2008, 23:46:21 [X] [D]
třeba na mobilech se ip adresa mění celkem běžně.

[5] (Kozo - Mail - WWW) 14.09.2008, 23:48:21 [X] [D]
Narazit sa na to da aj v nasich koncinach. Koniec koncov narazili sme na to aj v ere stareho dobreho POBOXu pred cca 5-7 rokmi. Uplne ten isty problem..... Akurat vela ludi kym si neskusia, tak neveria.

[6] (#13 - WWW) 14.09.2008, 23:48:21 [X] [D]
Arthure, konečně přiznej, že provádíš Temné Machinace nejen s počítadlem! :)

[7] (Pixy [openID] - Mail ) 14.09.2008, 23:50:07 [X] [D]
Proboha, existuje u AOL aspoň něco, co dělaj normálně?

[8] (Ondra Knezour - Mail ) 15.09.2008, 00:03:29 [X] [D]
Člověk ani nemusí být připojený přes AOL, aby mu to znepříjemnilo život. V práci vstanu, zavřu notebook, přesunu se o 1500 metrů domů, sednu si, otevřu notebook, pošta poští, předpověď počasí předpovídá, síť síťuje, jenom "zabezpečená" stránka remcá něco o krádeži identity.

[9] (David Grudl - WWW) 15.09.2008, 01:56:31 [X] [D]
Každý request s jinou IP adresou obstaral blahé paměti Google Web Accelerator.

[10] (David Grudl - WWW) 15.09.2008, 01:56:47 [X] [D]
Každý request s jinou IP adresou obstaral blahé paměti Google Web Accelerator.

[11] (Filip Jirsák - WWW) 15.09.2008, 09:30:18 [X] [D]
Úplně přesně vzato to není tak, že by AOL měnil IP adresu klienta (to klidně může taky, ale nesouvisí to s tím), ale klienti se dostanou na web přes proxy server. Ve skutečnosti je těch proxy serverů několik s různými IP adresami, takže pokud klienta jednou obslouží jeden proxy server a příště jiný, na webovém serveru to vypadá, jako by klient střídal IP adresy.

Stejně, jako se programátorům doporučuje (tedy asi až v druhém levelu) nespoléhat na to, že klientovi se během sezení nezmění IP adresa, doporučuje se správcům webových proxy serverů konfigurovat je tak, aby požadavky od jednoho klienta v rámci jednoho „sezení“ (což je na proxy ještě vágnější pojem, než na serveru) měly stejnou IP adresu. Ale v obou táborech (jak programátoři, tak administrátoři) se najde dost těch, kteří takové doporučení nerespektují.

[12] (Jiří Bureš - WWW) 15.09.2008, 10:19:05 [X] [D]
Se stejnou věcí jsem se potkal, když jsem zkoušel komentářový antispam. Testoval jsem IP adresu v době mezi začátkem psaní a odesláním komentáře. Fungovalo to hezky do doby, než mi napsal nazlobený člověk, co byl přihlášený via mobil (tuším od O2).

[13] ( - WWW) 15.09.2008, 10:59:02 [X] [D]
IMHO je tech uzivatelu malo. Hlavni je nezobrazovat pitomy hlasky o tom, ze uzivatel je hacker ;)

IP adresa je asi tak nejspolehlivejsi, co muzete pouzit. Drtivou vetsinu uzivatelu to neovlivni. Kolik z vas optimalizuje pro Konqueror?

[14] (Jakub Vrána [openID] - WWW) 15.09.2008, 11:05:08 [X] [D]
Internet Info na svých serverech tuším kontroluje céčkový rozsah adresy a pokud vím, tak to vážné komplikace nepřináší. Samozřejmě se pohybujeme převážně v českém rybníku a neřeší to ani případ [8].

[15] (Arthur Dent [openID] - Mail - WWW) 15.09.2008, 15:56:05 [X] [D]
[14] Ano, k podobnému řešení jsem přikročil nakonec i já.

[13] Nesouhlasím. S rozvojem mobilního internetu a podobných ošklivin se podobné problémy začnou objevovat čím dál častěji a IP adresa přestane být spolehlivá. A to jsem chtěl říct.

O hlášku nejde, důležité je, jak se zachovat, když zjistím, že ke stejné session přistupuje najednou někdo s diametrálně odlišnou IP adresou. Z pochopitelných důvodů je potřeba session zneplatnit a operaci nepovolit. A pak je jasné, že je třeba uživateli říct, proč byl odhlášen a proč se operace neprovedla.

[16] (Filip Jirsák - WWW) 15.09.2008, 16:50:19 [X] [D]
[15] Které jsou ty pochopitelné důvody? Mne napadá jediný – únik identifikátoru sezení do nepovolaných rukou. Ovšem slušná aplikace sama ten identifikátor nikam nepředává (ohlídá si, aby referrery šly bez tohoto identifikátoru). Předpokládám samozřejmě takový identifikátor, který se nedá snadno uhodnout. Takže zbývají varianty, že identifikátor unikl z počítače uživatele, nebo že jej odposlechl někdo na cestě. Ale pokud někdo dokáže identifikátor session získat z počítače uživatele nebo dokáže monitorovat jeho síťový provoz, dokáže posílat i požadavky s jeho IP adresou – a pokus o zneužití identifikátoru sezení z jiné IP adresy by byla hloupá chyba.

Takže před čím vlastně tahle kontrola IP adresy uživatele chrání?

[17] (Arthur Dent [openID] - Mail - WWW) 15.09.2008, 17:05:35 [X] [D]
[16] Pochopitelný důvod je ten, že objeví-li se mi přístup k session z IP adresy, která je diametrálně odlišná od té, co mám uloženou, tak je to přinejmenším podezřelé a ZAKÁZAT takovou operaci je míň rizikové než takovou operaci POVOLIT. To je ten důvod.

Je jedno jak se k session útočník dostal a co udělá, o tomhle řeč nejde. Pouze jsem podotknul, že jedním z mnoha doporučovaných způsobů obrany proti XSS, CSRF a podobným je kontrola IP, ale že má své úskalí. Účelem tohoto článku nebylo diskutovat možné způsoby útoku, ale podotknout jeden detail k jedné z doporučovaných technik. Viz perex: Poznámka k doporučovanému způsobu... Otázky JAK či CO nechme stranou. Šlo mi jen o to říct: Pokud kontrolujete IP, tak BACHA!

[18] (ehmo - WWW) 15.09.2008, 20:42:38 [X] [D]
Njn, ip adresa je uz dnes dost velky zadrhel. Problematicky je uplna kazdy ISP ktory pouziva proxy pre komunikaciu vonku a ma ich hned niekolko, ale aj rozne anonymizery, etc. Problem vsak nastane, ak nejak nedokazes priradit presny identifikator danej osobe. Ono sa to najlepsie skutocne robi tak, ze si vezmes len zaklad IP adresy, k tomu prilozis hash user agenta a budes dufat, ze utocnik nie je prilis inteligentny. V sekunde ako mas na webe XSS, tak je to uz jedno. Proti CSRF to ochrana zarucene nie je, ale moze pomoct, ale skor nie. Fajn pomoc pri ochrane session v php je httpOnline Cookie.

Nechcem tu opisovat dalsie veci, Martin by sa hneval :)

[19] (David Grudl - WWW) 15.09.2008, 21:30:18 [X] [D]
Zkoušel jsem i ověřovat hlavičky Accept-charset, Accept-encoding, Accept-language, User-agent, jejich změna by mohla svědčit o nekalém úmyslu. Ale je otázka, jak se to projeví v praxi, co s nimi mohou udělat proxy servery atd. Nepříjemné je, že o chybě se člověk jen těžko dozví. Takový rozhněvaný email od poškozeného uživatele má pak cenu zlata.

[20] (ehmo - WWW) 15.09.2008, 22:33:30 [X] [D]
[19] No hlavne je mozne detekovat ci sa nejedna o proxy, kedze AOL a podobne ISP posielaju v hlavicke ako napriklad X_FORWARDED_FOR, alebo ine. Tak je mozne upravovat spravanie aplikacie, aj ked to je uz asi prilis zlozite. No itak je to cesta

[21] (Peter ) 16.09.2008, 01:24:00 [X] [D]
[18] Ja by som Ti bol za ne vdacny. Verim, ze to u Martina prejde.

[22] (ehmo - WWW) 16.09.2008, 02:23:01 [X] [D]
[21] Martin by vdacny nebol, jasne to vyjadril v komentari [17]. Ak mas chut sa dozvediet viac, kludne sa ozvi, mozem dat nieco dokopy pre svoj blog. Toto je velmi zlozita a osemetna tema, veci ktore je potrebne osetrit je mnoho a existuje aj mnoho kombinacii moznosti pre zvysenie bezpecnosti.

[23] (Arthur Dent [openID] - Mail - WWW) 16.09.2008, 08:09:19 [X] [D]
[22] Zkus naťuknout httpOnline cookie, hněvat se nebudu. :) Jen mi přišlo zbytečně daleko offtopic probírat "k čemu že je taková ochrana" ([16]), protože to jsou elementární věci. X-FORWARDED-FOR jsem u AOL nezkoušel, ale jinak ho na Bloguje mám na zlobivé komentátory s proxy.

[24] (David Grudl - WWW) 16.09.2008, 08:56:40 [X] [D]
[20] jenže pozor na jednu věc. Být v případě přítomnosti hlavičky X-FORWARDED-FOR tolerantnější znamená řezat si větev sám pod sebou. Totiž pokud ukradnu někomu session, tak mi vlastně dovolíš ji použít s patřičně nastavenou X-XXX hlavičkou.

[25] (David Grudl - WWW) 16.09.2008, 09:03:58 [X] [D]
[23] httpOnly cookie je rozšířená informace pro prohlížeč, která říká, že cookie bude neviditelná pro JavaScript. Od verze 5.2.0 to podporuje i PHP, v předchozích šlo flag nastavovat fintou.

Je to docela chytrý způsob, jak zabránit jednomu typu útoků, ale stojí to a padá na podpoře prohlížečů. Protože jde tuším o vynález Microsoftu http://msdn.microsoft.com...46.aspx, tak IE 6 to podporuje (což je to hlavní, že). Firefox 3 to prý už umí taky.

[26] (Filip Jirsák - WWW) 16.09.2008, 11:33:23 [X] [D]
[18] „budes dufat, ze utocnik nie je prilis inteligentny“

Myslím, že to je celý problém téhle techniky ochrany sezení. Předpokládá, že útočník je natolik schopný, že dokáže identifikátor sezení získat a to v době jeho platnosti, ale pak už je natolik neschopný, že ho rovnou zkusí zneužít ze svého domácího počítače. A když mu to nevyjde, svoje pokusy vzdá.

Proto mi stále připadá jako nejlepší způsob, jak předejít problémům se změnou IP adresy, tu IP adresu jednoduše nekontrolovat, nijak, ignorovat ji. Předejde se tím všem problémům s kontrolou spojeným, a na bezpečnosti se to negativně neprojeví nijak. Ostatně, větu „nedělejte to“ v původním příspěvku jsem chápal přesně takhle. Teprve až z komentáře [15] jsem usoudil, že to „nedělejte to“ Arthur asi nemyslel doslova.

Ovšem pokud je tématem „co dělat s IP adresou, aby to bylo dostatečně efektní a uživatele to otravovalo jenom občas“, pak je tento komentář mimo téma, za což se omlouvám.

[27] (ehmo - WWW) 16.09.2008, 16:26:10 [X] [D]
[23] Bohuzial nestiham, akurat robim POC pre Jima Kukrala, ktoreho script pouzivas aj ty tu (scratchback). Mozno inokedy.

[24] To ze som tolerantnejsi k urcitej hlavicke ty nezistis. Skor tam slo o nastavenie inaksich pravidiel, napr ze sa nepojde podla IP ale len casti plus zaroven sa urobi hash dalsich informacii ziskanych od uzivatelskeho browseru.

[25] Dnes to uz je podporovane mnohymi prehliadacmi aj ked ako si spravne podotkol, tam kde to nefunguje, je to dost naprt. Ostatne je to napisane aj tu Mitigating Cross-site Scripting With HTTP-only Cookies.

[26] Ono je to malinko zlozitejsie. Session Hijacking je dost zavazna chyba, najcastejsie na bankovych aplikaciach. Ak dokazes najst koliziu aktivnej session a ta nie je nijak chranena, dokazes tak prevziat prava daneho uzivatela. Ako sam uznas, u bank je to velmi kruty problem. Samozrejme, banky pouzivaju mnoho inych ochrannych prvkov, ale to na veci nic nemeni. Je preto potrebne uzivatelov malinko otravovat a donutit ich, aby raz za cas prekusli nejake to prihlasenie naviac, ako keby mali prist o konto. Tazko povedat, ci je tato cesta lepsia ako taka, kedy programator musi mysliet na uplne vsetky dalsie moznosti zneuzitia aplikacie, ako napriklad ze nesmie zabudnut implementovat pri zasadnych zmenach v uzivatelskom konte overovanie stareho hesla, mozno aj kontrolneho retazca? Tazko povedat

[28] (Filip Jirsák - WWW) 16.09.2008, 17:08:16 [X] [D]
[27] I ta nejhloupější bankovní aplikace funguje přes HTTPS a pro identifikátor sezení používá nějaký dostatečně dlouhý náhodný klíč. Takže náhodou „trefit“ nějaký identifikátor je velice nepravděpodobné (podaří se to zhruba tak v příštím vesmíru), a ukrást jej můžete buď v bankovní aplikaci, nebo u uživatele – mezi tím jde šifrovaným kanálem. Navíc bankovní aplikace nemůže být chráněna jenom proti crackerovi–nemehlu, ale musí být chráněna i proti schopnějším útokům. „Ochrana“ kontrolou IP adresy znamená, že může sezení unést kdokoli za stejným NATem (tedy třeba kterýkoli kolega v práci, kterýkoli spolužák), kdokoli za stejným proxy serverem (AOL je zmíněn hned v článku), při benevolentnější ochraně kdokoli ve stejné třeba C síti – to už může být dost klientů mého ISP v okolí.

„Tazko povedat, ci je tato cesta lepsia ako taka, kedy programator musi mysliet na uplne vsetky dalsie moznosti zneuzitia aplikacie, ako napriklad ze nesmie zabudnut implementovat pri zasadnych zmenach v uzivatelskom konte overovanie stareho hesla, mozno aj kontrolneho retazca?“

Kontrola IP adresy nechrání před ničím. Takže to ostatní zabezpečení programátor stejně musí udělat, a tu kontrolu IP adresy si může ušetřit (přijde tím o pár hlášek vhodných k naštvání uživatele, o nic jiného). Pokud si programátor myslí, že kontroluje IP adresy a únos sezení ho tedy nemusí zajímat, je na dobré cestě spáchat v systému pořádnou bezpečnostní díru. Takže jediná rada pro kontrolu IP adresy sezení zní – nedělejte to!

[29] (Roman - Mail - WWW) 16.09.2008, 21:57:40 [X] [D]
...je ešte toľko krásnych slovíčok ako zasadnutie, schôdza, jednanie, relácia, porada, rokovanie ktoré ktoré sa nehodia na preloženie slovíčka session... nechápem prečo mal autor toho útrpného prekladu "sezení" utkvelú predstavu že nemôže použiť niečo čo nie je doslovným prekladom... napríklad "spojení"... apropo, čo na ty na to Pixy? Netrhá ti to "sezení" uši?

[30] (Roman - Mail - WWW) 16.09.2008, 21:59:54 [X] [D]
[27] ...ako napriklad ze nesmie zabudnut implementovat pri zasadnych zmenach v uzivatelskom konte overovanie stareho hesla,...

Veru, veru, múdro hovoríš, až mi je to divnô. :-)

[31] (Roman - Mail - WWW) 16.09.2008, 22:01:17 [X] [D]
[29] ...hm, este sa zbavit koktania a bude to fajn.

[32] (http://openid.cz/richard.bukovansky - Mail ) 16.09.2008, 22:30:21 [X] [D]
Jak to tak posloucham, uz aby bylo efektivne zavedeno IPv6...
Problem se ukradnutim session se velmi spatne resi, nezbyva nic jineho nez pouzit HTTPS, protoze proc krast session, kdyz jde ukradnout plaintextove heslo. Resit napadeni u non-HTTPs aplikace je trochu na povazenou...

[33] (Arthur Dent [openID] - Mail - WWW) 16.09.2008, 23:28:59 [X] [D]
[32] Ne každá non-HTTPS aplikace musí posílat plaintext heslo, že. Jistě jsi slyšel třeba o Digest autentifikaci. ;) Pro ty, co neslyšeli, dodám: http://en.wikipedia.org...ntication (Upozornění pro blbé: POUZE polemizuju s nevysloveným předpokladem, že neHTTPS aplikace rovná se automaticky plaintext heslo!)

[34] (ehmo - WWW) 17.09.2008, 22:56:16 [X] [D]
[28] je vidiet ze si v zivote videl vela IB. ja uz som sa s par stretol co sa tyka bezpecnosti a viem na ake zranitelnosti krasne trpia. uhadnut sessid nie je vzdy az take zlozite ako by si si myslel, ale rozoberat to zbytocne nebudem. bankova aplikacia by mala byt vrcholom bezpecnosti, neplati to vsak snad u ziadnej (cest vynimkam, zatial som ziadnu nevidel (aj ked MBank nema daleko)).

[32] Martin ti uz na to dal odpoved. nie kazda aplikacia (okrem rapidshare.com) posiela plain/text hesla. Existuju aj riesenia pre JS a mnoho inych, ktore vedia pomoct.

Kazdopadne ak session nie je chranena pre IP, hlavicka moc nepomoze. Ano, ked je clovek za jednym NATom tak je to jedno, ale ked uz moj spoluziak alebo kolega sa ma rozhodne okradnut, tak existuju aj lepsie riesenia ako kradnut session.

[35] (Franta - Mail - WWW) 21.09.2008, 17:05:58 [X] [D]
Svět by se neměl přizpůsobovat lidem, kteří mají "postižený" Internet. Naopak oni by měli apelovat na své poskytovatele, aby jim nabídli plnohodnotné připojení.

Ještě přijatelným kompromisem je dát uživatelům na vybranou - jako to mají např. na http://mail.volny.cz/ - "Kontrola IP adresy pro vyšší bezpečnost?".

Ale degradovat všem uživatelům bezpečnost kvůli tomu, že nějaký trouba nemá solidní připojení, je hloupost.

[36] (Franta - Mail - WWW) 21.09.2008, 17:20:30 [X] [D]
[33] viz třeba praktická ukázka na http://frantovo.cz...vatelu-na-webu

Někdy se HTTPS použije jen pro přenos jména/hesla a pak už sezení pokračuje nešifrovaně (kvůli zátěži serveru) - pak se kontrola IP adresy hodí. Uživatelům, které to kvůli jiné IP odhlašuje, pak doporučujeme používat variantu, která jede celou dobu po HTTPS, tam se IP kontrolovat nemusí.