to sice ano, ale pokud to % vztáhneš k množství uživatelských účtů, od nuly bude již dále. Zneplatnění session při změně hesla co vím neumí běžné open source CMS typu Wordpress.
Co mě ale u řady služeb chybí, tak je zobrazení aktivních přihlášených session a možnost je odhlásit, uvítal bych to zejména u bank, ale i u jakékoliv další služby.
Pokud to dobře chápu, tohle je jiný princip – že se při obnově spojení účet vůbec neověřuje. Útočník by se tedy mohl „přihlásit“ bez znalosti jakéhokoli hesla.
Navíc zneplatnění všech session při změně je sporná praktika, při samotné změně hesla k tomu není důvod. Důvod k tomu je, pokud předpokládám, že někdo získal neoprávněný přístup k účtu – jenže ne každá změna hesla musí být vyvolána podezřením na kompromitaci hesla.
Je to exaktne stejnej princip, pri pouziti web session se taky nezjistuje zadny heslo, a proste se bere za to, ze autorizace prosla. Pokud nekdo necha session platnou i protom, co uzivatel heslo zmeni, tak si zaslouzi viset za koule v pruvanu, protoze user si to heslo (jako v tomhle pripade) meni prevazne proto, ze ma podezreni ze se na nej prihlasuje nekdo/nebo neco, co nema. S platnou session se muze vesele prihlasovat dal a protoze se session prevazne pri prihlaseni sama obnovuje ... tak libovolne dlouho a navzdy.
V tomhle konkretnim pripade je to jen okoreneno tim, ze se platna session vytvori jeste driv, nez dojde k autorizaci, a presto, ze k ni nedoslo, zustava platna.
Defakto neni v clanku popsano, jestli oprava resi jen to preruseni spojeni, nebo jestli resi i tu zmenu hesla.
Je to exaktne stejnej princip, pri pouziti web session se taky nezjistuje zadny heslo, a proste se bere za to, ze autorizace prosla.
Ne, při použití session se předpokládá, že v dané session už byl konkrétní uživatel autentizován.
Stejný princip jako u té chyby FreeRADIUS by byl, kdyby si útočník vymyslel sessionID, odeslal požadavek (bez jména a hesla) na server, před získáním odpovědi spojení přerušil, pak se přesunul na jiný počítač a tam zadal stejné sessionID, a komunikace by prošla. Což u toho webu moc nedává smysl, protože tam se session vytvářejí proto, abyste věděl, který to je uživatel, takže mít autentizovanou session bez uživatele bude obvykle nemožné.
protoze user si to heslo (jako v tomhle pripade) meni prevazne proto, ze ma podezreni ze se na nej prihlasuje nekdo/nebo neco, co nema
To je pouze vaše domněnka.
S platnou session se muze vesele prihlasovat dal a protoze se session prevazne pri prihlaseni sama obnovuje ... tak libovolne dlouho a navzdy.
Session by samozřejmě mělo být možné zneplatnit, ale nemusí se to dělat automaticky se změnou hesla. Spíš by na to měl být mechanismus, který bude vyžadovat ještě něco, než jen znalost aktuálního hesla.
Trochu zapomínáte na to, jakou popisujete situaci. Pokud útočník uživateli změní heslo a tím ho zároveň odhlásí ze všech session, má uživatel smůlu a nadobro přišel o účet. Pokud útočník změní heslo, ale nezruší tím všechny session, původní uživatel je nejspíš někde ještě přihlášen a může přes tohle původní přihlášení svůj účet znova ovládnout, změnit heslo a zrušit útočníkovu session.
V tomhle konkretnim pripade je to jen okoreneno tim, ze se platna session vytvori jeste driv, nez dojde k autorizaci, a presto, ze k ni nedoslo, zustava platna.
Ne, to není „okořenění“, to je podstata chyby.
Defakto neni v clanku popsano, jestli oprava resi jen to preruseni spojeni, nebo jestli resi i tu zmenu hesla.
Změny hesla se to vůbec netýká. Autentizace v tomhle případě ani nemusí být jménem a heslem, jako autentizační protokol je možné zvolit třeba klientské certifikáty nebo jednorázová hesla.
Při obnovení přerušeného spojení FreeRADIUS 3.0.x v defaultní konfiguraci důvěřuje autorizaci z doby vytvoření spojení. Dokonce ani neukládá dodatečně přiřazované parametry jako VLAN a při obnově je tudíž neposílá.
FreeRADIUS umožňuje obnovení parametrů i provedení dodatečných kontrol při obnovení spojení, ale správce to musí nakonfigurovat.
Při vytvoření spojení FreeRADIUS ukládá atributy User-Name, Stripped-User-Name a Cached-Session-Policy. Obsah posledního atributu si musí nastavit správce při úspěšném vytvoření spojení. Při obnově spojení může jeho obsah použít pro nastavení parametrů jako je VLAN. Pokud se do atributu uloží i čas vytvoření spojení, tak by mělo jít zkontrolovat, zda se mezitím nezměnilo heslo uživatele. Nezkoušel jsem to, v diskusním listu pro FreeRADIUS lze nalézt několik ukázek použití atributu Cached-Session-Policy.
Tedy teď si nejsem jistý na co vlastně reagujete.
U toho FreeRadiusu je potřeba pouze pokus o přihlášení, vhodně přerušený před ověřením hesla. Tedy "založení platné session" ještě před ověřením hesla a vhodným přerušením a následným navázáním spojení se znalostí té session se tomu ověřování úplně vyhnout.
U těch webů s tou session to tak je. Problém je, když se ta session dá prodlužovat (do nekonečna), například přístupem. Větším problémem je pak, když se předává v url kvůli tomu, že se má sdílet mezi doménami. To se pak snadno dostane i do googlu (protože uživatel někam pastne url) a taková session pak nevyprší (o to se postarají třeba roboti.)