Alternatywa dla session scope beanów

0

Session scope beany mają złą sławę (słusznie raczej), ale nachodzi mnie myśl że czasami trudno je zastąpić. Np. jak zastąpić beana sesyjnego jeśli chcemy mieć koszyk w sesji? Przecież zawsze się będzie to tego sprowadzało że będzie jakis globalny obiekt

@jarekr000000 @Wibowit jestem ciekaw jak wy byście to zrobili :)

2

Koszyk i tego typu rzeczy trzymam normalnie po stronie klienta (SPA).
To, że jest zalagowany dostaje klient w postaci jakiegoś podpisanego tokena (np. jak w JWT).

I to załatwia wiele problemów.

Poza tym oczywiście mam jakieś obiekty perzystentne. Czy one sa w bazie, event storze, czy siedzą wprost w jakiejś mapie globalnej dla danej instancji - to już szczegół implementacyjny.
To po prostu stan aplikacji. Jakkolwiek nie pamiętam, żebym taki globalny stan trzymał w zmiennej de facto statycznej (chyba, że bardzo dawno temu).
(czyli globalność jest tylko logiczna).

0

czy siedzą wprost w jakiejś mapie globalnej dla danej instancji - to już szczegół implementacyjny.

@jarekr000000: Chodzi o instancję aplikacji? Np. ConcurrentMap<Jakiś Token, Koszyk> ?

0

Beany sesyjne, czyli ThreadLocale podpięte do wątku sesji wykrzaczają się już przy pierwszym Futurze/ CompletionStage, które to działają sobie w innych wątkach. No chyba, że teraz jakoś inaczej te beany działają, ale nie wydaje mi się. Obsługa sesji zależy od frameworka. Framework może dostarczać wspomniane ThreadLocale i sesje przypięte do wątków, ale może zamiast tego np udostępniać sesję jako obiekt wprost.

Ogólnie jeśli frontend masz naklepany w jakimś frameworku SPA typu Angular, React, Vue itd to nie ma przeszkód by pchać koszyk na frontend, tak samo jak wszystkie inne dane sesyjne. Zwiększy to zdecydowanie skalowalność aplikacji, bo lekkie sesje nie będą tak mocno rozpychać pamięci na serwerze tak jak ciężkie sesje, a ponadto gdy zechcesz odpalić kilka instancji serwera to nie będziesz musiał synchronizować sesji między instancjami serwera bądź przypinać użytkownika do instancji serwera.

Swoją drogą to JWT + ich podpisywanie nie jest zamiennikiem dla typowych sesji opartych o ciasteczka + stan na serwerze. Ciasteczek i tak musisz używać, bo to jedyne bezpieczne rozwiązanie webowe, które jest wygodne dla użytkownika. HTML5 Web Storage nie jest bezpieczne, a jeżeli zrezygnujemy zarówno z ciasteczek jak i Web Storage to użytkownik za każdym przeładowaniem strony będzie musiał się logować. Zarządzanie sesjami po stronie serwera jest potrzebne, by móc te sesje zamykać. Nawet w Coyote jest opcja "wyloguj ze wszystkich innych sesji". U mnie w banku w aplikacji jest np wymóg, by dany użytkownik mógł być zalogowany tylko w jednej sesji jednocześnie - bez zarządzania sesjami po stronie serwera tego nie zaimplementujesz.

JWT można jednak użyć jako ciasteczka zamiast zwykłego identyfikatora sesji. Wtedy w JWT może być zawarty zarówno identyfikator sesji jak i identyfikator (np login) użytkownika (całość oczywiście zaszyfrowana i z podpisem). Potem identyfikatory żyjących sesji wrzucasz do Redisa i masz skalowalną i bezpieczną apkę.

Jeśli nie możesz przenieść stanu sesyjnego na stronę użytkownika to i tak w praktyce musisz iść na jakieś kiepskawe kompromisy, więc rozwiązanie nie będzie ani eleganckie ani przyjemne w kodowaniu.

0
Wibowit napisał(a):

Swoją drogą to JWT + ich podpisywanie nie jest zamiennikiem dla typowych sesji opartych o ciasteczka + stan na serwerze. Ciasteczek i tak musisz używać, bo to jedyne bezpieczne rozwiązanie webowe, które jest wygodne dla użytkownika.

Z jednek strony Cookies mają HttpOnly (co daje przewagę nad tokenem trzymanym w local storage). Z drugiej strony za to trzeba się uzbrajać przeciwko CSRF. Trzeba się postarać, żeby były w miarę bezpieczne.

scibi92 napisał(a):

@jarekr000000: Chodzi o instancję aplikacji? Np. ConcurrentMap<Jakiś Token, Koszyk> ?

new MySerwer( sate = new MyState(), port = 8080);

0

Z jednek strony Cookies mają HttpOnly (co daje przewagę nad tokenem trzymanym w local storage). Z drugiej strony za to trzeba się uzbrajać przeciwko CSRF. Trzeba się postarać, żeby były w miarę bezpieczne.

Do ciasteczek jest już szereg dobrze przetestowanych i udokumentowanych gotowców (z zabezpieczeniami przeciwko CSRF też). Za pomocą samych JWT + Web Storage nie osiągniesz takiego bezpieczeństwa jak przy dobrze zaimplementowanych ciasteczkach. Z tego powodu ciasteczka dalej są i będą standardem w bankowości, kontach Google, Facebooka, itd

Same JWT (bez ciastek) mają sens po stronie backendu, do komunikacji między mikroserwisami na przykład. Na frontendzie lepiej zostać przy ciastkach.

0

Istnieją jakieś automatyczne zabezpieczenia przed CSRF które nie padają od XSS? Z tego co się orientuje jak strona jest podatna na XSS to nie ma różnicy między cookie http only a jwt token zapisany w local storage, i tak i tak atakujący może wykonać request używając poświadczeń użytkownika.

A google i facebook używają ciasteczek głównie ze względu na możliwość śledzenia użytkowników w internecie, z tokenem nie byłoby to możliwe na taką skale ....

0

A google i facebook używają ciasteczek głównie ze względu na możliwość śledzenia użytkowników w internecie, z tokenem nie byłoby to możliwe na taką skale ....

Ciasteczka od logowania są chyba oddzielne od ciasteczek od śledzenia. Można się wylogować z G, FB, itd a dalej być śledzonym.

0
neves napisał(a):

Istnieją jakieś automatyczne zabezpieczenia przed CSRF które nie padają od XSS? Z tego co się orientuje jak strona jest podatna na XSS to nie ma różnicy między cookie http only a jwt token zapisany w local storage, i tak i tak atakujący może wykonać request używając poświadczeń użytkownika.

Raczej nie ma dowodu, że istnieją takie, że nie padają :-) . Ale istnieją dość bezpieczne, które nawet przy XSS trudno złamać.
(token jest aplikowany na ajax handlerze, nie ma żadnego dostępu do niego przez zmienne globalne itp).
Do tego trzeba dodać same site cookie, csp, hsts i można mieć duży poziom bezpieczeństwa, Jakkolwiek większość programistów chyba nawet nie wie co to jest.

0

Istnieją jakieś automatyczne zabezpieczenia przed CSRF które nie padają od XSS?

Losowy CSRF token generowany przy każdym GET + Single Origin Policy zwykle wystarczy bo w zasadzie nie ma jak exfiltrować za bardzo tokena. Do tego CSP i robi się niewiele miejsca do ataku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1