Renforcer la sécurité en JavaScript

Chaque langage de programmation présente son propre ensemble de vulnérabilités de sécurité, et JavaScript ne fait pas exception. Exploiter les vulnérabilités de JavaScript peut entraîner une manipulation des données, un détournement de session, un accès non autorisé aux données, et plus encore. Bien que souvent associé à des fonctionnalités côté client, les risques de sécurité de JavaScript peuvent également représenter des menaces significatives dans des environnements côté serveur.

Pour toute application, la confiance des clients est très importante. Maintenir cette confiance nécessite de protéger les données des clients et d’assurer la sécurité des applications. Heureusement, la mise en œuvre de protections appropriées peut atténuer ces risques et renforcer la sécurité de votre application.

Dans cet article, nous explorerons certaines des menaces de sécurité JavaScript les plus courantes et discuterons des outils et des stratégies efficaces pour protéger votre application contre les attaques potentielles.

Injection de Code Inter Sites

Le scripting intersites (XSS) est une exploitation de sécurité qui permet à un attaquant d’injecter du code malveillant côté client dans un site web. Selon le projet Open Web Application Security Project (OWASP) Top 10 des vulnérabilités de sécurité en 2021, le XSS se classe comme le troisième vecteur d’attaque le plus courant.

Comment atténuer le XSS

Validation des Entrées

Assurez-vous que les entrées des utilisateurs respectent les types de données, les formats et les plages attendus. Supprimez ou échappez les caractères potentiellement nuisibles pour éviter les injections.

function validateInput(input) {
  return input.replace(/[^a-zA-Z0-9]/g, ''); // Allow only alphanumeric characters
}

Encodage des Sorties

Convertir les caractères spéciaux dans la sortie en leurs équivalents d’entité HTML pour neutraliser les scripts potentiellement malveillants avant le rendu.

function encodeHTML(input) {
  return input.replace(/&/g, '&')
    .replace(/</g, '<')
    .replace(/>/g, '>')
    .replace(/"/g, '"')
    .replace(/'/g, ''');
}

Clickjacking

Clickjacking est une attaque trompeuse qui incite les utilisateurs à cliquer sur un élément avec lequel ils n’ont pas l’intention d’interagir. Cette technique consiste à intégrer un site Web légitime dans un site malveillant — souvent en utilisant un <iframe> HTML invisible ou mal positionné — pour détourner les actions de l’utilisateur. En conséquence, les attaquants peuvent voler des identifiants de connexion, obtenir des autorisations non autorisées, ou même tromper les utilisateurs en les incitant à installer involontairement des logiciels malveillants.

Une méthode courante pour y parvenir consiste à utiliser CSS pour ajouter un bouton superposé dont l’opacity est réglée à presque 0. Cela trompe l’utilisateur en lui faisant cliquer sur un bouton ou un lien non intentionnel.

Comment prévenir le Clickjacking

Les X-Frame-Options instruisent le navigateur sur la possibilité d’intégrer le site dans un iframe. Il existe trois options :

1. DENY – Empêche la page d’être affichée dans un iframe entièrement
2. SAMEORIGIN – Permet l’intégration de la page uniquement si la requête provient du même domaine
3. ALLOW-FROM – Permet l’intégration de la page uniquement par un domaine spécifique et de confiance

Dans Node.js, vous pouvez utiliser helmet pour définir ces options comme montré ci-dessous :

const helmet = require("helmet");
const app = express();
app.use(
  helmet({
    xFrameOptions: { action: "sameorigin" },
  }),
);

Une défense efficace contre le clickjacking est de mettre en œuvre l’en-tête Content Security Policy (CSP). Le CSP offre un contrôle granulaire sur la manière dont et où le contenu peut être intégré, empêchant le cadrage non autorisé. 

Pour atténuer les risques de clickjacking, incluez la directive frame-ancestors dans l’en-tête de votre CSP. Par exemple :

Content-Security-Policy: frame-ancestors 'self' https://www.example.org;

Cette politique garantit que le document protégé ne peut être intégré que par son propre origine ('self') et les domaines explicitement autorisés, tels que example.org. Elle bloque toutes les tentatives non autorisées de cadrer le contenu, protégeant les utilisateurs contre les attaques de clickjacking.

Remarque : Si frame-ancestors et X-Frame-Options sont tous deux définis, les navigateurs prenant en charge frame-ancestors ignoreront X-Frame-Options.

La falsification de requête inter-sites (CSRF)

CSRF (parfois aussi appelée XSRF) exploite la confiance qu’un site web a dans le navigateur d’un utilisateur en effectuant des requêtes non autorisées au nom de l’utilisateur. Les attaquants trompent les utilisateurs pour les amener à exécuter des actions sans leur consentement, pouvant entraîner des violations de données ou des transactions non désirées. Quelques exemples sont la mise à jour des informations personnelles de la victime, l’initiation d’un transfert de fonds à partir du compte bancaire de la victime, ou même la redirection d’une livraison de colis vers une adresse différente.

Jetons un coup d’œil à un exemple spécifique de cela. Vous visitez le site Web de votre banque et vous vous êtes connecté. Imaginons que vous receviez un e-mail pour un tirage au sort prétendant être de votre banque. Le lien vous emmène vers une page Web en apparence inoffensive. En coulisses, une requête POST est déclenchée et envoyée à l’application bancaire légitime.

curl --location --request POST 'https://acmebank.com/transfer?routing=852363&fromAccountNumber=123456789&toAccountNo=987654321' \
--header 'Cookie: session=acmebanksessionvalue'

Côté application acmebank.com, la balise « script » soumet le formulaire dès que l’utilisateur charge la page, sans aucune validation de l’utilisateur ou même sans que l’utilisateur ne remarque ce qui se passe, comme illustré ci-dessous.

<html>
  <body>
    <form action="https://acmebank.com/transfer" method="POST">
      <input type="hidden" routing="852363" fromAccountNo="123456789" toAccountNo="987654321" amount="5000" />
    </form>
    <script>
  	window.addEventListener("DOMContentLoaded", () => {
    document.querySelector("form").submit();
  	});
	</script>
  </body>
</html>

Le formulaire ci-dessus crée la requête suivante vers l’application réelle, acmebank. La requête contient le cookie de session de l’utilisateur légitime, mais contient le numéro de compte de notre banque ! Comme votre session avec votre banque est toujours active, le transfert du montant sera effectué s’il n’y a pas d’autre validation en place.

Comment se défendre contre les attaques CSRF

Définissez l’attribut SameSite sur Strict. Cela contrôle si un cookie est envoyé avec les requêtes entre sites.

• Les cookies de session devraient avoir une durée de vie courte. Exigez une ré-authentification pour les actions sensibles afin de réduire les risques.

Utilisez des jetons uniques de session CSRF. Ce jeton peut ensuite être inclus dans un formulaire qui est envoyé par le navigateur. Pour chaque requête, le serveur compare le jeton envoyé par le client à sa valeur stockée pour la session. Utilisez la bibliothèque csrf-csrf pour configurer des jetons uniques.

Vol de données de session

Le détournement de session se produit lorsqu’un attaquant vole le jeton de session d’un utilisateur, ce qui lui permet de se faire passer pour l’utilisateur et d’accéder illégalement à son compte.

Comment prévenir le détournement de session

Utilisez des cookies sécurisés

Définissez les indicateurs Secure et HttpOnly sur les cookies de session pour empêcher l’accès non autorisé. La définition de l’attribut Secure empêche le cookie de session d’être transmis en clair et ne permet qu’une transmission sur des connexions HTTPS. La définition de l’attribut Http-Only impose au navigateur de ne pas autoriser l’accès au cookie à partir du DOM ce qui empêche les attaques basées sur des scripts côté client d’accéder aux données sensibles stockées dans ces cookies.

Activez l’authentification multi-facteurs (MFA)

Ajoutez une couche supplémentaire de sécurité pour vérifier les utilisateurs. Il s’agit d’une méthode très courante que vous rencontrerez dans la plupart des applications sécurisées. Des intégrations faciles sont disponibles via des fournisseurs tels que Okta et Duo.

Implémenter l’expiration de session

Expirez automatiquement les sessions inactives pour réduire les fenêtres d’attaque.

Pratiques de codage et outils pour une sécurité de haut niveau

Scanning de vulnérabilités

Un scanner de vulnérabilités maintient la sécurité de votre application. Scanner vos bibliothèques, votre réseau, vos applications et vos appareils aide à découvrir les faiblesses que les attaquants pourraient exploiter. Des outils comme Snyk et Sonarqube peuvent être facilement intégrés dans des bases de code JavaScript. Ces outils fonctionnent en parallèle avec des listes connues de vulnérabilités maintenues par OWASP. Avec une intégration transparente dans le processus de développement, ces scanners offrent aux développeurs et aux équipes de sécurité une visibilité en temps réel et précise sur les vulnérabilités du code et des solutions pour les corriger.

Tests de pénétration et évaluations

Les développeurs peuvent adopter des pratiques de tests de pénétration pour sonder et exploiter activement les vulnérabilités potentielles au sein d’une application. Les hackers éthiques simulent des attaques du monde réel pour évaluer la posture de sécurité des applications web en manipulant le code JavaScript et les interactions utilisateur.

Pour ce faire, les développeurs peuvent écrire du code JS personnalisé pour simuler les scénarios, ou ils peuvent utiliser des outils spécialisés de test de pénétration qui exploitent JavaScript pour automatiser le processus d’analyse des vulnérabilités courantes telles que XSS, en utilisant OWASP ZAP. Plus d’informations sur les tests de pénétration sont disponibles dans le guide officiel de l’OWASP. 

Pare-feu d’application Web (WAF)

À mesure que les applications grandissent, le trafic web augmente, augmentant l’exposition aux attaques. La mise en place d’un Pare-feu d’application Web (WAF) aide à se protéger contre le trafic malveillant en filtrant et en surveillant les requêtes HTTP. Cela implique l’intégration avec des fournisseurs de WAF tiers tels que Cloudflare ou AWS WAF. Avec un WAF, vous pouvez définir des règles telles que : 

• Le pays ou la localisation géographique d’où proviennent les requêtes.
• L’adresse IP, la plage CIDR et les noms de domaine d’où proviennent les requêtes.
• Limite des longueurs de requête et des paramètres de requête pour prévenir les attaques par injection.
• Code SQL susceptible d’être malveillant. Les attaquants essaient d’extraire des données de votre base de données en intégrant un code SQL malveillant dans une requête web. C’est ce qu’on appelle une injection SQL.
• Détection et blocage des scripts intégrés qui peuvent faire partie d’attaques XSS.

Un WAF peut également aider à atténuer les attaques Distributed Denial of Service (DDoS), garantissant la disponibilité des applications.

Protéger l’intégrité des données

La mise en œuvre de mesures robustes d’intégrité des données est essentielle lors du stockage ou de l’accès à des informations sécurisées. Les meilleures pratiques incluent :

• Appliquer des politiques de mots de passe robustes et encourager l’utilisation de gestionnaires de mots de passe. De plus, encouragez vos utilisateurs à utiliser un gestionnaire de mots de passe afin qu’ils puissent utiliser des mots de passe plus complexes et n’aient pas à se soucier de les mémoriser (Utilisez LastPass ou 1Password).
• Protégez-vous contre les attaques par force brute sur les pages de connexion avec des limitations de taux, des verrouillages de compte après un certain nombre de tentatives infructueuses, et des défis CAPTCHA.
• En utilisant des en-têtes HTTP tels que :
  • HTTP Access-Control-Allow-Origin pour contrôler quels origines peuvent accéder aux ressources.
  • HTTP X-Content-Type-Options pour prévenir les risques de sécurité liés aux types MIME.
  • Intégrité des sous-ressources (SRI) pour garantir que les ressources des CDN ne sont pas altérées.

Conclusion

La sécurité JavaScript est un processus continu qui nécessite une approche proactive pour protéger les applications contre des menaces en constante évolution. La mise en œuvre de bonnes pratiques telles que la validation des entrées, les en-têtes CSP, la gestion sécurisée des sessions et la détection des vulnérabilités peut réduire considérablement le risque d’attaques comme XSS, CSRF et le détournement de session.

De plus, l’utilisation d’outils de sécurité tels que les WAF, les tests de pénétration et l’authentification multi-facteurs renforce la résilience des applications. Prioriser la sécurité à chaque étape du développement permettra aux développeurs de créer des applications robustes et dignes de confiance, qui restent protégées contre les cybermenaces modernes.