Lucrez la o aplicatie cu AngularJS, si am niste dubii din punct de vedere al securitatii din moment ce pot vedea token-ul in developer toolbar de la chrome, acesta este generat de Rest API la login, stocat pe sessionStorage de HTML5 si folosit apoi de toate request-urile client side din browser ca element de autorizare. Exista vreo alta solutie de a stoca token-ul sa nu fie vizibil sau o alta modalitate de a schimba partea de securitate, avand in vedere ca nu pot schimba Rest API, care e legacy, si trebuie sa implementez modelul cu token-ul de autorizare.
Un link interesant pe tema asta Where to Store Your JWTs - Cookies vs HTML5 Web Storage, oricum merita luata in considerare si varianta cookies cu Secure flag.
Chiar ieri am ascultat un episod de podcast in care s-a vorbit putin de json web token, care l-ai putea folosi.
Uite episodul din The Web Platform Podcast.
Au vorbit de JWT (Json Web Token) ca in articolul de mai sus, dar nu au vorbit despre html5 storage vs cookies. Eu ti-as recomanda cookies.
1 Like
Raspunsul este, depinde.
- REST API-ul ce arhitectura de autorizare are OAuth 1/2, altceva?
- Cu acelasi token se pot face mai multe request-uri valide?
1 Like
@adavidoaiei: pana la urma ce decizie ai luat?
Intreb, ca mi se parea interesanta ideea de httpOnly cookie (in sensul ca nu poate fi cititi de js), dar inteleg ca nu toate browserele implementeaza la fel (http://resources.infosecinstitute.com/cookies-httponly-flag-problem-browsers/)
Am stocat token in cookie folosind API-ul de manipulare cookie din angularjs fara httpOnly (urmeaza sa mai studiez), am citit putin si despre OAuth 1/2 dar nu am inteles pe deplin si de aceea nu i-am raspuns lui @navaru, iar legat de a doua intrebare a lui @navaru se pot face mai multe request-uri valide cu acelas token.
inca doua intrebari:
- faci refresh la token, si daca da cum? sau tii tokenul valid pentru mult timp?
- mai faci si o logare serverside pentru aplicatia care serverste js-ul/html-ul?
1.) Din pacate nu fac refresh la token, acesta e folosit pe parcursul unei sesiuni login, logout.
2.) Aplicatia web este formata din fisiere HTML pure cu AngularJS fara cod server side PHP, .NET, logica e in JavaScript si foloseste un serviciu REST, deci nu am logare server side din aplicatia care serveste js-ul/html-ul.
1 Like
1). asta inseamna ca ii dai un time to live foarte mare corect?
2). asta inseamna ca am acces la js-ul tau fara login si pass. Corect?
1 Like
1.) Corect, e o rescriere a unei aplicatii mai vechi, doar partea de front end, back end REST API ramane cel initial, neatins, cu life cycle de token expus mai sus, am citit de modelul de token cu refresh pare interesanta ideea dar nu e implementata.
2.) Da are acces la js fara login si pass, dar nu vad o problema in asta deocamdata, daca e vreo bresa de securitate in asta poti sa imi spui. Eu am propus o combinatie ASP.NET MVC cu AngularJS dar mi-a fost refuzata propunere, deoarece nu s-ar scala la fel de bine, ca e mai bine sa mut logica pe client in javascript plus ca dupa modelul asta ruleaza si pe server cu linux, nu doar windows, ceea ce ar scadea costurile.
1 Like
- Nu vad problemele de securitate . Teoretic, daca folosesti cookie nici nu mai ai nevoie de logare serverside, caci tu cand faci request la html, trimiti catre server token-ul (daca cookiul e setat pentru acel domeniu) - si poti face ulterior o verificare (in .net, php,etc) atunci cand “scuipi” html-ul.
- Vad o problema de securitate aici , faptul ca nu face logout decat atcunci cand da el logout, fie atunci cand
1 Like
1.) Da e o problema cu token-ul, ar trebui modificata partea de life cycle la token, el expira intr-un anumit numar de ore daca nu da logout.
2.) Ce spuneam nu scuip HTML din PHP, .NET, ci e returnat fisierul plain HTML de pe server, e Single Page Application cu AngularJS.
O librarie javascript pentru manipulare cookies:
poti seta cookies secure si pe domeniu:
// Setting cookies with additional options
Cookies.set('key', 'value', { domain: 'www.example.com', secure: true });