Stockage inadapté du token de session (non sécurisé)

[thibaut-decherit]

J'ai déduit que le token de session était inpact-token étant donné qu'en le supprimant ça me déconnecte. Si je fais erreur, ne pas tenir compte de cette issue.

Le token de session inpact-token est stocké en local storage. Le local storage n'est PAS adapté pour le stockage de données sensibles/privées/confidentielles car il est accessible à TOUT JavaScript exécuté sur la page, rendant possible le vol de son contenu par exemple en cas de XSS, ou si du code malveillant se retrouve dans une librairie que vous utilisez.

C'est d'autant plus un problème que vous n'avez pas de Content Security Policy pour limiter par exemple vers quels domaines le JS présent sur vos pages peut envoyer des données (via la directive connect-src) : ainsi, du JS malveillant pourrait lire le token de session et le faire fuiter vers un domaine tiers via une requête AJAX. Dans la même veine, du JS malveillant pourrait faire une "fausse" requête GET vers un domaine tiers en attachant le token de session à l'URL. Par exemple en ajoutant au DOM :

• une "fausse" image (serait bloqué par la directive CSP img-src)
• un "faux" script (serait bloqué par la directive CSP script-src)
• une "fausse" feuille de style (serait bloqué par la directive CSP style-src)
• une "fausse" police (serait bloqué par la directive CSP font-src)

Voire via une requête POST en modifiant l'attribut action d'un formulaire déjà présent sur le site (serait bloqué par la directive CSP form-action). Bref, vous saisissez l'idée !

Il est préférable de stocker un token d'authentification dans un cookie avec le flag HttpOnly, car le navigateur refusera au JS l'accès aux cookies ayant ce flag. Le bonus étant que vu que c'est un cookie, le navigateur se chargera nativement de l'envoyer avec les requêtes, donc ce n'est pas un problème de ne pas pouvoir y accéder en JS. A moins que vous deviez envoyer ce cookie à un autre domaine que celui qui l'a créé, mais ça a l'air d'être destiné (entre autre ?) au sous-domaine api-v1.nextinpact.com donc ça devrait le faire avec les bons réglages au moment de la création.

D'ailleurs vous semblez passer ce token dans des URLs, comme https://api-v1.nextinpact.com/notifications/negotiate?signalrtoken=, c'est pas super propre de faire de l'auth via l'URL... Peut-être un problème de conception de ce côté.

Pour aller plus loin concernant le local storage (et la CSP) :

• 3e point de https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage
• https://www.zataz.com/un-code-java-permet-de-pieger-des-boutiques-dans-le-monde-et-en-france/, https://www.zataz.com/attaque-bancaire-a-lencontre-de-plusieurs-boutiques-francaises/ et https://www.zataz.com/le-geant-de-commerce-americain-macy-pirate/
• https://www.clearskysec.com/magecart/
• https://scotthelme.co.uk/hardening-payment-forms-with-csp/
• https://www.troyhunt.com/the-javascript-supply-chain-paradox-sri-csp-and-trust-in-third-party-libraries/
• https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

[Exagone313]

De plus, à propos de JWT :

• http://cryto.net/%7Ejoepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
• http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

[pehadavid]

@thibaut-decherit merci, je vais étudier tout ça. En soit je comprends tout à fait la crainte et la faille potentielle et ça mérite vraiment de se pencher sur le sujet. Si tout cela est pertinent, on switchera vers un stockage sur un cookie.