Autor Zpráva
Lloyd
Profil *
Dobrý den,
vždy jsem si myslel, že přihlášení, nebo data se za pomocí sessions odmažou po zavření prohlížeče a s tím také kalkuloval.
Vidím ale, že tomu tak nebude.
na www.czc.cz jsem se přihlásil, naklikal si nákupní košík, restartoval pc a po zapnutí czc.cz jsem byl přihlášen a stále data v košíku.

Jak je možné, že mi přihlášení nepadlo?
Rád bych tohoto také dosahl na mém webu shopu.

Díky za rady,
Lloyd
SeparateSK
Profil
Áno, je to riešené cez cookie, tam si stránka uloží tvoj nick a heslo.
shaggy
Profil
SeparateSK:
tam si stránka uloží tvoj nick a heslo.
To hádam nie. Aj keď aj veľký eshop môže urobiť zlý programátor, neverím, že by takúto zvrhlosť niekto urobil. Prihlasovacie údaje v žiadnom prípade nepatria do cookie (ani nikam inam, než na server), to by si mohol vedieť.
Chuchycek
Profil
Občas se stačí trošku podívat na google..., nicméně podívej se jak to řeší třeba Jakub Vrána
SeparateSK
Profil
shaggy:
v hashi samozrejme
Alphard
Profil
SeparateSK [#5]:
Ani to asi ne. Pro tyto účely je třeba časově limitovaný token. A navíc, heslo nesdělujeme ani v hashi.
SeparateSK
Profil
A prečo by aj nie?
$meno=$_COOKIE["meno"];
$heslo=$_COOKIE["heslo"];
$q=mysql_query("SELECT * FROM users WHERE name='$meno'");
$arr=mysql_fetch_array($q);
if($heslo!=$arr["password"])
   exit();
Rfilip
Profil
Čitelný jméno a heslo v cookie? Děláš si snad srandu ne?
SeparateSK
Profil
Kto alebo čo hovorí, že sú čitateľné?
$heslo!=$arr["password"] ?


Kľudne môžu byť vo vlastnom encodovaní.


Asi lepší príklad:
function decode($text){
     //....
}
$meno=$_COOKIE["meno"];
$heslo=$_COOKIE["heslo"];
$q=mysql_query("SELECT * FROM users WHERE name='".decode($meno)."'");
$arr=mysql_fetch_array($q);
if(decode($heslo)!=$arr["password"])
   exit();



A myslíš si snáď, že útočník bude vedieť ako funguje tvoje vlastné encodovanie?
shaggy
Profil
SeparateSK:
A myslíš si snáď, že útočník bude vedieť ako funguje tvoje vlastné encodovanie?
A ty si myslíš, že s tak obmedzenými znalosťami (aké máš) vymyslíš enkódovanie, ktoré útočník nedokáže prelomiť?
Traja sme ti napísali, že tieto veci do cookies nepatria. Dostal si aj odkaz na praktické riešenie, ale ty sa napriek tomu ideš hádať?
SeparateSK
Profil
Len si dajte: javascript:alert(document.cookie) na tejto sieti - djpw.cz ;)
miniBBsite={NICK}%7C{md5(HESLO)}%7C{login_time+60*60*24*(365/2)}
Meno, heslo i expirácia v jednom cookie

shaggy:
Prihlasovacie údaje v žiadnom prípade nepatria do cookie (ani nikam inam, než na server), to by si mohol vedieť.

Alphard:
A navíc, heslo nesdělujeme ani v hashi.


%7C = |
Joker
Profil
SeparateSK:
Kto alebo čo hovorí, že sú čitateľné?
$heslo!=$arr["password"] ?
Pak je heslo bez problému čitelné. Jediný efekt je, že když uživatel zadá heslo třeba „heslo“, pro tu cookie bude heslo „955db0b81ef1989b4a4dfeae8061a9a6“ a bude se držet v prostém textu.
Jakýkoliv uživatel získá hash hesla se dokáže přihlásit jako ten daný uživatel.

Len si dajte: javascript:alert(document.cookie) na tejto sieti - djpw.cz ;)
Tato diskuse historicky vychází z prastaré verze miniBB s hromadou bezpečnostních chyb, které se zdejší vývojáři postupně snaží odbourávat.
Čili ano, v kódu diskuse se mohou vyskytnout věci, které byste doma rozhodně zkoušet neměli :-)
Mimochodem, stejnou chybou trpělo phpBB do verze 3.
SeparateSK
Profil
Joker:
Jakýkoliv uživatel získá hash hesla se dokáže přihlásit jako ten daný uživatel.
Ach, teda pardon, moja chyba, nad týmto som vôbec nepremýšľal a kvôli tomu vznikol celý spor - kvôli mojej nedbanlivosti :-) .
Str4wberry
Profil
Ehm, čím ten časově limitovaný náhodný token bude pro dlouhé přihlášení bezpečnější? Pokud ukradnu danou sušenku, tak je to přece úplně jedno — oboje bude platit hodně dlouho. Nebo mi něco uniká*?

*) Nebo je pointa v tom, že ze špatně zajištěného hesla v cookie může jít vyčíst originální heslo? To je ale spíš problém obecně špatného hashování hesel.
Joker
Profil
Str4wberry:
Nebo je pointa v tom, že ze špatně zajištěného hesla v cookie může jít vyčíst originální heslo?
To může být problém, ale podle mě větší problém jsou dvě věci:
1. Dokud má uživatel stejné heslo, bude stejný i token. Pokud odchytím token a uživatel o tom neví, můžu se na něj přihlašovat, dokud si nezmění heslo, které si většina uživatelů nemění nikdy.
Když uživatel dostane token, který se při odhlášení zruší a při dalším přihlášení přidelí jiný, můžu se na jeden odchycený token přihlašovat jen do chvíle, než se ten uživatel odhlásí.
2. Pokud vím, jak má přihlašovací cookie vypadat (což obvykle není těžké zjistit), můžu se znalostí hashe uživatelova hesla, aniž bych prolomil jeho skutečné heslo, vytvořit přihlašovací cookie, na základě které mě systém automaticky přihlásí pod účtem daného uživatele.
A sám uživatel tomu nemůže nijak zabránit, pokud systém neumožňuje natvrdo zakázat automatické přihlašování.

Další výhoda samostatného tokenu je, že když nebude čistě náhodný, ale závislý na nějaké informaci od klienta (třeba i user-agent), ani ukořistěním přihlašovacího tokenu nebude jednoduše možné se přihlásit z jiného počítače.
Str4wberry
Profil
Ad 1)
Narážel jsem na to, že pokud chci mít trvalé přihlášení, tedy hodně dlouhou dobu platnosti, tak se ta výhoda v časovém omezení nemusí moc projevit. Protože i ten časově limitovaný token bude platit hodně dlouho. (Schválně jsem se podíval na cookie u trvalého přihlášení na Twitteru a platnost se tam zdá být 30 let.)

Ale máš pravdu, že odhlášením a přihlášením se lehce snižuje risiko dlouhodobého zneužívání.

Ad 2)
Myslíš to tak, že se nějak dostaneš k hashi uživatelova hesla a díky tomu se dokážeš přihlásit? To ale stejně tak platí pro jakýkoliv token.

Hraní si s user-agentem může vést k nechtěnému odhlašování třeba po aktualisaci prohlížeče. Na druhou stranu pokud dokáže útočník získat cookie, řekl bych, že dokáže i toho user-agenta.
Amunak
Profil
U tokenu je výhoda, že se může změnit jednou za čas (třeba jednou denně) i bez odhlášení uživatele. Tím by se taky nejspíš dalo zamezit ukradení cookie. Nehledě na to, že v prostředích kde je potřeba vysoká bezpečnost jde token svázat s jedinou IP adresou, což je pro útočníka další velká překážka.
Str4wberry
Profil
U tokenu je výhoda, že se může změnit jednou za čas (třeba jednou denně) i bez odhlášení uživatele.
To se ale stejně tak prodlouží i zloději, ne?

jde token svázat s jedinou IP adresou, což je pro útočníka další velká překážka
Což je překážka i pro běžného uživatele, protože ho to bude pořád odhlašovat, když se mu IP změní. Pokud je potřeba vysoká bezpečnost, tak se asi vůbec nebudeme bavit o trvalém přihlášení, že? :–)
Amunak
Profil
Str4wberry:
To se ale stejně tak prodlouží i zloději, ne?
Aby se token mohl změnit, musí se to stát při nějaké akci uživatele kdy jde změnit cookie. Tedy třeba při přechodu na jinou stránku. Šance, že se toto stane útočníkovi je malá. A pokud se to stane útočníkovi, pak to uživatele odlásí (protože má starý token) a při dalším přihlášení získá token pro sebe oprávněný uživatel, takže útočník zase prohraje. Není to stoprocentní, ale myslím, že pořád lepší než jeden neměnný token na třicet let.

Pokud je potřeba vysoká bezpečnost, tak se asi vůbec nebudeme bavit o trvalém přihlášení, že? :–)
Pravda, taky mi to pak došlo.
Str4wberry
Profil
Nezablokujeme tím možnost být trvale přihlášen na více strojích (prohlížečích) najednou?
Amunak
Profil
Str4wberry:
Zablokujeme. Alternativně jde prostě vypsat někdě (v profilu uživatele) všechna aktivní přihlášení s možností je zrušit. Pro přidanou bezpečnost pak případně informovat (v profilu nebo na mailu) o tom, že se někdo přihlásil z nové IP adresy nebo něco podobného. Otázka ale je, jestli tomu někdo věnuje pozornost.
Str4wberry
Profil
To ale bude otravné. Přihlásit se z nové IP je celkem běžná záležitost. (Sám jsem na tuto diskusi poslal příspěvky z více než 200 IP adres.) A také taková informace bude pro běžné uživatele španělská vesnice.
Amunak
Profil
Str4wberry:
Právě. Přesto se to někde dá vidět a mě osobně to vyhovuje. Asi to ale nemá smysl pro web, kde není třeba zabezpečení moc hlídat. Ono beztak jde prakticky jen o pohodlnou správu tokenů.
Joker
Profil
Str4wberry:
pokud chci mít trvalé přihlášení, tedy hodně dlouhou dobu platnosti, tak se ta výhoda v časovém omezení nemusí moc projevit
To je pravda, i tak se ale uživatel bude asi odhlašovat častěji, než si měnit heslo.
Krom toho mě napadl zhruba mechanismus, jaký popisuje Amunak:
Trvalé přihlášení vlastně funguje tak, že když uživateli vyprší relace a pošle nějaký token, systém mu automaticky vyrobí relaci novou. A to je zároveň docela výhodný bod, kdy lze samostatný token zahodit a vyrobit nový.
Každý token by tak vlastně sloužil k jednorázovému přihlášení. Při přihlášení ve chvíli, kdy vypršela session na serveru, bych „spotřeboval“ token a zároveň dostal nový.
Útočník by musel token odchytit a zároveň i použít v době mezi jeho získáním a spotřebováním uživatelem.
Takové přihlášení by ale zároveň spotřebovalo token a příští otevření stránky oprávněným uživatelem vyvolá situaci, kterou je možné detekovat a řešit. Neboli je možné detekovat i úspěšné neoprávněné přihlášení.

Myslíš to tak, že se nějak dostaneš k hashi uživatelova hesla a díky tomu se dokážeš přihlásit? To ale stejně tak platí pro jakýkoliv token.
Ale aby útočník mohl získat samostatný token, musí ho uživatel nejdřív vytvořit. Nelze tak nabourat účet, který nemá aktuálně platné trvalé přihlášení.
Při použití hashe hesla je token vygenerovaný a platný vždycky. I když bude uživatel paranoidní a trvalé přihlášení nikdy nebude používat, útočník si stejně může vyrobit cookie.
S jednorázovými tokeny navíc útočník musí stihnout token získat i spotřebovat v době od jeho vygenerování do spotřebování oprávněným uživatelem.

Hraní si s user-agentem může vést k nechtěnému odhlašování třeba po aktualisaci prohlížeče.
To ano.
Ale lze používat jen nějaké části (třeba název prohlížeče a operační systém). Takhle mám k dispozici škálu různých parametrů a můžu zvolit vhodný poměr mezi otravováním uživatelů a bezpečností.

pokud dokáže útočník získat cookie, řekl bych, že dokáže i toho user-agenta.
Pokud ví, co vlastně potřebuje. Že umí získat cookie ještě neznamená, že zná algoritmus sestavování tokenu na serveru (nebo alespoň ví, jaké údaje se pro to používají).

Nezablokujeme tím možnost být trvale přihlášen na více strojích (prohlížečích) najednou?
Můžu token svázat s počítačem, po jedné zdejší starší debatě s argumentem přecházení s jedním zařízením mezi WiFi sítěmi možná raději přes jiné údaje než IP, a zároveň umožnit více tokenů.
I když, kdybych si s tím chtěl vyhrát, bylo by možné udělat mechanismus, který by kontroloval víc faktorů a určité změny toleroval, například povolil změnu IP, pokud je stejný user-agent anebo změnu user-agenta, pokud je stejná IP, prohlížeč a operační systém.

Je pravda, že když už bych chtěl dělat takhle vychytaný systém, šlo by jako token použít i ten hash hesla, prostě bych přidal tabulku, ze kterých míst je povolené trvalé přihlášení. Ale pořád by to se samostatným tokenem bylo ještě o trošku bezpečnější.
Str4wberry
Profil
Pořád přemýšlím, čím se to znovuvytvoření tokenu liší v případě oprávněného uživatele a narušitele. Z tvého popisu mi akorát vyplývá, že je menší čas na první použití ukradené sušenky, protože v ukradené podobě funguje jen do další akce oprávněného uživatele.

Jenom ujasním požadavky na funkčnost:
Neodhlášení při změně IP,
neodhlášení při aktualisaci prohlížeče,
možnost být současně přihlášen na více zařízeních.

Řekněme, že sušenku budu získávat pomocí XSS JavaScriptem, zároveň si pošlu všechna dostupná data o uživateli, takže pro mě nebude problém nasimulovat konkrétní OS a prohlížeč.

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: