Le stockage local peut-il jamais être considéré comme sûr ?

Question

On me demande de développer une application web qui fonctionnera hors ligne pendant de longues périodes. Pour que cela soit viable, je ne peux éviter de sauvegarder des données sensibles (des données personnelles, mais pas le genre de données que vous ne feriez que hacher) dans le stockage local.

Je reconnais que ce n'est pas une pratique recommandée, mais n'ayant guère le choix, je fais ce qui suit pour sécuriser les données :

• chiffrer tout ce qui entre dans le stockage local en utilisant la bibliothèque cryptographique javascript de stanford et AES-256
• le mot de passe de l'utilisateur est la clé de chiffrement et n'est pas stocké sur l'appareil
• diffusion de tout le contenu (lorsqu'il est en ligne) à partir d'un seul serveur de confiance via ssl
• validation de toutes les données allant et venant du stockage local sur le serveur en utilisant le projet owasp antisamy
• dans la section réseau de l'appcache, sans utiliser *, et en listant seulement les URIs nécessaires à la connexion avec le serveur de confiance.
• en général, essayer d'appliquer les directives suggérées dans l'aide-mémoire XSS de l'OWASP.

Je suis conscient que le diable se cache souvent dans les détails et je sais que le stockage local et la sécurité basée sur le javascript en général suscitent beaucoup de scepticisme. Quelqu'un peut-il nous dire si c'est le cas ?

• des défauts fondamentaux dans l'approche ci-dessus ?
• des solutions possibles pour de tels défauts ?
• existe-t-il un meilleur moyen de sécuriser le stockage local lorsqu'une application html 5 doit fonctionner hors ligne pendant de longues périodes ?

Merci pour toute aide.

Answer 1

WebCrypto

Les problèmes de cryptographie dans le javascript côté client (navigateur) sont détaillés ci-dessous. Toutes ces préoccupations, à l'exception d'une seule, ne s'appliquent pas à l'application WebCrypto API qui est maintenant raisonnablement bien soutenu .

Pour une application hors ligne, vous devez toujours concevoir et mettre en œuvre un keystore sécurisé.

Remarque : Si vous utilisez Node.js, utilisez le module intégré crypto API.

Cryptographie native en Javascript (avant WebCrypto)

Je présume que la principale préoccupation est que quelqu'un ayant un accès physique à l'ordinateur lise les données. localStorage pour votre site, et vous voulez que la cryptographie aide à empêcher cet accès.

Si quelqu'un a un accès physique, vous êtes également ouvert à des attaques autres et pires que la lecture. Celles-ci incluent (mais ne sont pas limitées à) : keyloggers, script modification hors ligne, script injection locale, empoisonnement du cache du navigateur et redirections DNS. Ces attaques ne fonctionnent que si l'utilisateur utilise la machine après qu'elle ait été compromise. Néanmoins, un accès physique dans un tel scénario signifie que vous avez de plus gros problèmes.

Gardez donc à l'esprit que le seul scénario dans lequel la crypto locale a de la valeur est le vol de la machine.

Il existe des bibliothèques qui mettent en œuvre la fonctionnalité souhaitée, par exemple Stanford Javascript Crypto Library . Il y a cependant des faiblesses inhérentes (comme indiqué dans le lien de la réponse de @ircmaxell) :

1. Manque d'entropie / génération de nombres aléatoires ;
2. L'absence d'un magasin de clés sécurisé, c'est-à-dire que la clé privée doit être protégée par un mot de passe si elle est stockée localement, ou stockée sur le serveur (ce qui empêche tout accès hors ligne) ;
3. Absence d'effacement sécurisé ;
4. Absence de caractéristiques de synchronisation.

Chacune de ces faiblesses correspond à une catégorie de compromission cryptographique. En d'autres termes, même si vous avez le nom "crypto", il sera bien en deçà de la rigueur à laquelle on aspire dans la pratique.

Tout cela étant dit, l'évaluation actuarielle n'est pas aussi triviale que "la crypto Javascript est faible, ne l'utilisez pas". Il ne s'agit pas d'une approbation, mais strictement d'une mise en garde, qui exige que vous compreniez parfaitement l'exposition aux faiblesses mentionnées ci-dessus, la fréquence et le coût des vecteurs auxquels vous êtes confrontés, ainsi que votre capacité d'atténuation ou d'assurance en cas d'échec : La crypto Javascript, malgré ses faiblesses, peut réduire votre exposition mais uniquement contre les voleurs aux capacités techniques limitées. Cependant, vous devez présumer que la crypto Javascript n'a aucune valeur contre un attaquant déterminé et capable qui cible ces informations. Certains considéreraient qu'il est trompeur de qualifier les données de "cryptées" alors que l'on sait que tant de faiblesses sont inhérentes à l'implémentation. En d'autres termes, vous pouvez réduire marginalement votre exposition technique, mais vous augmentez votre exposition financière en cas de divulgation. Chaque situation est différente, bien sûr - et l'analyse de la réduction de l'exposition technique à l'exposition financière n'est pas triviale. Voici une analogie illustrative : Certaines banques exigent des mots de passe faibles En effet, leur exposition aux pertes dues à des mots de passe faibles est inférieure au coût pour l'utilisateur final de la mise en place de mots de passe forts.

Answer 2

Eh bien, le principe de base est le suivant : non, ce n'est pas encore sécurisé.

En fait, vous ne pouvez pas utiliser la cryptographie en JavaScript : JavaScript Crypto considéré comme nuisible .

Le problème est qu'il n'est pas possible d'introduire de manière fiable le code cryptographique dans le navigateur, et même si c'était le cas, JS n'est pas conçu pour vous permettre de l'exécuter en toute sécurité. Ainsi, tant que les navigateurs ne disposeront pas d'un conteneur cryptographique (que les extensions de médias cryptés fournissent, mais contre lequel on se rallie pour leurs objectifs de DRM), il ne sera pas possible de le faire en toute sécurité.

En ce qui concerne la "meilleure façon", il n'y en a pas pour le moment. Votre seule alternative est de stocker les données en texte brut, et d'espérer le meilleur. Ou ne pas stocker l'information du tout. Dans tous les cas.

Soit ça, soit si vous besoin de ce genre de sécurité, et que vous avez besoin d'un stockage local, créez une application personnalisée...

Answer 3

Pour explorer ce sujet, j'ai une présentation intitulée "Securing TodoMVC Using the Web Cryptography API" ( vidéo , code ).

Il utilise le API de cryptographie Web pour stocker la liste des tâches chiffrée dans localStorage en protégeant l'application par un mot de passe et en utilisant une clé dérivée du mot de passe pour le chiffrement. Si vous oubliez ou perdez le mot de passe, il n'y a pas de récupération possible. ( Clause de non-responsabilité - il s'agissait d'un POC et non d'une utilisation en production. )

Comme l'indiquent les autres réponses, cette solution reste sensible aux XSS ou aux logiciels malveillants installés sur l'ordinateur client. Cependant, toute donnée sensible se trouverait également en mémoire lorsque les données sont stockées sur le serveur et que l'application est utilisée. Je suggère que le support hors ligne pourrait être le cas d'utilisation le plus convaincant.

En fin de compte, le cryptage de localStorage ne protège probablement les données que contre les attaquants qui ont un accès en lecture seule au système ou à ses sauvegardes. Il ajoute une petite quantité de défense en profondeur pour le Top 10 de l'OWASP. A6-Exposition des données sensibles et vous permet de répondre correctement à la question "Ces données sont-elles stockées en clair à long terme ?

Answer 4

C'est un article vraiment intéressant. J'envisage de mettre en œuvre le cryptage JS pour offrir une sécurité lors de l'utilisation du stockage local. Il est absolument clair que cela n'offrira une protection qu'en cas de vol de l'appareil (et que cela est mis en œuvre correctement). Il n'offrira pas de protection contre les enregistreurs de frappe, etc. Cependant, il ne s'agit pas d'un problème lié aux JS, car la menace des keyloggers concerne toutes les applications, quelle que soit leur plate-forme d'exécution (navigateur, native). En ce qui concerne l'article "JavaScript Crypto Considered Harmful" référencé dans la première réponse, j'ai une critique à formuler : "Vous pourriez utiliser SSL/TLS pour résoudre ce problème, mais c'est cher et compliqué". Je pense qu'il s'agit d'une affirmation très ambitieuse (et peut-être plutôt biaisée). Oui, le SSL a un coût, mais si vous considérez le coût du développement d'applications natives pour de multiples systèmes d'exploitation, plutôt que basées sur le Web en raison de ce seul problème, le coût du SSL devient insignifiant.

Ma conclusion - Le code de cryptage côté client a sa place, mais comme pour toutes les applications, les développeurs doivent en reconnaître les limites et le mettre en œuvre s'il est adapté à leurs besoins, et s'assurer qu'il existe des moyens d'en atténuer les risques.

Answer 5

Non accessible à toute page web (vrai) mais facilement accessible et modifiable via des outils de développement, tels que chrome (ctl-shift-J). Par conséquent, un cryptage personnalisé est nécessaire avant de stocker la valeur.

Mais, si javascript a besoin de décrypter (pour valider), alors l'algorithme de décryptage est exposé et peut être manipulé.

Javascript a besoin d'un conteneur entièrement sécurisé et de la possibilité d'implémenter correctement des variables et des fonctions privées qui ne sont disponibles que pour l'interpréteur js. Mais cela viole la sécurité de l'utilisateur - puisque les données de suivi peuvent être utilisées en toute impunité.

Par conséquent, le javascript ne sera jamais totalement sécurisé.