Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.
Ještě se vrátím k tomuhle. Zajímalo by mne, jak si to představujete prakticky. Bavíme se o mikroslužbách, takže mám hejno služeb poskytujících nějaké API, typicky RESTové. Vedle toho mám hejno aplikací konzumujících ty služby, mezi nimi obvykle nějkaé SPA běžící v prohlížeči.
Konzument může klidně zavolat jedinou API službu a tím veškerá komunikace s tím API končí. Takže nemůžu použít klasické předpotopní ochrany proti CSRF rozbíjející web, které spočívají v tom, že se nevolá API ale zobrzauje se formulář a z něj se odesílají data – takže uživatel musí nejprve zobrazit nějaký formulář, který získá klíč pro jedno volání API. Takže API musí být stavové a uživatel má smůlu při používání prohlížeče – nmůže používat tlačítko zpět, nemůže si formulář duplikovat na další záložce.
OK, budete se tedy snažit zabránit CSRF pomocí SameSite cookie (která závisí na podpoře prohlížeče a bohužel ještě zcela nezmizely prohlížeče, které ji nepodporují). Jenže jde to reálně udělat? Ukažme si to na nějakém příkladu použití mikroslužeb. Představme si vydavatelství, které vydává několik internetových magazínů, a má pro ně společné účty. (Příklad je to čistě hypotetický, s uvedeným vydavatelstvím ani jeho softwarem nemám nic poslečného, jsem jen čtenář.) Takže to vydavatelství má mikroslužbu obhospodařující uživatelské účty dejme tomu na adrese user.api.iinfo.cz. Bude tam nějaký endpoint volaný metodou GET na adrese user.api.iinfo.cz/basicInfo, který vrátí základní informace o uživateli, které s ezobrzaují na každé stránce – jeho uživatelské jméno, odkaz na profilovou fotku, typ podporovatele. Tohle API pak budou volat jednotlivé magazíny třeba z adres root.cz, lupa.cz apod.
To asi se SameSite cookie fungovat nebude, že?
61 Odpovědí
19359 Zhlédnutí