reklama

Nápad na bakalářskou práci se Spring

Re:Nápad na bakalářskou práci se Spring
« Odpověď #30 kdy: 27. 04. 2019, 14:53:57 »
Použít jen HTTPS (a z HTTP udělat jen přesměrování na HTTPS) je jen otázka konfigurace webového serveru. Autentizaci přihlášením klientským certifikátem přes HTTPS bych nedělal, podpora v prohlížečích je špatná. Ne že by to neodporovaly, ale UX je otřesné. Například Chrome vyžaduje od uživatele každých pár minut PIN k čipové kartě s uloženým certifikátem, pokud se používá TLS 1.3, protože dohodnutí nových parametrů TLS dělají opravdu důkladně až k té nové žádosti o PIN.

Pokud použijete jen jQuery, musíte si napsat sám spoustu věcí, které vám jinak poskytují ty frameworky. Angular je už dost velký framework, myslím, že by stačilo i něco lehčího – třeba Vue.js. Myslím, že se ho člověk naučí docela rychle a postará se za vás o ty dvě nejnudnější věci, které musíte pořád řešit v čistém JavaScriptu – propojení dat v JavaScriptovém objektu na HTML prvky (vstupní políčka formulářů a výstup) a spouštění akcí.

Pro autentizaci volání RESTových služeb jsem navrhoval použít protokol OAuth2, který k RESTovým požadavkům přidává JWT –JSON Web Token. V něm jsou zakódované údaje, které předal autentizační server, jsou jím podepsané a obvykle obsahují časovou značku. Autentizační server tedy vystaví JSON, ve kterém je uvedená identifikace uživatele (nějaké ID, login, e-mail apod.), může tam přidat další údaje jako třeba role uživatele a nastaví platnost tokenu třeba na 15 minut a celé to podepíše. REST server pak ověří podpis a časovou platnost toho tokenu a vytáhne si z něj potřebné údaje (např. ten login).

Hesla se na serveru nešifrují ale hashují, tj. z hashe nelze zpět získat původní heslo. Existují speciální hashovací funkce určené pro hesla, kterým tedy já osobně moc nevěřím, protože nejsou kryptograficky prověřené. Takže bych raději použil standardní SHA-256. Důležité je to, že se nehashuje samotné heslo, ale kombinace heslo+sůl+pepř. Sůl je nějaký náhodný text unikátní pro každé heslo a je uložený spolu s heslem. Pepř je také náhodný text, který ale vůbec není uložený v databázi, je někde v konfiguraci aplikace. Kdyby útočník získal databázi, nebude znát pepř a nemůže tedy zkoušet hesla hádat. Kdyby získal databázi i pepř, může zkoušet hesla hádat – zkusí nějaké heslo, k němu zná pepř i sůl, vypočítá hash a porovná ho s tím v databázi. Díky soli ale musí hádat každé heslo zvlášť. Když se nepoužije sůl ani pepř, může útočník použít tzv. duhové tabulky – tabulky, kde je ke spoustě hesel už vypočítaný hash. Pak mu stačí projít databázi a všechny uložené hashe hledat v těch duhových tabulkách. U jednoduchých hesel uspěje a získá tak hesla konkrétních uživatelů. Pokud byste chtěl o bezpečném ukládání hesel vědět víc, hodně o tom píše a přednáší Michal Špaček.

Co se týče SQL injection, takovou chybu musíte spíš pracně vyrobit – sám, nebo použitím nevhodného nástroje. SQL injection vzniká tak, že v programu skládáte ručně do textového řetězce SQL příkaz a jeho parametry. Třeba "SELECT * FROM table WHERE id = " + request.getId(). Když použijete JPA nebo Spring JDBCTemplate a parametry budete do SQL dotazů předávat pomocí mapování, SQL injection nemůže nastat (samozřejmě pokud není nějaká chyba v použitých knihovnách a nedělají to skládání řetězců interně v té knihovně).

Pro uživatelské role máte nejjednodušší použít Spring Security – poskytnete implementaci, která pro zadaného uživatele vrátí seznam jeho rolí, a pak už jenom stačí každou metodu REST controlleru označit anotací, ve které uvedete seznam rolí, které tu metodu smějí volat.

reklama


Re:Nápad na bakalářskou práci se Spring
« Odpověď #31 kdy: 28. 04. 2019, 12:39:47 »
Použít jen HTTPS (a z HTTP udělat jen přesměrování na HTTPS) je jen otázka konfigurace webového serveru. Autentizaci přihlášením klientským certifikátem přes HTTPS bych nedělal, podpora v prohlížečích je špatná. Ne že by to neodporovaly, ale UX je otřesné. Například Chrome vyžaduje od uživatele každých pár minut PIN k čipové kartě s uloženým certifikátem, pokud se používá TLS 1.3, protože dohodnutí nových parametrů TLS dělají opravdu důkladně až k té nové žádosti o PIN.

Pokud použijete jen jQuery, musíte si napsat sám spoustu věcí, které vám jinak poskytují ty frameworky. Angular je už dost velký framework, myslím, že by stačilo i něco lehčího – třeba Vue.js. Myslím, že se ho člověk naučí docela rychle a postará se za vás o ty dvě nejnudnější věci, které musíte pořád řešit v čistém JavaScriptu – propojení dat v JavaScriptovém objektu na HTML prvky (vstupní políčka formulářů a výstup) a spouštění akcí.

Pro autentizaci volání RESTových služeb jsem navrhoval použít protokol OAuth2, který k RESTovým požadavkům přidává JWT –JSON Web Token. V něm jsou zakódované údaje, které předal autentizační server, jsou jím podepsané a obvykle obsahují časovou značku. Autentizační server tedy vystaví JSON, ve kterém je uvedená identifikace uživatele (nějaké ID, login, e-mail apod.), může tam přidat další údaje jako třeba role uživatele a nastaví platnost tokenu třeba na 15 minut a celé to podepíše. REST server pak ověří podpis a časovou platnost toho tokenu a vytáhne si z něj potřebné údaje (např. ten login).

Hesla se na serveru nešifrují ale hashují, tj. z hashe nelze zpět získat původní heslo. Existují speciální hashovací funkce určené pro hesla, kterým tedy já osobně moc nevěřím, protože nejsou kryptograficky prověřené. Takže bych raději použil standardní SHA-256. Důležité je to, že se nehashuje samotné heslo, ale kombinace heslo+sůl+pepř. Sůl je nějaký náhodný text unikátní pro každé heslo a je uložený spolu s heslem. Pepř je také náhodný text, který ale vůbec není uložený v databázi, je někde v konfiguraci aplikace. Kdyby útočník získal databázi, nebude znát pepř a nemůže tedy zkoušet hesla hádat. Kdyby získal databázi i pepř, může zkoušet hesla hádat – zkusí nějaké heslo, k němu zná pepř i sůl, vypočítá hash a porovná ho s tím v databázi. Díky soli ale musí hádat každé heslo zvlášť. Když se nepoužije sůl ani pepř, může útočník použít tzv. duhové tabulky – tabulky, kde je ke spoustě hesel už vypočítaný hash. Pak mu stačí projít databázi a všechny uložené hashe hledat v těch duhových tabulkách. U jednoduchých hesel uspěje a získá tak hesla konkrétních uživatelů. Pokud byste chtěl o bezpečném ukládání hesel vědět víc, hodně o tom píše a přednáší Michal Špaček.

Co se týče SQL injection, takovou chybu musíte spíš pracně vyrobit – sám, nebo použitím nevhodného nástroje. SQL injection vzniká tak, že v programu skládáte ručně do textového řetězce SQL příkaz a jeho parametry. Třeba "SELECT * FROM table WHERE id = " + request.getId(). Když použijete JPA nebo Spring JDBCTemplate a parametry budete do SQL dotazů předávat pomocí mapování, SQL injection nemůže nastat (samozřejmě pokud není nějaká chyba v použitých knihovnách a nedělají to skládání řetězců interně v té knihovně).

Pro uživatelské role máte nejjednodušší použít Spring Security – poskytnete implementaci, která pro zadaného uživatele vrátí seznam jeho rolí, a pak už jenom stačí každou metodu REST controlleru označit anotací, ve které uvedete seznam rolí, které tu metodu smějí volat.

Děkuji.
Jednu věc nechápu. Bavíme se o autentizaci přes OAuth2 a k tomu by měl být i možný způsob autentizaci i normální, že? Jakože klasická registrace na straně té aplikace.
Řekněme, že se uživatel přihlásí přes FB. Jak to ted bude reálně fungovat? Řekněme, že tam bude prostě úvodní stránka, kde se danému člověku budou vypisovat nové události ze všech společenstev, ve kterých je členem.
Čili by byl dotaz na DB - "neco... WHERE user.id = X;" - nicméně když se přihlásí přes FB, tak jak tohle zjistím, když toho člověka vlastně fyzicky v databázi nemám, ne? Tak jak zjistím, do jakých společenstev se přidal, na jakých bude akcích atd, když ho fyzicky v databazi mít nebudu?

Re:Nápad na bakalářskou práci se Spring
« Odpověď #32 kdy: 28. 04. 2019, 12:43:59 »
Jo a ještě jedna věc...
U Rest Api jsem koukal, že je anotace @Secured(role) - jakým způsobem se přenáší ta role mezi springem a front endem? Uložená v jsonu nějak?

Re:Nápad na bakalářskou práci se Spring
« Odpověď #33 kdy: 28. 04. 2019, 13:38:41 »
Autentizace říká, kdo je přihlášený uživatel. Způsobů autentizace můžete mít několik vedle sebe. Jeden asi bude jménem a heslem – uživatel zadá na formuláři jméno a heslo, vy ho podle jména v databázi vyhledáte a ověříte heslo. Když použijete přihlašování přes třetí stranu (např. Facebook), při registraci si opět uložíte údaje o uživateli do databáze, pak ho necháte přihlásit se přes Facebook a Facebook vám vrátí nějaký (pro Facebook) unikátní identifikátor toho uživatele. A ten vy si uložíte k tomu uživatelskému profilu do databáze. Když se příště přihlásí přes Facebooku, Facebook vám zase vrátí to samé ID a podle toho vy si v databázi najdete, který je to uživatel. Takže v databázi budete mít nejspíš nějakou tabulku s uživatelským profilem (třeba jeho jméno, příjmení a e-mail), vedle toho jinou tabulku se jménem a heslem a další tabulku s ID z Facebooku. A k jednomu profilu můžete mít uložený jak záznam v tabulce se jménem a heslem, tak záznam v tabulce Facebooku – uživatel si pak může vybrat, kterou variantou se přihlásí.

HTTP je ale bezstavový protokol, tedy normálně by uživatel musel zadávat své jméno a heslo (nebo se přihlašovat přes Facebook) s každým požadavkem, který se pošle na server. To samozřejmě nikdo dělat nebude – místo toho server uživatele ověří jednou a na základě toho předá klientovi nějakou informaci, kterou pak klient posílá s každým dalším požadavkem. A podle ní server pozná, že jde o toho přihlášeného klienta. Dříve se to dělalo tak, že server přidělil přihlášenému uživateli nějaké unikátní číslo (nazývané třeba session ID), a někam si poznamenal, že tohle session ID je uživatel třeba Franta Novák. Pak session ID poslal klientovi a ten ho přidával jako cookie do každého dalšího požadavku na server. Server si podle toho session ID z cookie dohledal příslušný záznam a z něj si přečetl, že s tímhle session ID je přihlášený uživatel Franta Novák. To má tu nevýhodu, že musí být na serveru to úložiště session ID, takže můžete mít jenom jeden server, nebo – když jich máte víc – potřebujete mezi nimi sdílet to úložiště session ID.

A tady do toho vstupuje ten OAuth2 protokol. Místo toho, aby si server poznamenával session ID, tak vytvoří elektronický dokument (ve formátu JSON), který říká „přihlášený uživatel je Franta Novák“, a případně k tomu doplní další údaje. A tenhle dokument elektronicky podepíše a pak ho i s tím podpisem předá klientovi. Klient pak ke každému požadavku nepřidává session ID, ale tenhle elektronicky podepsaný dokument, kterému se říká (autentizační) token (ve skutečnosti je velmi krátký, desítky znaků). Když ho dostane server, ověří ten podpis, a pokud sedí, ví, že může důvěřovat té informaci „přihlášený uživatel je Franta Novák“. Tím pádem si server nemusí pamatovat žádné session ID, ale i když budete mít 80 serverů po celém světě, pokud bude každý z nich umět ověřit ten elektronický podpis, dokáže bezpečně zjistit, že jde o toho správného uživatele.

Ve vašem případě je pro tu autentizaci REST požadavků OAuth2 trochu kanón na vrabce, ale je to průmyslový standard, se kterým umí zacházet spousta knihoven a frameworků. A Spring už má podporu v sobě, takže nemusíte nic implementovat, jenom to nakonfigurujete. V dokumentaci Springu Spring Security Reference jsou ty varianty použití OAuth2 popsané.

Druhá věc je, že OAuth2 se používá i přitom přihlašování třeba přes Facebook, ale to s tou autentizace REST požadavků nesouvisí. Vlastně byste tam měl OAuth2 použité na dvou nesouvisejících místech – pro přihlášení přes Facebook a pro autentizaci REST požadavků.

Aby vám fungovala anotace @Secured(role), musíte implementovat rozhraní UserDetailsService, kde je metoda, která vrací uživatele a jeho role. Ve vašem případě je nejjednodušší podle předaného identifikátoru si uživatele dohledat v databázi a z ní načíst i odpovídající role.

S OAuth2 by se to dalo udělat i tak, že se ty role načtou při přihlášení uživatele a přidají se do toho autentizačního tokenu, který se pak posílá s každým požadavkem. Díky tomu podpisu pak server ví, že tomu seznamu rolí může důvěřovat. To se ale používá spíš v případech, kdy máte oddělený server, který dělá autentizaci, a server, který poskytuje vlastní služby. Ten server pak nemusí vědět nic o uživatelích, prostě se jenom řídí tím, co je v tom tokenu.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #34 kdy: 28. 04. 2019, 14:38:41 »
Mockrát Vám děkuji. Ta Vaše vysvětlení jsou pro mě (jako člověka, co s tím nikdy nepracoval) velmi pochopitelná. Čili navrhujete: Aby REST api bylo zabezpečené přes Oauth2 - tím způsobem, jak jste popisoval. Čili na serveru se vytvoří nějaký elektronický dokument podepsaný, který pošle na klienta a ověřuje ho podle podpisu. A FB/Google přihlášení byste do toho nedoporučoval? Že jste psal, že se bude míchat Oauth2 na dvou nesouvislých místech? A pokud by se mi podařilo do té aplikace toto implementovat + to hashování hesla + ty role, tak by to dle Vás bylo bezpečnostně v pořádku? Samozřejmě ještě nevím, co s tím https potom...


Re:Nápad na bakalářskou práci se Spring
« Odpověď #35 kdy: 29. 04. 2019, 09:32:21 »
Mockrát Vám děkuji. Ta Vaše vysvětlení jsou pro mě (jako člověka, co s tím nikdy nepracoval) velmi pochopitelná.
Děkuji. Pro mne je to důležitá informace, že to vysvětlování má smysl a že to je srozumitelné. Abych si tu jen tak nepsal něco, čemu z 90 % nebude rozumět :-)

Čili navrhujete: Aby REST api bylo zabezpečené přes Oauth2 - tím způsobem, jak jste popisoval. Čili na serveru se vytvoří nějaký elektronický dokument podepsaný, který pošle na klienta a ověřuje ho podle podpisu.
Ano. Ten dokument, který se používá v OAuth2 protokolu, se nazývá JWT – JSON Web Token. Jeho generování a ověřování nebudete implementovat, ve Springu už jsou knihovny, které to implementují. Vy to musíte jen nakonfigurovat (jaké klíče se mají použít apod.) a implementovat věci, na kterých to generování a ověřování závisí. Např. když se uživatel přihlásí jménem a heslem, Spring zavolá vaší službu, které předá to jméno a heslo, vy implementujete vyhledání uživatele v databázi, ověření hesla a zjištění dalších údajů o uživateli (třeba jeho plné jméno a role) a tyhle údaje vrátí vaše služba Springu, a ten už z toho ten JWT vyrobí.

A FB/Google přihlášení byste do toho nedoporučoval? Že jste psal, že se bude míchat Oauth2 na dvou nesouvislých místech?
Že se to bude míchat na dvou místech bylo myšleno tak, aby vás nemátlo, že se ten protokol může v té aplikaci použít dvěma způsoby, které spolu nijak nesouvisí. Je spoust aplikací, které používají OAuth2 pro zabezpečení svých REST služeb, a přihlášení přes FB  nebo Google neimplementují. A naopak je spousta aplikací, které implementují přihlášení přes FB nebo Google, ale jiným způsobem OAuth2 nepoužívají.

Já osobně bych doporučoval v takové aplikaci mít implementované přihlášení minimálně přes FB, Google, MojeID a asi i Twitter, protože zejména u aplikací, které používám jen občas, je otravné přihlašovat se jménem a heslem. A to používám správce hesel, takže pro mne je to přihlášení jednodušší, než pro většinu lidí, kteří si musí nějaké heslo vymyslet a pak si ho pamatovat. Ale to přihlášení přes systémy třetích stran je volitelná funkce, dá se doplnit kdykoli později – spíš je to další funkce, kterou můžete přidat, když se budete chtít naučit něco dalšího.

A pokud by se mi podařilo do té aplikace toto implementovat + to hashování hesla + ty role, tak by to dle Vás bylo bezpečnostně v pořádku? Samozřejmě ještě nevím, co s tím https potom...
Z hlediska autentizace by to mělo být v pořádku, protokoly, o kterých se bavíme, jsou prověřené, implementace použitá ve Springu pokud vím nemá žádné známé bezpečnostní problémy. Jinak je ale potřeba bezpečnost řešit u každé části aplikace, nedá se říct, že by aplikace použitím nějaké technologie byla bezpečná. Vždy musíte počítat např. s tím, že uživatel v prohlížeči sice může zadat např. jen číslo, ale schopnější uživatel si umí z prohlížeče ten JWT vytáhnout a zavolá tu vaší RESTovou službu jinak, a místo čísla tam dá text nebo ho nevyplní vůbec. Aplikace v takovém případě má vypsat chybu ale hlavně nesmí udělat žádnou operaci, na kterou uživatel nemá oprávnění.

Aplikace ve Springu se myslím většinou nevystavují přímo do internetu – obvykle tam bývá předřazený proxy server (třeba Nginx). Na tom předřazeném serveru se nakonfiguruje HTTPS (a přesměrování z HTTP na HTTPS), ten proxy server pak už může komunikovat se Springovou aplikací nešifrovaným HTTP – běží buď na stejném serveru nebo ve stejné síti. A i kdyby ta Springová aplikace měla (sama) běžet přes HTTPS, je to jen otázka konfigurace, té aplikace se to nijak nedotkne. Ve frontendové části aplikace se HTTPS vyřeší ještě snadněji, tam jde jenom o to v URL pro volání RESTových služeb použít protokol https a ne http. A samozřejmě je potřeba i tu frontendovou aplikaci servírovat ze serveru přes HTTPS – u malé aplikace to může dělat ten samý server, který dělá proxy server té backendové Springové aplikaci. Tj. pak máte třeba Nginx server, na něm je nakonfigurované HTTPS a s tím serverem komunikuje webový prohlížeč. Ten Nginx jednak poskytuje (statické) soubory frontendové aplikace, a jednak určité URL (třeba https://example.com/api/*) přeposílá na tu backendovou aplikaci ve Springu.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #36 kdy: 10. 05. 2019, 12:12:24 »
Mockrát Vám děkuji. Ta Vaše vysvětlení jsou pro mě (jako člověka, co s tím nikdy nepracoval) velmi pochopitelná.
Děkuji. Pro mne je to důležitá informace, že to vysvětlování má smysl a že to je srozumitelné. Abych si tu jen tak nepsal něco, čemu z 90 % nebude rozumět :-)

Čili navrhujete: Aby REST api bylo zabezpečené přes Oauth2 - tím způsobem, jak jste popisoval. Čili na serveru se vytvoří nějaký elektronický dokument podepsaný, který pošle na klienta a ověřuje ho podle podpisu.
Ano. Ten dokument, který se používá v OAuth2 protokolu, se nazývá JWT – JSON Web Token. Jeho generování a ověřování nebudete implementovat, ve Springu už jsou knihovny, které to implementují. Vy to musíte jen nakonfigurovat (jaké klíče se mají použít apod.) a implementovat věci, na kterých to generování a ověřování závisí. Např. když se uživatel přihlásí jménem a heslem, Spring zavolá vaší službu, které předá to jméno a heslo, vy implementujete vyhledání uživatele v databázi, ověření hesla a zjištění dalších údajů o uživateli (třeba jeho plné jméno a role) a tyhle údaje vrátí vaše služba Springu, a ten už z toho ten JWT vyrobí.

A FB/Google přihlášení byste do toho nedoporučoval? Že jste psal, že se bude míchat Oauth2 na dvou nesouvislých místech?
Že se to bude míchat na dvou místech bylo myšleno tak, aby vás nemátlo, že se ten protokol může v té aplikaci použít dvěma způsoby, které spolu nijak nesouvisí. Je spoust aplikací, které používají OAuth2 pro zabezpečení svých REST služeb, a přihlášení přes FB  nebo Google neimplementují. A naopak je spousta aplikací, které implementují přihlášení přes FB nebo Google, ale jiným způsobem OAuth2 nepoužívají.

Já osobně bych doporučoval v takové aplikaci mít implementované přihlášení minimálně přes FB, Google, MojeID a asi i Twitter, protože zejména u aplikací, které používám jen občas, je otravné přihlašovat se jménem a heslem. A to používám správce hesel, takže pro mne je to přihlášení jednodušší, než pro většinu lidí, kteří si musí nějaké heslo vymyslet a pak si ho pamatovat. Ale to přihlášení přes systémy třetích stran je volitelná funkce, dá se doplnit kdykoli později – spíš je to další funkce, kterou můžete přidat, když se budete chtít naučit něco dalšího.

A pokud by se mi podařilo do té aplikace toto implementovat + to hashování hesla + ty role, tak by to dle Vás bylo bezpečnostně v pořádku? Samozřejmě ještě nevím, co s tím https potom...
Z hlediska autentizace by to mělo být v pořádku, protokoly, o kterých se bavíme, jsou prověřené, implementace použitá ve Springu pokud vím nemá žádné známé bezpečnostní problémy. Jinak je ale potřeba bezpečnost řešit u každé části aplikace, nedá se říct, že by aplikace použitím nějaké technologie byla bezpečná. Vždy musíte počítat např. s tím, že uživatel v prohlížeči sice může zadat např. jen číslo, ale schopnější uživatel si umí z prohlížeče ten JWT vytáhnout a zavolá tu vaší RESTovou službu jinak, a místo čísla tam dá text nebo ho nevyplní vůbec. Aplikace v takovém případě má vypsat chybu ale hlavně nesmí udělat žádnou operaci, na kterou uživatel nemá oprávnění.

Aplikace ve Springu se myslím většinou nevystavují přímo do internetu – obvykle tam bývá předřazený proxy server (třeba Nginx). Na tom předřazeném serveru se nakonfiguruje HTTPS (a přesměrování z HTTP na HTTPS), ten proxy server pak už může komunikovat se Springovou aplikací nešifrovaným HTTP – běží buď na stejném serveru nebo ve stejné síti. A i kdyby ta Springová aplikace měla (sama) běžet přes HTTPS, je to jen otázka konfigurace, té aplikace se to nijak nedotkne. Ve frontendové části aplikace se HTTPS vyřeší ještě snadněji, tam jde jenom o to v URL pro volání RESTových služeb použít protokol https a ne http. A samozřejmě je potřeba i tu frontendovou aplikaci servírovat ze serveru přes HTTPS – u malé aplikace to může dělat ten samý server, který dělá proxy server té backendové Springové aplikaci. Tj. pak máte třeba Nginx server, na něm je nakonfigurované HTTPS a s tím serverem komunikuje webový prohlížeč. Ten Nginx jednak poskytuje (statické) soubory frontendové aplikace, a jednak určité URL (třeba https://example.com/api/*) přeposílá na tu backendovou aplikaci ve Springu.

Zdravím,
a jak to ještě funguje s CSRF? Řekněme, že bych použil Oauth2 k zabezpečení těch REST služeb. CSRF hrozí? Případně mu předpokládám je vhodné nějakým způsobem zamezit?

Děkuji

Re:Nápad na bakalářskou práci se Spring
« Odpověď #37 kdy: 10. 05. 2019, 19:53:47 »
a jak to ještě funguje s CSRF? Řekněme, že bych použil Oauth2 k zabezpečení těch REST služeb. CSRF hrozí? Případně mu předpokládám je vhodné nějakým způsobem zamezit?
CSRF spočívá v tom, že v okamžiku, kdy je uživatel přihlášen do aplikace, přinutíte prohlížeč, aby poslal platný požadavek včetně autentizačních údajů. To funguje například tehdy, když je přihlášený uživatel identifikován pomocí cookie – prohlížeč ji přibalí automaticky k požadavku, i když byl požadavek odeslán z jiné webové stránky. Při použití OAuth2 se ale autentizační token obvykle posílá v hlavičce Authorization a o jeho přiložení se musí postarat ten kód, který tu RESTovou službu volá – tj. nedělá to prohlížeč automaticky. Tedy případný útočník by musel autentizační token také připojit k požadavku ručně – ale to by jej nejprve musel získat. Pokud bude uložený např. jen v JavaScriptové aplikaci na klientovi, tak token získat nemůže (pokud v té aplikaci není speciální kód, který by to umožnil). Případně může být ten token uložen v Session Storage nebo Local Storage – ty jsou vázané na doménu, takže útočící skript z jiné domény se k nim nedostane. Nicméně pokud by pod jednou doménou běželo několik aplikací, ty už by si mohly navzájem číst Session Storage nebo Local Storage. Ale pokud poběží víc aplikací pod jednou doménou, těch způsobů, jak se navzájem ovlivnit, je mnoho – takže bych buď počítal s tím, že na dané doméně bude aplikace samotná, a nebo tam budou jen důvěryhodné aplikace.

Re:Nápad na bakalářskou práci se Spring
« Odpověď #38 kdy: 11. 05. 2019, 00:02:24 »
Děkuji.
Čili za předpokladu, že budu používat Oauth2 pro ty rest api, budu mít aplikaci, kdy bude jeden server a jakože "jeden" front end, tak k CSRF nemůže dojít, pokud ten token bude prostě uložený někde v JS kodu na klientovi. Je to takto správně? Já jsem
A existují nějaké útoky přímo na ten Oauth2, na který bych si měl dát pozor?

Re:Nápad na bakalářskou práci se Spring
« Odpověď #39 kdy: 11. 05. 2019, 08:59:53 »
Ano, pokud ten token bude uložen v JS aplikaci na frontendu, z pohledu CSRF je to bezpečné – útočník se k tokenu nemůže dostat a prohlížeč ho neposílá automaticky, tj. požadavek s validním tokenem nemůže odejít jinak, než přímo z vaší aplikace.

Pokud se OAuth2 implementuje podle aktuálních doporučení, žádný známý útok mne nenapadá. Jedině to, že u Single Page Aplikací (SPA) se dříve doporučovalo u autentizace přes OAuth2 implicit flow, dnes už se doporučuje provést i v tomhle případě standardní získání tokenu. Celý proces přihlášení přes OAuth2 je odbře popsán teřba v OAuth 2 Simplified a jsou tam i odkazy na aktuální doporučení.

 

reklama