Outils de développement · Calculateur de hachage SHA
Coller des secrets dans des outils de hachage en ligne : pourquoi le résumé devrait être local
· Pourquoi c'est important
sha-256 sécurité confidentialité API du navigateur
Si un outil de hachage envoie votre entrée à son serveur, le secret que vous hachiez a déjà quitté votre machine. Cet article explique le risque, comment Web Crypto rend un serveur inutile et comment vérifier qu'un outil est local.
La clé API que vous avez hachée pour la comparer à un fichier de configuration – et où elle est allée
Un développeur doit hacher une clé API pour la comparer à une valeur stockée dans la configuration, afin de pouvoir accéder à l'outil de hachage en ligne le plus proche. Ils collent la clé, cliquent sur le bouton et obtiennent le résumé. Le hachage correspond, donc le test réussit. Ce qu’ils ne réalisent probablement pas, c’est que la clé API a déjà quitté leur machine. Tout outil de hachage exécuté sur un serveur reçoit l'entrée en texte brut avant de calculer un résumé. Le serveur peut l'enregistrer, le stocker, le vendre ou le transmettre à des concurrents.
La tromperie est subtile car un outil de hachage peut véritablement produire une sortie correcte tout en envoyant l'entrée à un serveur. L'opération mathématique de hachage est indépendante de l'emplacement, de sorte qu'un hachage côté serveur est cryptographiquement correct même si l'architecture n'est pas sécurisée. Un attaquant n’a pas besoin de corrompre le calcul du hachage pour gagner ; ils ont juste besoin de l'entrée en texte brut. Un développeur qui suppose qu'un outil de hachage est local parce que le résultat est correct fait confiance à la mauvaise propriété.
Ce qu'un outil de hachage côté serveur reçoit : l'entrée en texte brut complet, par définition, avant le calcul d'un résumé
Un outil de hachage côté serveur nécessite l'entrée en texte brut comme entrée, par définition. Le serveur le reçoit via HTTPS, ce qui le protège pendant le transit, mais uniquement jusqu'à ce que le serveur soit atteint. Le texte brut est ensuite enregistré par le serveur, stocké en mémoire pendant le hachage, potentiellement écrit sur le disque et inclus dans toutes les sauvegardes ou traces de surveillance conservées par le serveur. La société qui gère le serveur peut lire les journaux et voir tous les secrets qui y ont été hachés.
L'alternative consiste à utiliser Web Crypto, qui est la propre implémentation cryptographique du navigateur. Sur une origine sécurisée, c'est-à-dire HTTPS ou localhost, le navigateur expose crypto.subtle.digest, une fonction qui calcule les résumés SHA-1, SHA-256, SHA-384 et SHA-512 entièrement dans le processus du navigateur. L'entrée ne quitte jamais l'appareil et aucun serveur n'est impliqué. L'implémentation du navigateur est auditée par les fournisseurs de navigateurs, corrigée par les fournisseurs de navigateurs et s'exécute sous forme de code natif optimisé plutôt que de code JavaScript fourni.
Pourquoi le serveur n'est pas nécessaire : le propre Web Crypto du navigateur calcule chaque résumé SHA-2 localement
Vérifier qu'un outil de hachage est local nécessite uniquement d'ouvrir le panneau réseau DevTools et de surveiller ce que l'outil envoie sur le réseau. Dans la plupart des navigateurs, DevTools s'ouvre avec F12 ou Cmd+Option+I et l'onglet Réseau permet de surveiller le trafic réseau. Avec l'onglet Réseau ouvert et l'outil de hachage visible, collez le texte brut, cliquez sur le bouton de hachage et regardez ce qui se passe. Si un outil local est utilisé, le panneau réseau n'affiche aucune nouvelle demande.
Cette méthode de vérification fonctionne car les navigateurs implémentent une restriction de même origine. La page peut envoyer des requêtes à sa propre origine sans déclencher de problèmes CORS, de sorte qu'un outil local pourrait envoyer des requêtes à un serveur du même domaine s'il le souhaitait. Lorsqu'une requête réseau apparaît dans le panneau DevTools, cela prouve que l'outil envoie des données quelque part. Un développeur qui vérifie cela et ne voit aucun trafic réseau a la certitude que l'entrée ne quitte pas le navigateur. Le calculateur de hachage ToolAcre SHA produit un panneau réseau qui reste vide lors du hachage.
Vérification avec le panneau réseau - coller, hacher et surveiller zéro requête
Une politique de sécurité du contenu stricte peut fournir une assurance supplémentaire au-delà de la vérification du panneau réseau. La politique de sécurité du contenu est un en-tête HTTP envoyé par le serveur, déclarant les domaines que le navigateur doit autoriser à charger des scripts et à effectuer des requêtes. Une politique qui interdit tous les scripts externes, toutes les feuilles de style externes et toutes les soumissions de formulaires à des origines externes limite ce qu'une page compromise peut faire. Un attaquant ne peut pas envoyer de code malveillant qui envoie l'entrée à un serveur externe si la politique interdit les requêtes externes.
Les en-têtes de stratégie de sécurité du contenu sont envoyés avec la réponse HTTP et peuvent être inspectés dans la section En-têtes de réponse de l'onglet Réseau DevTools. Une ligne comme Content-Security-Policy: default-src 'self'; script-src 'self' déclare que les scripts ne peuvent provenir que de la même origine. Une politique plus stricte qui inclut les ancêtres de frame « aucun » empêche la page d'être intégrée dans une iframe, ce qui bloque un vecteur d'attaque si une iframe malveillante tente de voler le focus. Ces détails sont utiles pour comprendre les défenses, mais la vérification du panneau réseau reste la principale vérification.
CSP est la défense en profondeur ; les sources du référentiel lues ici n'établissent pas l'en-tête déployé
Un exemple concret : coller une clé API d'AWS ou d'Azure dans le calculateur de hachage ToolAcre SHA pour la vérifier par rapport à une empreinte digitale stockée. Ouvrez DevTools, sélectionnez l'onglet Réseau et assurez-vous qu'il est en cours d'enregistrement. Collez la clé API dans l'outil de hachage, sélectionnez SHA-256 et cliquez sur hachage. Le résumé apparaît dans l'outil et le panneau réseau n'affiche aucune nouvelle demande. Le vecteur de test est disponible dans la documentation de l'outil pour vérifier l'exactitude du hachage si nécessaire. Le point clé est que la clé API n’a jamais quitté le navigateur et que le résumé peut désormais être comparé à une valeur stockée sans jamais exposer le secret.
Ce flux de travail ne couvre pas si une extension de navigateur a été compromise ou si le navigateur lui-même a été compromis. Une extension malveillante dotée d'autorisations étendues peut voir tout le trafic, intercepter le contenu du presse-papiers et observer ce que l'utilisateur tape. Un navigateur compromis, soit par une vulnérabilité Zero Day, soit par une installation malveillante, peut être forcé d'envoyer l'entrée n'importe où. Aucun outil Web ne peut offrir de protection contre ces menaces. La défense appropriée consiste à faire confiance à l’installation du navigateur, à le maintenir à jour et à examiner les extensions installées.
Exemple concret : utilisez un marqueur inoffensif et inspectez les requêtes plutôt que de coller une clé API en direct
Le conseil à quiconque colle des secrets dans des outils est de vérifier que l'outil est local avant de le coller. Il s'agit d'une étape simple qui élimine le risque le plus important : l'opérateur du serveur, ses employés, ses sauvegardes et ses journaux voient tous le texte en clair. Utilisez le panneau réseau DevTools, surveillez zéro requête, puis faites confiance à l'outil avec le secret. Le calculateur de hachage ToolAcre SHA est conçu pour être utilisé de cette façon. Il ne stocke rien, ne télécharge rien et le panneau Réseau reste vide.
Pour les développeurs qui ont déjà collé des secrets dans des outils côté serveur, l'étape suivante consiste à alterner ces secrets. Une clé API envoyée à un serveur inconnu doit être considérée comme compromise. Il doit être révoqué et un nouveau doit être délivré. Les mots de passe doivent être modifiés. Les clés SSH doivent être remplacées. Pour les secrets statiques tels que les clés API d'infrastructure, il s'agit d'une opération unique. Pour les jetons de session ou les informations d'identification temporaires, la rotation se produit automatiquement à mesure que les jetons expirent.
Ce que cela ne couvre pas : les extensions de navigateur et les machines compromises, contre lesquelles aucun outil Web ne peut se défendre
Instaurer la confiance dans les outils en ligne commence par comprendre où se déroule le calcul et vérifier cette compréhension avec les outils de développement du navigateur. Le panneau réseau est un signal clair : si des données quittent le navigateur, elles y apparaîtront. Si aucune demande ne contient l'entrée de test distinctive, cette session fournit la preuve d'un chemin de conversion local. Il ne s'agit pas d'une garantie concernant les extensions, le code du navigateur compromis ou les déploiements futurs. La combinaison de cette vérification avec l’examen du code source, s’il est disponible, donne confiance.
Pour les organisations évaluant les outils cryptographiques destinés à être utilisés avec des données sensibles, le principe reste le même : vérifiez que le calcul a lieu là où vous le contrôlez. Pour les personnes qui hachent une clé API ou vérifient un fichier, utilisez d'abord la vérification du panneau réseau. Pour les systèmes de production, utilisez HMAC ou des signatures au lieu de hachages simples pour l'authentification. Le calculateur de hachage ToolAcre SHA est un outil d'apprentissage et de calcul de résumé local. Il n'est pas approprié pour l'authentification de production.
À retenir : vérifiez, puis faites confiance – le calculateur de hachage ToolAcre SHA s'exécute dans votre navigateur, ne télécharge rien et ne stocke rien entre les visites
Le principe de transparence est au cœur de l'approche ToolAcre : chaque outil documente ce qu'il fait, ce que propose le navigateur et ce que le développeur doit faire. Le calculateur de hachage SHA indique qu'il utilise l'implémentation Web Crypto du navigateur pour SHA-256, SHA-384 et SHA-512, et qu'il n'implémente pas HMAC ou dérivation de clé. Pour le hachage, l'outil est précis. Pour l'authentification, les développeurs doivent chercher ailleurs. Cette clarté évite la confusion qui survient lorsqu’un seul outil essaie d’en faire trop.
Lorsqu'un développeur voit que le panneau réseau est vide et que le code source est ouvert, la relation de confiance repose sur des bases solides. L'outil fait ce qu'il prétend : calculer les hachages localement en utilisant la propre implémentation du navigateur. Le développeur peut alors prendre une décision éclairée quant à savoir si l’outil correspond à son cas d’utilisation. Pour vérifier une clé API, cela convient parfaitement. Pour l’authentification de production, HMAC est nécessaire. Pour le stockage des mots de passe, une fonction de dérivation de clé comme Argon2id est nécessaire. Connaître ces limites est la première étape vers la création de systèmes sécurisés.