Přihlášení pomocí tokenu a zvýšení bezpečnosti

[manik]

Ahojte, riesim momentalne pre svoj web v springu prihlasovanie cez rest pomocou jwt. Bezstavovost tokenu je super vyhoda, no na druhu stranu je tu otazka bezpecnosti, a to ako zabezpecit ucet uzivatela voci tomu, ze niekto ziska token z jeho lokal storage token a pokusi sa pomocou neho prihlasit? Napada ma moznost uchovavat token, alebo nejaky iny udaj v db, ale tym pridem o vyhodu ktoru so sebou tokenu nesu. Druha moznost ktora ma napadla je uchovavat v tokene ip z akej sa uzivatel prihlasil, a pri requeste kontrolovat ci sa ip requestu zhoduje s tou v tokene. Mate nejake napady?

[Reklama]

[harrison314]

1, Zakladom je https, myslim, ze ine zabezpecnie sa pri JWT ani nepouziva. A bez neho nema jwt ziaden vyznam.
2, Akykolvek iny udaj vies dat do tokenu, nemusis ho tahat do DB, token je predsa podpisany.

[manik]

1. to povazujem za samozrejme ze komunikacia bude zabezpecena, to ale neriesi problem ak bude mat uzivatel zle zabezpeceny pc a nejakym sposobom ho ziska utocnik prave odtial.

preto ma napadlo ukladat v tokene tu ip, a kontrolovat ci je rovnaka ako v tokene, ak nie, uzivatel by bol presmerovany na prihlasenie.

[Natix]

Tohle se dá řešit krátkou životností access tokenu (řádově minuty), nicméně to vyžaduje implementace refresh tokenů, které ukrást jde taky. Nicméně pro ty už lze implementovat blacklist/whitelist, což sice ve výsledku vede na znovuvynalézání session, ale refresh tokeny se na rozdíl od access neposílají při každém requestu. Samozřejmě to výslednou implementaci komplikuje, takže dost záleží na konkrétní implementaci, kterého identity providera používáte atd.

Druhá možnost je token neukládat do local storage, ale do cookie, pokud ho resource server dokáže odtud přečíst. Tím se zbavíte problému s XSS (které je ale velký problém v každém případě), nicméně je pak výměnou za to třeba dát pozor na CSRF, protože takový token je pak posílaný automaticky s každým requestem, nejenom ajaxovým, ale i browserovým.

[Filip Jirsák]

Kontrolovat IP adresu klienta byl hodně hloupý nápad už před lety, a od té doby se pravděpodobnost, že se IP adresa klienta bude měnit, ještě podstatně zvýšila.

Pokud se někomu podaří dostat ke klientskému local storage, má dotyčný uživatel pravděpodobně mnohem větší problém, než že se někdo může přihlásit k vaší aplikaci.

[Reklama]

[manik]

Kontrolovat IP adresu klienta byl hodně hloupý nápad už před lety, a od té doby se pravděpodobnost, že se IP adresa klienta bude měnit, ještě podstatně zvýšila.

Pokud se někomu podaří dostat ke klientskému local storage, má dotyčný uživatel pravděpodobně mnohem větší problém, než že se někdo může přihlásit k vaší aplikaci.

samozrejme ze je to malo pravdepodobne ... no zvazoval som ci sa da nejakym elegantnym sposobom podchytit aj takato situacia.

[Filip Jirsák]

Nejde o to, že je to málo pravděpodobné, ale o to, že asi většina případů, kdy něco takového může nastat, spočívá v tom, že útočník ovládá uživatelův prohlížeč. V takovém případě může útočník poslat jakýkoli požadavek z jeho IP adresy a se všemi údaji, které zadává uživatel. Takže bránit se takovému útoku je marné. Takže zbývají případy, kdy by se útočník dostal k local storage kvůli nějaké chybě prohlížeče. Jenže prohlížeč může mít chybu i v úložišti cookies, uložených hesel, obraně proti cross-site scripting – stejně tedy nenajdete technologii, která by byla v prohlížeči zaručeně bezchybná.

[karlik]

Tak třeba včera jsem se potřeboval připojit na server a kolega mi zvědavě hleděl přes prsty a čekal, až budu zadávat heslo. Nemám to rád, tak jsem vytáhl token a bylo poklizeno.

[dnl]

Tohle se dá řešit krátkou životností access tokenu (řádově minuty), nicméně to vyžaduje implementace refresh tokenů, které ukrást jde taky. Nicméně pro ty už lze implementovat blacklist/whitelist, což sice ve výsledku vede na znovuvynalézání session, ale refresh tokeny se na rozdíl od access neposílají při každém requestu. Samozřejmě to výslednou implementaci komplikuje, takže dost záleží na konkrétní implementaci, kterého identity providera používáte atd.

Suhlasim. + zalezi aj na pouzitom flow. Ak je to klientska aplikacia (Angular), tak sa pouziva implicit grant flow a tam refresh tokeny neexistuju. Pouziva sa vsak vacsinou skryty iframe, ktory s pouzitim este platnej IDP session zaisti novy token na pozadi. Refresh tokeny su pouzite pri Authorization Code flow - typicky pre app, co bezia na strane servera, kde je mala sanca, ze bude kompromitovany client secret.

Referencia: http://openid.net/specs/openid-connect-core-1_0.html