Secrets in Source 2 : contourner la sécurité par l'obscurité

Les contrôles de sécurité côté client sont l'une des idées fausses les plus persistantes dans le développement web. Lorsqu'un site tente de protéger son code source en désactivant le clic droit, en bloquant les raccourcis clavier ou en détectant les outils de développement, il pratique la sécurité par l'obscurité : un faux sentiment de sécurité qu'un utilisateur expérimenté contourne en quelques secondes. Comprendre pourquoi ces contrôles échouent est essentiel pour les développeurs qui pourraient s'y fier par erreur comme pour les professionnels de la sécurité qui les rencontrent lors des évaluations.

Qu'est-ce que la sécurité par l'obscurité ?

La sécurité par l'obscurité consiste à s'appuyer sur le secret d'une conception ou d'une implémentation comme protection principale, au lieu d'un véritable contrôle d'accès. Cacher un fichier derrière une URL impossible à deviner, minifier du JavaScript ou bloquer le menu contextuel en sont autant d'exemples. L'information est toujours là ; elle est seulement un peu plus difficile à voir. Dès que quelqu'un regarde au-delà de l'obscurité, la protection disparaît, raison pour laquelle on la considère comme une faiblesse plutôt qu'une défense.

Pourquoi les protections côté client échouent toujours

Le principe qui rend toute protection côté client inefficace est simple : tout code, donnée ou contenu livré à un navigateur est sous le contrôle total de l'utilisateur. Le JavaScript qui désactive le clic droit est annulé en désactivant JavaScript. Les scripts de détection des DevTools sont contournés avec d'autres méthodes de débogage. L'interception du clavier échoue lorsque la même action est disponible via un menu du navigateur, un bookmarklet ou une extension. Le navigateur est le logiciel de l'utilisateur, pas celui du serveur.

Les techniques de "protection" courantes incluent le remplacement de l'événement contextmenu pour bloquer le clic droit, l'interception des événements clavier pour Ctrl+U, F12 et Ctrl+Shift+I, l'utilisation d'une instruction debugger pour geler les DevTools, la surveillance de la taille de la fenêtre pour deviner si les DevTools sont ouverts, et l'obfuscation des scripts pour ralentir la lecture. Chacune de ces techniques possède plusieurs contournements documentés.

Comment fonctionne ce lab

Ce lab pratique HackerDNA vous dépose sur un site vitrine arrogant et "sécurisé" et vous demande de lire le code source qu'il s'efforce de cacher. Vous pratiquez les contournements qu'un testeur utilise vraiment : le schéma view-source: qui affiche le HTML brut avant l'exécution des scripts, des outils en ligne de commande comme curl et wget qui n'exécutent jamais de JavaScript, et le simple fait de désactiver JavaScript. Un développeur a laissé un commentaire pointant vers un fichier qu'il a oublié de protéger ; vous le suivez, demandez le fichier directement et capturez le flag, en découvrant au passage l'information disclosure et le broken access control.

Pourquoi c'est important

Reconnaître la sécurité par l'obscurité est une compétence fondamentale en sécurité web. Les secrets, les identifiants et la logique métier doivent résider sur le serveur, derrière une véritable authentification et autorisation. Tout ce qui est envoyé au navigateur doit être traité comme public, car il l'est. Entraînez-vous à repérer cette erreur ici sur HackerDNA avant de la rencontrer lors d'une mission réelle.