Security w Single Page Application

Witam,
próbuje zrobić security dla aplikacji typu SPA i się trochę zakręciłem. Chciałem użyć OAuth2 lub/i JWT. Jednak mam problem z przechowywaniem tokenów ponieważ z przeglądarki każdy może dostać się do tokena. Dostaje się do tokena kopiuje go i już mogę robić requesty do serwera. Czy istnieje jakiś sposób, aby zabezpieczyć się przed "kradzieżą" tokena?

Nie wiem co robisz do końca. (implementujesz OUATH2?)
Ale popatrz np. na zabezpieczanie COOKIE (klasyczne) - z przeglądarki każdy może odczytać COOKIe i już robić requesty do serwera...

A może korzystasz z serwisu Oauth2 - wtedy patrz "implicit flow".

Nie implementuje OAuth2. "Implicit flow" też Ci nic nie daje bo musisz podać ClientId.

Chodzi mi o to w jaki sposób przechowywać tokeny (ewentualnie inne dane jak np. clientId czy clientSecret) po stronie klienta, tak żeby osoby trzecie nie mogły ich odczytać i użyć.

Kozy napisał(a):

Jednak mam problem z przechowywaniem tokenów ponieważ z przeglądarki każdy może dostać się do tokena. Dostaje się do tokena kopiuje go i już mogę robić requesty do serwera.

Jeśli chodzi o przegląrkę to nie ma znaczenia, że ktoś ma dostęp do tokena skoro jest same origin policy. W skrócie, jeśli skrypt, który chce zrobić request na Twój serwer pochodzi z innej domeny, przeglądarka mu na to nie pozwoli.

edit
@Shalom w komentarzu słusznie zauważył że SOP można omijać, ale mógł chociaż wspomnieć, że przed CSRF można się bronić, przykłady z django np https://docs.djangoproject.com/en/dev/ref/csrf/. To pewnie też da się obejść, albo znaleźć exploit co sprowadza się do konkluzji, że jak dobry cracker się na Ciebie uprze to i tak Cie dojedzie prędzej czy później.

Generalnie nie można polegać na jednej warstwie, oauth2 ma znane problem, które są opisane chyba nawet w jakimś RFC.

@Kozy ClientID nie jest tajne! Czyli implicit flow -> po to powstał, żeby w przeglądarce dało się użyć (pytanie czy twój provider to wspiera).
A korzystający z przeglądarki zawsze da radę je sobie token wyciągnąć. Tylko, że dlaczego to niby ma być problem?
Zalogowałem się do Twittera z twojej aplikacji.. i co? Teraz sobie swojego tokena podejrze... to nie jest dramat.

http://oauthlib.readthedocs.io/en/latest/oauth2/grants/implicit.html

@jarekr000000 ale jak odejdziesz od przeglądarki i ktoś albo coś innego dostanie się np. do localStorage/sessionStorage (może to nie najlepsze miejsce zapisywania tokena, podałem tak przykładowo) gdzie jest zapisany token to może Ci namieszać w Twoich zasobach.

Providerem jestem ja, tzn. moja aplikacja i tutaj sobie mogę manipulować. Moją pierwszą myślą było użycie grant_type=password ze względu na frontend - nie ma zbędnych przekierowań. Tylko mam problem z trzymaniem tych wszystkich danych (clientId, clientSecret, token, refresh_token) w przeglądarce. Myślałem, żeby zrobić sobie jakieś cienkie proxy, gdzie można byłoby trzymać te dane (lub część danych - tylko clientId i clientSecret), nie wiem czy to jest dobry pomysł.

Jeszcze ogarniam JWT i może to będzie lepsza droga? Tylko tam znowu pojawia się ten sam problem.

Kozy napisał(a):

@jarekr000000 ale jak odejdziesz od przeglądarki i ktoś albo coś innego dostanie się np. do localStorage/sessionStorage (może to nie najlepsze miejsce zapisywania tokena, podałem tak przykładowo) gdzie jest zapisany token to może Ci namieszać w Twoich zasobach.

@Kozy - jak odejdziesz od przeglądarki to ktoś może Ci zainstalować piękne rezszerzenie, keylogera itp. Trudno Ci się będzie przed wszystkim obronić.

Sam token najlepiej nie przechowuj w localStorage tylko jak var wewnątrz modułu JS - trudno jest się do tego dostać. Do tego jeśli ustawianie tokena zrobisz automatycznie hookiem (podmiana) XMLHttpRequest.prototype.open
to nie tak łatwo będzie się do niego dostać (musisz sprawdzać tylko Czy ktoś jeszcze nie przejął 'open'... (Poprawka: hmm nie wiem czy to może być skuteczne - jak ktoś najpierw podmieni 'open' - to chyba nie dasz rady sprawdzić, że to obcy kod)).
Wtedy na pewno wydostanie tokena będzie trudne nawet jak ktoś Ci zrobi XSS.

Ale jak ktoś ma fizyczny dostęp do przeglądarki to sorry... Nie wiem co wtedy można zrobić i czy jest praktyczny sens?

Dobra, faktycznie chyba za dużo chcę zrobić.

@Kozy jak ktoś ma fizyczny dostęp do maszyny to maszyna jest skompromitowana. Pozostaje mieć nadzieję, że kiedyś może przeglądarki będą używać np. SGXa do przechowywania wrażliwych zasobów, ale trochę potrwa zanim to nastąpi, jeśli w ogóle.