Názory k článku
Bezpečnost na webu - přehled útoků na webové aplikace

Jsem jedinej paranoik, který na svých stránkách při každém načtení zabezpečené stránky měním session cookie (jak v DB, tak v prohlížeči)?

Jak se to vyrovná s tím, když uživatel v rámci session otevře odkaz do nového panelu a bude v prohlížení pokračovat současně z dvou panelů? V takovém případě by dle vašeho popisu nejspíš stránka v jednom panelu dostala novou session a druhá měla ještě session původní. Bude to uživateli fungovat?

Vzhledem k tomu, že session cookies bývají sdílené a pouze jako non-permanent, pak se nová cookie nastaví pro všechny okna (a taby) v daném procesu (tj. i pro všechny okna otevřené z původního). Díky tomu pak dojde ke změně cookie ve všech oknech naprosto bez problému.

To pak ale funguje jen proti krádeži session, ale nefunguje proti XSS ani CSRF.

Myslím, že když to běží přes cookie tak je lepší nastavit flag HttpOnly. Nelze pak z JavaScriptu obsah cookie přečíst. Takže nelze cookie ukrást.

...ale flag HttpOnly stále nefunguje ve všech prohlížečích - např. Safari - viz. https://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

Cookie s nastaveným HttpOnly flagem se pak chová jako cookie bez HttpOnly flagu.

Flag "HttpOnly" nemá žádný vliv na to, co jsem popsal výše:)

session_regenerate_id() v PHP

Ty nesmysly, co jsou v PHP, nepoužívám vůbec. Napsat si vlastní kód je na pár řádků...

Problém nastane v případech, kdy uživatel nechce zadávat jméno a heslo každých několik hodin, ale chce být přihlášen i několik týdnů (uživatelova IP adresa se pak bude pravděpodobně měnit).

IP adresa uživatele se může měnit i v řádu hodin nebo minut – stačí třeba být připojen přes proxy server s vyrovnáváním zátěže. Pokud už má někdo v moci třeba router na cestě od uživatele k serveru, aby dokázal odchytit session ID, nebude pro něj problém ani posílat a odchytávat dotazy s tou správnou IP adresou. Takže kontrola IP adresy session mi připadá jako takový efektní způsob, jak zdánlivě něco udělat pro bezpečnost, a ve skutečnosti neudělat nic – maximálně znesnadnit použití uživatelům, kteří opravdu mění IP adresu relativně často.

Byl tam spravny default. Kdyz uzivatel nerozumi, tak kontrolu IP adresy nevypne. Priste mozna bude nastvany, ze se mu heslo neulozilo, ale aspon ho nikdo nehackne.

Man in the middle je ale úplně jiná kategorie útoků. Webové útoky typicky pocházejí od osob, které nemají s obětí nic společného.

Pokud má někdo v moci router, nemusí se obtěžovat s odchytáváním sessionid, může si rovnou odchytit celou komunikaci včetně hesel.

to ale platí jen pro HTTP komunikaci - pokud webová aplikace vyžaduje jen zabezpečené připojení (HTTPS), tak to samozřejmě není možné odposlechnout, aniž by nedošlo ke změně certifikátu (uživatel by na to měl být prohlížečem upozorněn)

Nelze tak např. přímo do e-mailu, který informuje o přidání příspěvku, uvést odkaz na smazání bez potvrzení.

Odkaz pro smazání příspěvku bez potvrzení do e-mailu samozřejmě vložit lze. Stačí se oprostit od toho, že token (náhodný kód) musí být uložen právě do session a právě do formuláře. Token totiž může být na jedné straně součástí odkazu posílaného e-mailem a na druhé straně může být uložen v databázi vedle příspěvku. Aplikace tak zůstane odolná proti CSRF a zároveň pohodlná.