Dostatocna autentifikacia?

westrem

Ahoj,
ako si tak studujem zdrojaky Nette prisiel som az k triede User, ktora zapuzdruje narabanie s uzivatelom.

Ak spravne chapem tak Nette zistuje ci je clovek prihlaseny len za pomoci existencie $session a pravdivosti $session->authenticated.

Nie je to potencionalne bezpecnostne riziko? Je to len otazka do plena, viem, ze Nette je framework, ktory najviac dba prave na eliminovanie bezpecnostnych rizik. Nejde mi vsak do hlavy ako je mozne spoliehat len na tieto dve veci. Nie je mozne podstrcit falosnu session pripadne to nejak obist (nie som odbornik na problematiku session pripadne nejakych inych nekalich praktik)?

Doteraz som to totiz vzdy riesil tak, ze pri prihlaseni som uzivatelovi vygeneroval hash, ktory som ulozil v DB a do session som ulozil len nutne minimum, za pomoci ktoreho som vedel usera identifikovat a zaroven rekonstruovat hash v DB a pri kazdom requeste, ktory vyzadoval prihlaseneho uzivatela som kontroloval udaje v session s hashom v DB.

Na zaver este jedna mala otazocka, ak dobre predpokladam, na napisanie vlastneho spravcu userov staci implementovat IUser. Dajme tomu, ze mam triedu PUser, ako ju potom v config.ini zaregistrujem ako sluzbu nad usermi? Ide mi o konkretny riadok kodu, ktory som uz niekde videl ale neviem si spomenut kde, dakujem.

nAS

Tak to jsi celou dobu implementoval přesně to co dělá session sama nad cookies. Takže jsi měl takovou session² :) K tvé otázce: pokud nemá útočník přístup k místu kam ukládáš session (typicky filesystém), tak session podstrčit nemůže, ani v ní modifikovat data.

A k druhé otázce, třeba nějak takto:

service.Nette-Web-IUser = PUser

Editoval nAS (9. 8. 2010 19:29)

westrem

Vdaka,
to s tym session² som si uvedomil vlastne az teraz ako si to napisal, nikdy mi to netrklo.

K tomu podstrcenemu session: a nie je mozne tam nejak pomocou JS carovat s cookies? (Zase raz do toho plne nevidim tak sa pytam).

Dakujem.

nAS

Čarovat s cookies samozřejmě možné je, ale v cookie je uložen právě jenom ten náhodný klíč, takže když si uživatel změní cookie, tak se nespáruje s jeho session, takže se mu vygeneruje nová prázdná a to je tak vše. Ale žádným způsobem nemůže měnit to co máme uloženo na serveru pod tím klíčem.

srigi

westrem napsal(a):

K tomu podstrcenemu session: a nie je mozne tam nejak pomocou JS carovat s cookies? (Zase raz do toho plne nevidim tak sa pytam).

Ano pomocou JS vies ukradnut cookie ktora obsahuje PHPSESSID. VO vseobecnosti to umoznuje utok typu XSS, znamy je pripad Abclinuxu,

Utok je ale mozny iba vtedy, ako dokazes na stranku podstrcit JS kod, ktory sa vykona inemu – prihlasenemu userovi. A pred tymto Nette proaktivne chrani.

Editoval srigi (9. 8. 2010 20:39)

Panda

Pomocí JS je možné přistupovat ke cookies, ale ten JS musí pocházet ze stránky umístěné se stejnou. A pokud útočník může vložit JS do Tvého webu, tak něco není v pořádku.

// Doplnění: tak koukám, že jsem byl moc pomalý. :-)

Editoval Panda (9. 8. 2010 20:48)

westrem

srigi napsal(a):

westrem napsal(a):

K tomu podstrcenemu session: a nie je mozne tam nejak pomocou JS carovat s cookies? (Zase raz do toho plne nevidim tak sa pytam).

Ano pomocou JS vies ukradnut cookie ktora obsahuje PHPSESSID. VO vseobecnosti to umoznuje utok typu XSS, znamy je pripad Abclinuxu,

Utok je ale mozny iba vtedy, ako dokazes na stranku podstrcit JS kod, ktory sa vykona inemu – prihlasenemu userovi. A pred tymto Nette proaktivne chrani.

Ano, toto viem, pytal som pretoze som si nebol isty ci nie je mozne pomocou JS docielit aj nieco viac.
Takze v konecnom dosledku je teda implementacia v Nette spolahliva, pretoze ak by si niekto aj podstrcil novy cookie tak sa v Nette inicializuje nova session a utocnik ma smolu ano?

MIKI

Rychlym hladanim v tejto casti fora som nenasiel odpoved na svoju otazku, tak sa pytam tu, kde to vyzera byt „najblizsie“

Taktiez som robil autentizaciu ako popisoval westrem, cez tu DB & SID. V tomto smere som teda celkom rad, ze mi odpada takato uloha. (Session poznam, ale nerad som to pouzival :) )

Ako som prezeral zdrojove kody (nie vsetky a dokladne, priznavam), tak si neviem pomoct, ale mam pocit, ze by bol problem s „dvojitym prihlasenim“, ktore chcem osetrit. Cize prihlaseny moze byt uzivatel len raz. Ak sa prihlasi druhykrat, tak „stare session“ sa mu zrusi, nebude platne. Dokaze toto Nette „samo“, alebo je nutne to dorobit individualne?
Viem si predstavit, ze by som v DB uschovaval a kontroloval Session ID, ktory sa uklada v cookies. Ako sa k nemu dostanem cez prihlaseneho uzivatela?

Vopred vdaka za odpoved/nasmerovanie :)

Patrik Votoček

Můžeš to řešit několika způsoby.

jako session storage použít DB. A kotrolovat si jestli už nejsou taková a maková data.
přikaždém požadavku kontrolovat uživatele na nějáký token (implementovat tak aby každý uživatel mohl mít pouze jeden)

Najdou se určitě i další způsoby… Ale víc mě jich teď před spánkem nenapadá…