Sécurité JavaScript

Comme presque tous les langages de programmation, JavaScript présente des risques en matière de sécurité. L’exploitation des vulnérabilités JavaScript peut permettre de manipuler, modifier et voler des données, de rediriger des sessions, et bien plus encore. Bien que JavaScript soit généralement considéré comme une application client, ses vulnérabilités de sécurité sont également susceptibles d’avoir des répercussions dans les environnements côté serveur.

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

Dans cet article, nous examinerons les vulnérabilités les plus courantes de JavaScript et la manière de les prévenir avec des approches modernes de la sécurité, combinées à des outils de test (par exemple, outils d’audit et d’analyse de code, outil d’analyse des vulnérabilités JavaScript, etc.)

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

La sécurité JavaScript consiste à rechercher, prévenir, protéger et résoudre des problèmes de sécurité dans les applications qui utilisent JavaScript.

La technologie JavaScript, fondamentale pour la création d’applications web, est très couramment utilisée pour la création d’applications côté serveur, de bureau et même mobiles. Sa grande popularité en fait une cible de choix pour les pirates, qui utilisent divers vecteurs d’attaque. JavaScript étant principalement utilisé en front-end, il est logique de se concentrer d’abord sur les problèmes de sécurité JavaScript dans les navigateurs.

Les éditeurs de logiciels ont reconnu ces problèmes de sécurité JavaScript et réagi en proposant des logiciels d’analyse de la sécurité JavaScript, ainsi que divers outils de test de la sécurité JavaScript qui rendent les applications plus sûres et réduisent considérablement les risques. Essayez notre vérificateur de code JavaScript pour détecter des vulnérabilités dans votre code.

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

Les vecteurs d’attaque JavaScript les plus courants sont les suivants : exécution de scripts malveillants, vol de données de session établies par l’utilisateur ou de données provenant du stockage local (localStorage) du navigateur, incitation des utilisateurs à effectuer des actions indésirables, exploitation de vulnérabilités dans le code source des applications web.

Bien entendu, cette liste axée sur l’aspect front-end des applications web n’est en aucun cas exhaustive.

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

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

1. Vulnérabilités du code source

Souvent, les vulnérabilités du code source sont combinées à une ou plusieurs autres failles de sécurité JavaScript. Dans ce cas, l’utilisation de l’offuscation JavaScript ne suffit pas à empêcher ou cacher ces vulnérabilités. JavaScript étant un langage interprété, et non compilé, il serait pratiquement impossible d’empêcher des pirates d’examiner le code de l’application avec cette méthode. L’offuscation reste néanmoins une pratique pertinente car elle ralentit leurs tentatives de rétro-ingénierie.

Autre cause des failles de sécurité dans le code source : l’utilisation généralisée de paquets et de bibliothèques publics. NPM, acteur majeur de l’écosystème JavaScript, propose plus d’un million de paquets dans son registre. Si la diversité des offres est certainement un avantage, cela signifie aussi qu’il existe potentiellement un grand nombre de vulnérabilités cachées dans ces paquets qui sont installés dans les projets d’applications web.

Les développeurs installent souvent des paquets, même pour les tâches les plus simples, ce qui augmente les dépendances de leur projet, entraîne des problèmes de sécurité, et d’autres conséquences majeures.

La surveillance et le traitement de toutes les vulnérabilités potentielles des dépendances applicatives s’avèrent chronophages et fastidieux. Heureusement, des outils d’audit permettent d’automatiser, et donc d’accélérer, le processus.

Une approche multidimensionnelle pour prévenir les problèmes de sécurité JavaScript dans le code source devrait inclure :

• Une sensibilisation accrue des développeurs aux meilleures pratiques

• Un audit approprié du code de l’application pour détecter les vulnérabilités potentielles

• L’écriture de tests unitaires pour s’assurer non seulement que le code se comporte comme prévu, mais aussi qu’il s’exécute en toute sécurité

• La mise en œuvre d’outils pour l’analyse dynamique des applications et l’identification des problèmes de sécurité JavaScript dans les paquets et les bibliothèques de tiers

2. Exécution de scripts indésirables

La majorité des attaques par exécution involontaire de scripts impliquent l’attaque sur les éléments dynamiques (XSS). Un problème spécifique à JavaScript est sa façon d’interagir avec le Document Object Model (DOM) d’une page web, qui permet aux scripts d’être intégrés et exécutés sur des ordinateurs clients sur le web. Ainsi, bien qu’il existe plusieurs types d’attaques XSS, toutes ont en commun de faire apparaître et d’exécuter des scripts non fiables dans le navigateur de l’utilisateur.

L’un des scénarios d’attaque XSS les plus simples est souvent observé sur les sites web de forums où les utilisateurs peuvent voir les messages des autres sur la page. Si le HTML ou le JavaScript ne sont pas correctement encodés lorsqu’ils font partie d’un message, des utilisateurs peu scrupuleux pourraient publier du contenu dans un forum :

La publication d’un script de ce type ferait de chaque utilisateur final une victime facilitant involontairement l’attaque en exécutant simplement l’application, le code malveillant semblant faire partie de la page web.

Pour prévenir les attaques XSS, les développeurs doivent appliquer la désinfection (une combinaison d’échappement, de filtrage et de validation des chaînes de caractères) lors du traitement des entrées et des sorties de l’utilisateur depuis le serveur.

3. Échappement/encodage des entrées de l’utilisateur

Les attaques XSS reposent sur la fourniture de données contenant certains caractères spéciaux qui sont utilisés dans le code HTML, JavaScript ou CSS sous-jacent d’une page web. Lorsque le navigateur rend la page web et rencontre ces caractères, il les considère comme faisant partie du code de la page, et non comme une valeur à afficher. C’est ce qui permet à l’attaquant de sortir d’un champ de texte et de fournir du code supplémentaire, côté navigateur, 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 reflétées ou extraites d’une base de données), ces caractères spéciaux doivent être remplacés par des codes d’échappement pour ces caractères.

Par exemple, les caractères
< and > utilisés pour délimiter des entités HTML peuvent être remplacés par
< and >, qui indique au navigateur d’afficher ces caractères au lieu de les interpréter comme étant 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 à l’aide de xNN, où NN correspond à la valeur ASCII hexadécimale du caractère.

4. Filtrage des entrées

Dans certains cas, il est préférable de simplement supprimer les caractères dangereux des données reçues en entrée. Cette méthode offre un certain degré de protection, mais ne suffit pas pour se protéger 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 s’assurer qu’elles ne contiennent que les caractères attendus. Par exemple, les champs de numéro de téléphone ne doivent contenir que des chiffres et, éventuellement, un tiret ou des parenthèses. Les entrées contenant des caractères non prévus doivent être immédiatement rejetées. Ces filtres doivent être configurés de façon à identifier les caractères acceptables et rejeter tout le reste.

6. Validation uniquement côté client

Bien que toutes les méthodes évoquées ci-dessus soient efficaces dans les navigateurs, les pirates peuvent aussi utiliser des outils spéciaux pour envoyer les données directement au serveur, contournant ainsi les validations côté client. Cela permet l’entrée de données potentiellement malveillantes ou non vérifiées sur le serveur. Sans validation supplémentaire côté serveur, les données stockées pourraient être corrompues ou remplacées par des données erronées.

La meilleure pratique recommandée pour éviter de tels scénarios consiste à mettre en œuvre une validation à la fois côté client et côté serveur. Cette approche réduit le risque, tout en fournissant des fonctions de validation sur le client qui améliorent les résultats pour l’utilisateur final.

La validation uniquement sur le serveur est parfois fastidieuse pour l’utilisateur, car elle peut le contraindre à remplir plusieurs fois des formulaires en ligne avant que tout ne soit validé. La validation JavaScript doit être utilisée pour informer immédiatement l’utilisateur des problèmes liés à sa saisie, tandis que la validation du serveur garantit que seules les données attendues parviennent à l’application.

7. Vol des données de session

Le script de navigateur côté client peut être très puissant dans la mesure où il a accès à tout le contenu renvoyé par une application web au navigateur. Cela inclut les cookies qui peuvent potentiellement contenir des données sensibles, notamment les identifiants de session des utilisateurs. En fait, une exploitation courante des attaques XSS consiste à envoyer les jetons d’identification de session de l’utilisateur à l’attaquant afin qu’il puisse détourner la session.

Pour éviter cela, la plupart des navigateurs prennent désormais en charge l’attribut Http-Only sur les cookies. Lorsque le serveur place un cookie sur le navigateur, la définition de l’attribut Http-Only indique au navigateur de ne pas autoriser l’accès au cookie à partir du 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 de stockage local et de session du navigateur peuvent être volées de la même manière, mais elles ne peuvent pas être sécurisées par l’accès au DOM. Il est donc préférable d’éviter de stocker des informations sensibles, telles que des jetons, dans le stockage du navigateur, sauf en cas de nécessité imposée par les caractéristiques spécifiques de l’architecture de l’application web.

8. Inciter les utilisateurs à effectuer des actions indésirables

Le Cross-site request forgery (CSRF) est un type d’attaque qui tente d’inciter le navigateur à exécuter des requêtes malveillantes sur les sites web auxquels l’utilisateur est déjà connecté, même si les sites ne sont pas réellement ouverts à ce moment-là. Si les sessions sur le site cible sont basées sur des cookies, les requêtes adressées à ce site peuvent être automatiquement enrichies de cookies d’autorisation.

Les pirates peuvent également mettre en place leurs propres pages web et leur faire exécuter des requêtes malveillantes vers d’autres sites en arrière-plan lorsque l’utilisateur les ouvre. Ils peuvent également utiliser les médias sociaux, les forums et d’autres plateformes pour publier des liens malveillants ou d’autres contenus qui forcent les navigateurs à effectuer des appels inaperçus vers d’autres sites en utilisant les cookies de session de l’utilisateur.

La technique générale pour éviter cette vulnérabilité consiste à implémenter une tokenisation de la communication client-serveur, dans laquelle est introduit un jeton supplémentaire qui n’est pas stocké dans les cookies. Les jetons doivent être générés pour chaque formulaire du site web lors de l’établissement de la session et être envoyés avec chaque requête tant que l’utilisateur est présent sur le site.

Comment faire face aux problèmes de sécurité JavaScript ?

La protection des applications et des serveurs contre les vulnérabilités JavaScript peut être gérée par l’adoption de meilleures pratiques de sécurité JavaScript et l’utilisation d’outils d’analyse avancés.

Dans le monde du développement web, les ingénieurs logiciels doivent constamment se tenir au courant des nouveaux risques de sécurité JavaScript qui apparaissent. S’il est important d’effectuer des tests de fonctionnalité sur les applications, l’utilisation régulière d’outils de test de sécurité JavaScript est également essentielle pour prévenir les vulnérabilités. Enfin, le respect de certaines meilleures pratiques simples et courantes augmentera certainement la durabilité de vos applications.

Les meilleures pratiques de sécurité JavaScript suivantes peuvent réduire ce risque.

• Évitez d’utiliser\**eval()** : n’utilisez pas cette commande dans le code, car elle exécute simplement l’argument passé si c’est une expression JavaScript. Cela signifie que si le pirate réussit à manipuler la valeur d’entrée, il pourra exécuter le script qu’il souhaite. Choisissez d’autres options plus sûres.

• 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 vous assurer que SSL/HTTPS est utilisé, définissez vos cookies comme « sécurisés », ce qui limite l’utilisation des cookies de votre application aux seules pages web sécurisées.

• Définissez des clés d’accès 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 telles que innerHTML sont puissantes et potentiellement dangereuses, car elles ne limitent pas ou n’échappent pas/ne codent pas les valeurs qui leur sont transmises. L’utilisation d’une méthode comme innerText permet d’échapper le contenu potentiellement dangereux. Cela est particulièrement utile pour prévenir les attaques XSS basées sur le DOM.

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