sessions přes db

Koumal:
„mám sessions přes db“
K čemu je to dobré?

„a nepoužívám cookies“
Proč bez cookies? Vystavuješ se tak útoku Session Fixation. Navíc je to ošklivé.

„že tam může být jenom jeden uživatel s daným emailem“
K tomu slouží cizí klíče.

Právě čtu ten článek.

Odpověď na tvou otázku jež mi byla řečena:

Joker - Moderátor - #15 · Zasláno: 11.5.2010 10:19:53
koumal:
„Vždycky jsem si myslel, že udělat sessions přes databázi je nejlepší řešení.“ ...
Databázová „session“ tabulka se nepoužívá kvůli rychlosti, ale kvůli bezpečnosti, jako obrana proti tzv. session stealing.

koumal:
„Proč jsem chtěl používat sessions tabulku. Důvod je ten, že abych nemusel načítat informace z profilu uživatele a prohledávat kvantum registrovaných uživatelů“
To je přece zbytečné, přesně k tomu je ta session, aby se do ní takové informace ukládaly. Než si při přihlášení údaje přesypat v databázi do jiné tabulky a pak je číst odtamtud, to je lepší si je rovnou uložit do session.

Cookies mi nikdy moc nevyhovovali. Nejsou určeny k ukládání osobních informací a takových informací, o kterých nechci aby uživatel věděl nebo je mohl měnit.

Mluvím o databázové session a teď si nejsem vědom jestli existuje ještě jiná session, vím jen o těch cookies.

K tomu slouží cizí klíče.
Ted ti asi nerozumím o cem mluvis, mohl by jsi to upresnit? Jake klice? Diky

Pozn. Jokerova citace končí před slovy: Cookies mi nikdy moc nevyhovovali.(Říkám já dnes)

koumal:
Celkově mám pocit, že tu problematiku relací (sessions) chápete nějak jinak, než to ve skutečnosti je.

K té citaci tohoto vlákna dodám, že tam mluvím o databázové session tabulce, ale samozřejmě předpokládám, že se nějak bude posílat to session ID.
Čili to má být databázová tabulka a cookie, ne databázová tabulka nahrazující cookie.

„Cookies mi nikdy moc nevyhovovali. Nejsou určeny k ukládání osobních informací a takových informací, o kterých nechci aby uživatel věděl nebo je mohl měnit.“
Pořád je to ale lepší možnost než GET nebo POST.
A nějak se to session ID posílat musí, protože jinak:

„Musím vždy jako návštěvník poslat sessid? Co když nepošle?“
Server to bere jako návštěvníka který ještě nemá relaci a založí novou, vytvoří nové session ID. Čili se ztratí spojení se starou relací.
Neboli neposílat zpátky session ID má stejný výsledek jako session vůbec nepoužívat.

„Aplikace by měla vytvořit nové sessid a to předat buď přes $_GET nebo $_POST, že?“
Přes GET nebo POST může data posílat jen klient serveru, ne server klientovi.
Že aplikace vytvoří nové session ID je pravda. A následně v závislosti na nastavení:
- Pokud je zapnutá session cookie, pošle klientovi cookie pro session ID (proto taky, pokud se už předtím odeslal nějaký výstup na klienta a nelze tedy do hlaviček přidat cookie, zobrazí se ta známá chyba headers already sent).
- Pokud má klient vypnuté cookies a je zapnuté transparentní SID, server automaticky připojí session ID ke všem odkazům a do všech formulářů přidá neviditelný prvek se session ID.

Díky za reakci. Je to zvláštní, ale přesto, že jsem se to učil už před několika roky, tak stále v tom mám chaos. Asi díky tomu, že jsem dlouhou dobu všechno dělal přes databázovou session a přeposílání sessid přes url.

Majkl578 mě odkázal na článek o Session Fixation . Četl jsem ještě článek v češtině o bezpečnosti sessions, ale i tak v tom mám stále trochu zmatek.
1) Co znamená Session Fixation v češtině? Podstrčení session? Čili, útočník pošle dotyčnému odkaz se svým sessid. Dotyčný klikne na odkaz, změní se mu sessid a je jakoby nalogovyný na stejném účtu co útočník? Kdyby to bylo naopak tak to chápu.
2) Omylem někomu pošlu odkaz se svým sessid, on si nastaví stejné sessid, a přihlásí se na stejnou službu, kterou používám. Tak se buď přímo přihlásí na můj účet nebo se mu na disku vytvoří cookie obsahující stejné údaje které mám já. Chápu to jakžtakž správně?

Je teda proti Session Fixation dostažující řešení, že nebudu posílat sessid přes url? Zabráním situacím, že by někdo mohl zveřejnit nebo odeslat emailem svoje sessid. Ale ještě tu je možnost, že někdo ukradne obsah moji cookie nebo že server je špatně zabezpečený a povede se mu přečíst obsah session na serveru.

koumal:
použij session_regenerate_id(); ....takto se po použití u daného člověka změní a útočník ho už nebude moct použít
+ další věci uvedené na http://en.wikipedia.org/wiki/Session_fixation#Countermeasures

Když změním sessid, nedojde k přerušení relace? Vždyť Joker psal:

"Server to bere jako návštěvníka který ještě nemá relaci a založí novou, vytvoří nové session ID. Čili se ztratí spojení se starou relací. Neboli neposílat zpátky session ID má stejný výsledek jako session vůbec nepoužívat."

Změní se to i u klienta, jinak by to nemělo smysl
Používám to a nic se nepřerušuje

koumal:
„Když změním sessid, nedojde k přerušení relace?“
Při session_regenerate_id() ne, viz Nox, v tomhle případě to přečíslovává sám server, takže „ví“, že se ID změnilo.
Prostě server tu relaci „přeznačí“ a klientovi pošle nové ID.

Teď bych potřeboval nějaký co nejjednodušší kód, který bych mohl použít, tak tento kód by měl fungovat?



zdroj. 29-Aug-2008 10:50