Intelligence de données générative

Cyber sécurité

Conseils de codage pour contourner les vulnérabilités JavaScript

Réédité par Platon
Réédité par Platon

Date :

Vues: 62

Dans les années 90, Internet était constitué d'arrière-plans gris et de zones de texte ternes. Mais JavaScript a changé tout cela, nous permettant de profiter de textes dynamiques, de sites Web interactifs et d'éléments cliquables sans sacrifier les performances. JavaScript est l’un des langages de programmation les plus utilisés aujourd’hui.

Cependant, les attaquants exploitent les vulnérabilités des applications JavaScript avec des scripts malveillants et des attaques de piratage de session pour créer un large éventail de manipulations, telles que des redirections de session, la collecte de données sensibles (violations de conformité) et la falsification d'informations. De nombreuses variantes de ransomware exploitent des failles dans le code JavaScript, telles que Magniber, Vjw0rm et GootLoader. Le groupe MageCart a compromis British Airways, en utilisant seulement 22 lignes de code pour manipuler la bibliothèque Modernizr.

Alors, comment rendre JavaScript plus sécurisé ? Il existe des dizaines de façons dont les adversaires exploitent les vulnérabilités JS, y compris des attaques difficiles à contrer telles que les scripts intersite (XSS), le détournement de session, l'injection de commandes du système d'exploitation, les exploits d'expressions régulières (Regex) et l'injection d'opérateurs de propagation. Des habitudes de sécurité bien établies peuvent contrecarrer certaines de ces attaques. Examinons de plus près certaines techniques d'attaque et les meilleures pratiques de cybersécurité pour les atténuer.

Attaques courantes et comment se défendre contre elles

Injection SQL (SQLi). Les attaques par injection SQL ciblent des vulnérabilités telles que les procédures d'encodage et une validation inappropriée pour exécuter des commandes de base de données malveillantes.
Pour minimiser les risques : Validez toutes les entrées. Éloignez-vous de l'utilisation de requêtes SQL explicites dans le code au profit du mappage objet-relationnel (ORM). Il existe de nombreuses options intéressantes, mais j'aime TYPEORME.

exemple de code Javascript montrant des entrées nettoyées

Scripts intersites (XSS). Les attaquants exploitent des vulnérabilités telles que le manque de validation ou de codage dans les applications Web pour insérer du code malveillant. L'application contaminée envoie le code à l'utilisateur sous forme de script côté navigateur, qui permet ensuite aux attaquants d'accéder aux jetons de session, aux cookies, aux mots de passe et à d'autres types d'informations personnelles. Il existe différents types d’attaques XSS utilisées aujourd’hui : XSS réfléchi (non persistant), XSS stocké et XSS basé sur DOM étant les variantes les plus courantes.
Pour minimiser les risques : Ne vous contentez pas de faire confiance au contenu transmis par les utilisateurs et de l'exécuter ; filtrez-le à votre arrivée. Assurez-vous que le contenu renvoyé par votre serveur applique les en-têtes de type de contenu correspondant pour garantir que les navigateurs interprètent les réponses comme vous le souhaitez. Appliquez une politique de sécurité du contenu chaque fois que vous le pouvez pour contrôler quel contenu s'exécute sur votre site Web et à quelles origines vous faites confiance avec ce contenu.

Falsification de requêtes intersites (CSRF). Les attaques CSRF sont extrêmement courantes aujourd’hui. Ces exploits incitent les utilisateurs finaux à effectuer et à exécuter des actions malveillantes lorsqu'ils utilisent des applications Web. Cela se produit une fois qu’ils ont déjà été authentifiés et que leur utilisation a commencé. La principale technique utilisée ici est l’ingénierie sociale, généralement des e-mails ou des SMS malveillants avec des liens d’apparence normale. Une fois le lien cliqué, la charge utile est exécutée.

Schéma du processus de falsification de requêtes intersites

Pour minimiser les risques : Utilisez des frameworks fournis avec une protection CSRF intégrée. Vous pouvez également implémenter des jetons CSRF pour toutes les requêtes qui provoquent des actions (changement d'état) et les valider sur votre backend.

Attaques de traversée de chemin. Également connues sous le nom d'attaques par traversée de répertoire, les attaques par traversée de chemin sont utilisées pour obtenir un accès non autorisé aux répertoires, aux fichiers de configuration et aux mots de passe sensibles qui ont été stockés (plutôt négligemment) en dehors du dossier racine Web.
Pour minimiser les risques : Évitez de stocker des fichiers sensibles en dehors de votre dossier racine Web. Travaillez sans intervention de l'utilisateur lors de l'utilisation d'appels au système de fichiers. Assurez-vous également que l'utilisateur ne peut pas fournir toutes les parties du chemin en entourant l'entrée de l'utilisateur avec votre propre code de chemin. Enfin, mettez en œuvre des politiques d’accès au code strictes (avec des prisons chrootées) pour restreindre l’endroit où les fichiers peuvent être obtenus ou enregistrés.

Falsification de requêtes côté serveur (SSRF). Les attaques SSRF exploitent les vulnérabilités côté serveur pour effectuer un large éventail d'activités non autorisées : accès à des ressources sensibles (métadonnées AWS), connexion à des services internes, manipulation de données et même modification d'URL pour accéder aux données de fournisseurs sécurisés ou canaliser les informations client vers des serveurs distants. Outre l'utilisation des protocoles HTTP, les attaques SSRF peuvent également utiliser FTP, SMTP et SMB.
Pour minimiser les risques : Valider les données et les contextes. Recherchez les adresses V4 et V6. Vérifiez les adresses IP fournies avec les adresses IP des fournisseurs de confiance. N'enregistrez pas de données sur des serveurs : optez plutôt pour des compartiments et des blobs S3. Créez une liste blanche sensible à la casse des domaines approuvés et identifiés. Et n’acceptez jamais les URL complètes des utilisateurs : elles sont difficiles à valider.

Exposition aux cookies sensibles. Il existe de nombreuses variantes de vulnérabilités liées à l'exposition des données sensibles, mais elles ont toutes un thème commun : l'exposition d'informations qui auraient dû être cryptées. Les pirates aiment également exploiter des clés cryptographiques faibles (par exemple, l'algorithme de hachage de mot de passe MD5 qui n'est plus considéré comme sécurisé) avec des attaques par force brute alimentées par de puissants ASIC et GPU.
Pour minimiser les risques : Classez toutes les données stockées, traitées et transmises conformément à vos exigences réglementaires et appliquez les contrôles en conséquence. Supprimez les données sensibles inutiles. Chiffrez toutes les données au repos et les données en transit avec le protocole TLS, ainsi que les chiffrements PFS et d'autres paramètres sécurisés. Utiliser HSTS. Désactivez toute mise en cache pour les réponses contenant des informations sensibles.

En résumé : meilleures pratiques

JavaScript est une véritable bénédiction grâce à sa polyvalence et sa flexibilité. Il aide les entreprises à créer des expériences utilisateur puissantes et à obtenir des fonctionnalités améliorées. Mais cela présente également des exigences de sécurité dont vous devez tenir compte. Seule une approche proactive peut vous aider à éviter les problèmes (temps d'arrêt, coûts de remédiation, atteinte à la marque, perte d'activité) et à rester opérationnel. conforme aux règles de confidentialité.

Voici quelques bonnes pratiques que vous devriez mettre en place :

  • Restez à l'écart de la eval () commande dans votre code car elle peut simplement exécuter un argument passé comme n'importe quelle expression JS régulière.
  • Donnez la priorité aux protocoles de cryptage, et définissez également tous vos cookies comme « sécurisés » pour limiter leur utilisation et empêcher les pirates de les exploiter.
  • Prenez l'habitude de régler Clés d'accès API. Une fois que vous commencez à attribuer des jetons individuels aux utilisateurs finaux, les accès illégaux peuvent automatiquement être refusés.
  • innerHTML est une méthode de manipulation DOM très puissante, qui ne limite ni n'échappe aux valeurs qui leur sont transmises. Utilisez plutôt innerText.

C'est également une bonne idée de coder en toute sécurité et d'avoir à bord une solution d'analyse de code source (SCA) pour détecter les vulnérabilités le plus tôt possible. Le trafic doit également passer par un pare-feu d'application Web (WAF) éprouvé et testé. Bien qu'aucun des deux ne soit une solution miracle en matière de sécurité JavaScript (la cyberimmunité en général est un mythe), vous êtes toujours plus en sécurité avec plusieurs couches de protection.

spot_img

Dernières informations

spot_img

Copyright @ 2024 Platon Technologies Inc.