Sécurité JavaScript

Comme presque tous les langages de programmation, JavaScript n’est pas exempt de risques potentiels pour la sécurité. L’exploitation de vulnérabilités JavaScript peut permettre de manipuler des données, de détourner des sessions, de modifier ou de dérober des données, et bien plus encore. Bien que JavaScript soit généralement considéré comme une technologie côté client, les problèmes de sécurité JavaScript peuvent également affecter les environnements côté serveur.

La meilleure défense contre les vulnérabilités JavaScript les plus courantes consiste à les connaître et à mettre en place les contrôles appropriés pour réduire les risques.

Dans cet article, nous examinons les vulnérabilités JavaScript les plus courantes et les moyens de les prévenir en combinant des approches de sécurité modernes et des outils de test (par exemple, des outils d’audit et d’analyse du code, un scanner de vulnérabilités JavaScript, etc.).

Qu’est-ce que la sécurité JavaScript ?

La sécurité JavaScript consiste à examiner, prévenir, contrer et résoudre les problèmes de sécurité dans les applications qui utilisent JavaScript.

JavaScript est une technologie fondamentale pour créer des applications web. Elle est également très populaire pour le développement d’applications côté serveur, de bureau et même mobiles. Sa popularité généralisée en fait toutefois une cible de choix pour les pirates, qui peuvent l’attaquer par différents vecteurs. Comme JavaScript est surtout utilisé côté front-end, il est logique de s’intéresser d’abord aux problèmes de sécurité JavaScript dans les navigateurs.

Les éditeurs de logiciels ont également pris conscience de ces problèmes de sécurité JavaScript et proposent des logiciels d’analyse de la sécurité JavaScript ainsi que divers outils de test qui renforcent la sécurité des applications et réduisent considérablement les risques. Essayez notre vérificateur de code JavaScript pour détecter les vulnérabilités dans votre code.

Quelles sont les vulnérabilités JavaScript les plus courantes ?

Les vecteurs d’attaque JavaScript les plus courants comprennent l’exécution de scripts malveillants, le vol des données de session déjà établies d’un utilisateur ou des données du localStorage du navigateur, la manipulation des utilisateurs pour les inciter à effectuer des actions involontaires et l’exploitation de vulnérabilités dans le code source des applications web.

Bien entendu, cette liste n’est pas exhaustive ; elle se concentre plutôt sur l’aspect front-end des applications web.

8 vulnérabilités de sécurité JavaScript

8 vulnérabilités de sécurité JavaScript

1. Vulnérabilités du code source

Les vulnérabilités du code source sont souvent associées à d’autres failles de sécurité JavaScript, voire à plusieurs d’entre elles. Malheureusement, dans ces situations, l’obfuscation JavaScript seule ne permet ni de prévenir ni de dissimuler ce type de vulnérabilité. JavaScript étant un langage interprété et non compilé, cette méthode ne peut pratiquement pas empêcher les pirates potentiels d’examiner le code de l’application. L’obfuscation reste néanmoins une bonne pratique, car elle ralentit les tentatives de rétro-ingénierie des pirates.

L’utilisation généralisée de packages et de bibliothèques publics est une autre cause de failles dans le code source. NPM, un acteur majeur de l’écosystème JavaScript, propose plus d’un million de packages dans son registre. Cette grande diversité est certes un avantage, mais elle signifie également que ces packages installés dans les projets d’applications web peuvent contenir un grand nombre de vulnérabilités cachées.

De plus, les développeurs installent souvent des packages pour les tâches les plus simples, ce qui accroît le nombre de dépendances de leurs projets. Cela peut bien sûr entraîner des problèmes de sécurité et avoir d’autres conséquences importantes.

Surveiller et traiter toutes les vulnérabilités potentielles des dépendances d’une application peut prendre beaucoup de temps et de travail. Les outils d’audit peuvent contribuer à automatiser et donc à accélérer ce processus.

Une approche à plusieurs volets pour prévenir les problèmes de sécurité JavaScript dans le code source doit inclure les éléments suivants :

• Sensibiliser davantage les développeurs aux bonnes pratiques

• Auditer correctement le code de l’application pour détecter les vulnérabilités potentielles

• Écrire des tests unitaires pour vérifier non seulement que le code se comporte comme prévu, mais aussi qu’il s’exécute de manière sécurisée

• Mettre en place des outils pour analyser les applications de manière dynamique et détecter les problèmes de sécurité JavaScript dans les packages et bibliothèques tiers

2. Exécution involontaire de scripts

La plupart des attaques reposant sur l’exécution involontaire de scripts impliquent le cross-site scripting (XSS). JavaScript présente un risque particulier en raison de son interaction avec le Document Object Model (DOM) d’une page web, qui permet d’intégrer des scripts et de les exécuter sur les ordinateurs des clients sur le web. Ainsi, bien qu’il existe plusieurs types d’attaques XSS, elles ont toutes en commun de faire apparaître et exécuter un script non fiable dans le navigateur de l’utilisateur.

L’un des scénarios d’attaque XSS les plus simples se rencontre souvent sur les forums, où les utilisateurs peuvent voir les messages des autres sur la page. Si le HTML ou le JavaScript d’un message n’est pas correctement encodé, des utilisateurs malveillants peuvent publier un script sur le forum.

La publication d’un tel script ferait de chaque utilisateur final une victime, qui faciliterait involontairement l’attaque en utilisant simplement l’application. Le code malveillant semblerait faire partie de la page web.

Pour prévenir les attaques XSS, les développeurs doivent assainir les données — en combinant l’échappement, le filtrage et la validation des chaînes — lors du traitement des entrées utilisateur et des sorties du serveur.

3. Échappement et encodage des entrées utilisateur

Les attaques XSS reposent sur l’envoi de données contenant certains caractères spéciaux utilisés dans le HTML, le JavaScript ou le CSS sous-jacent d’une page web. Lorsque le navigateur affiche la page et rencontre ces caractères, il les interprète comme faisant partie du code de la page plutôt que comme une valeur à afficher. L’attaquant peut ainsi sortir d’un champ de texte et injecter du code côté navigateur supplémentaire qui sera exécuté.

Pour éviter cela, chaque fois que des données fournies par le navigateur sont renvoyées dans une réponse (qu’elles soient immédiatement répercutées ou récupérées dans une base de données), ces caractères spéciaux doivent être remplacés par leurs codes d’échappement.

Par exemple, les caractères < et > qui servent à délimiter les entités HTML peuvent être remplacés par &lt; et &gt;, afin que le navigateur affiche ces caractères au lieu de les interpréter comme des entités HTML. Si les données fournies par le navigateur sont renvoyées dans un contexte JavaScript, les caractères non alphanumériques doivent être échappés au moyen de xNN, où NN correspond à la valeur ASCII hexadécimale du caractère.

4. Filtrage des entrées

Dans certains cas, il peut être préférable de simplement supprimer les caractères dangereux des données reçues en entrée. Cette méthode offre un certain niveau de protection, mais ne doit pas être utilisée seule pour se prémunir contre la manipulation des données. Les attaquants disposent de diverses techniques pour contourner ces filtres.

5. Validation des entrées

Dans la mesure du possible, les entrées fournies par le navigateur doivent être validées pour vérifier qu’elles ne contiennent que les caractères attendus. Par exemple, les champs de numéro de téléphone ne devraient accepter que des chiffres et, éventuellement, des tirets ou des parenthèses. Toute entrée contenant des caractères qui ne figurent pas dans l’ensemble attendu doit être immédiatement rejetée. Les filtres doivent être configurés pour accepter les caractères autorisés et rejeter tous les autres.

6. Se fier uniquement à la validation côté client

Bien que toutes les méthodes évoquées ci-dessus soient efficaces dans les navigateurs, les pirates peuvent utiliser des outils spécifiques pour envoyer des données directement au serveur et ainsi contourner les validations côté client. Ils peuvent alors envoyer au serveur des données potentiellement malveillantes ou non vérifiées. En l’absence de validation supplémentaire côté serveur, les données stockées risquent d’être corrompues ou remplacées par des données erronées.

La bonne pratique recommandée pour prévenir ces scénarios consiste à mettre en place une validation à la fois côté client et côté serveur. Cette approche réduit le risque de données incorrectes tout en assurant côté client des validations qui améliorent l’expérience de l’utilisateur final.

La validation côté serveur uniquement peut être contraignante pour l’utilisateur, car il peut devoir remplir plusieurs fois des formulaires en ligne avant que toutes les validations soient réussies. La validation JavaScript doit signaler immédiatement à l’utilisateur les problèmes liés à ses entrées, tandis que la validation côté serveur garantit que seules les données attendues sont transmises à l’application.

7. Vol des données de session

Les scripts côté client exécutés dans le navigateur peuvent être très puissants, car ils ont accès à tout le contenu qu’une application web renvoie au navigateur. Cela inclut les cookies, qui peuvent contenir des données sensibles, notamment les identifiants de session des utilisateurs. En fait, une méthode courante d’exploitation des attaques XSS consiste à envoyer les jetons d’identifiant de session de l’utilisateur à l’attaquant, afin qu’il puisse détourner la session.

Pour empêcher cela, la plupart des navigateurs prennent désormais en charge l’attribut Http-Only pour les cookies. Lorsque le serveur définit un cookie dans le navigateur, l’attribut Http-Only indique à ce dernier de ne pas autoriser l’accès au cookie depuis le DOM. Cela empêche les attaques basées sur des scripts côté client d’accéder aux données sensibles stockées dans ces cookies.

Les données stockées dans le stockage local ou de session du navigateur peuvent également être dérobées de la même manière, mais elles ne peuvent pas être protégées en contrôlant l’accès au DOM. Il est donc préférable d’éviter de stocker des informations sensibles, comme des jetons, dans le stockage du navigateur, sauf si l’architecture de l’application web l’exige pour des fonctionnalités spécifiques.

8. Inciter les utilisateurs à effectuer des actions involontaires

Les attaques par falsification de requêtes intersites (CSRF) tentent de tromper un navigateur pour qu’il exécute des requêtes malveillantes sur des sites web auxquels l’utilisateur est déjà connecté, même si le site n’est pas ouvert à ce moment-là. Si les sessions sur le site ciblé reposent sur des cookies, les requêtes vers ce site peuvent être automatiquement accompagnées des cookies d’autorisation.

Les pirates peuvent également créer leurs propres pages web et leur faire envoyer en arrière-plan des requêtes malveillantes à d’autres sites lorsque l’utilisateur les ouvre. Ils peuvent aussi utiliser les réseaux sociaux, les forums et d’autres plateformes pour publier des liens ou du contenu malveillants qui obligent les navigateurs à appeler discrètement d’autres sites en utilisant les cookies de session de l’utilisateur.

La méthode générale pour éviter cette vulnérabilité consiste à mettre en place une tokenisation des communications entre le client et le serveur, en ajoutant un jeton supplémentaire qui n’est pas stocké dans les cookies. Des jetons doivent être générés pour chaque formulaire du site web à l’ouverture de la session et transmis avec chaque requête tant que l’utilisateur est présent sur le site.

Comment gérer les problèmes de sécurité JavaScript ?

La protection des applications et des serveurs contre les vulnérabilités JavaScript passe par l’adoption des bonnes pratiques de <span>sécurité JavaScript</span> et l’utilisation d’outils d’analyse sophistiqués.

Dans le domaine du développement web, les ingénieurs logiciels doivent constamment se tenir au courant des nouveaux risques de sécurité JavaScript. Il est important de tester les fonctionnalités des applications, mais l’utilisation régulière d’outils de test de sécurité JavaScript est également essentielle pour prévenir les vulnérabilités. Enfin, quelques bonnes pratiques simples et courantes contribueront à renforcer la durabilité de vos applications.

Les bonnes pratiques suivantes en matière de sécurité JavaScript peuvent réduire ces risques.

• Évitezeval()** : n’utilisez pas cette commande dans votre code, car elle exécute simplement l’argument transmis s’il s’agit d’une expression JavaScript. Ainsi, si un pirate parvient à manipuler la valeur d’entrée, il pourra exécuter n’importe quel script. Privilégiez plutôt des options alternatives plus sécurisées.

• Chiffrez : utilisez HTTPS/SSL pour chiffrer les données échangées entre le client et le serveur.

• Définissez des cookies sécurisés : pour garantir l’utilisation de SSL/HTTPS, définissez vos cookies comme « secure » afin que les cookies de votre application ne soient utilisés que sur des pages web sécurisées.

• Définissez des clés d’accès à l’API : attribuez des jetons individuels à chaque utilisateur final. Si ces jetons ne correspondent pas, l’accès peut être refusé ou révoqué.

• Utilisez des méthodes sûres de manipulation du DOM :Des méthodes comme innerHTML sont puissantes et potentiellement dangereuses, car elles ne limitent pas les valeurs qui leur sont transmises et ne les échappent ni ne les encodent. Utiliser une méthode comme innerText permet d’échapper automatiquement les contenus potentiellement dangereux. C’est particulièrement utile pour prévenir les attaques XSS basées sur le DOM.

Identifier les problèmes de sécurité JavaScript potentiels est une première étape essentielle pour prévenir les vulnérabilités dans le développement d’applications. Testez votre code dès maintenant avec un scanner de vulnérabilités open source.