Google sur le changement d'approche du traitement du contenu mixte sur les pages ouvertes via HTTPS. Auparavant, s'il y avait des composants sur les pages ouvertes via HTTPS et chargés sans cryptage (via le protocole http://), un indicateur spécial était affiché. À l'avenir, il a été décidé de bloquer le chargement de ces ressources par défaut. Ainsi, les pages ouvertes via « https:// » seront garanties de contenir uniquement des ressources téléchargées via un canal de communication sécurisé.
On constate qu'actuellement plus de 90 % des sites sont ouverts par des utilisateurs de Chrome via HTTPS. La présence d'inserts chargés sans cryptage crée des menaces de sécurité en modifiant le contenu non protégé s'il existe un contrôle sur le canal de communication (par exemple, lors d'une connexion via Wi-Fi ouvert). L’indicateur de contenu mixte s’est révélé inefficace et trompeur pour l’utilisateur, car il ne fournit pas une évaluation claire de la sécurité de la page.
Actuellement, les types de contenus mixtes les plus dangereux, tels que les scripts et les iframes, sont déjà bloqués par défaut, mais les images, fichiers audio et vidéos peuvent toujours être téléchargés via http://. Grâce à l'usurpation d'image, un attaquant peut remplacer les cookies de suivi des utilisateurs, tenter d'exploiter les vulnérabilités des processeurs d'image ou commettre une contrefaçon en remplaçant les informations fournies dans l'image.
La mise en place du blocage se déroule en plusieurs étapes. Chrome 79, prévu pour le 10 décembre, proposera un nouveau paramètre qui vous permettra de désactiver le blocage pour des sites spécifiques. Ce paramètre sera appliqué aux contenus mixtes déjà bloqués, tels que les scripts et les iframes, et sera appelé via le menu qui se déroule lorsque vous cliquez sur le symbole du cadenas, remplaçant l'indicateur proposé précédemment pour désactiver le blocage.
Chrome 80, attendu pour le 4 février, utilisera un système de blocage logiciel pour les fichiers audio et vidéo, impliquant le remplacement automatique des liens http:// par https://, ce qui préservera la fonctionnalité si la ressource problématique est également accessible via HTTPS. . Les images continueront à se charger sans modifications, mais si elles sont téléchargées via http://, les pages https:// afficheront un indicateur de connexion non sécurisée pour l'ensemble de la page. Pour passer automatiquement à https ou bloquer les images, les développeurs de sites pourront utiliser les propriétés CSP update-insecure-requests et block-all-mixed-content. Chrome 81, prévu pour le 17 mars, corrigera automatiquement http:// en https:// pour les téléchargements d'images mixtes.
De plus, Google à propos de l'intégration dans l'une des prochaines versions du navigateur Chome du nouveau composant Password Checkup, précédemment comme . L'intégration conduira à l'apparition dans le gestionnaire de mots de passe Chrome classique d'outils d'analyse de la fiabilité des mots de passe utilisés par l'utilisateur. Lorsque vous essayez de vous connecter à un site, votre identifiant et votre mot de passe seront vérifiés par rapport à une base de données de comptes compromis, avec un avertissement affiché si des problèmes sont détectés. La vérification est effectuée sur une base de données couvrant plus de 4 milliards de comptes compromis apparus dans des bases de données d'utilisateurs divulguées. Un avertissement s'affichera également si vous essayez d'utiliser des mots de passe triviaux tels que "abc123" (en Google (23 % des Américains utilisent des mots de passe similaires), ou lorsqu'ils utilisent le même mot de passe sur plusieurs sites.
Pour préserver la confidentialité, lors de l'accès à une API externe, seuls les deux premiers octets du hachage du login et du mot de passe sont transmis (l'algorithme de hachage est utilisé ). Le hachage complet est crypté avec une clé générée du côté de l'utilisateur. Les hachages originaux de la base de données Google sont également cryptés et seuls les deux premiers octets du hachage sont laissés pour l'indexation. La vérification finale des hachages qui relèvent du préfixe à deux octets transmis est effectuée du côté de l'utilisateur à l'aide de la technologie cryptographique "», dans lequel aucune des parties ne connaît le contenu des données vérifiées. Pour se protéger contre la détermination par force brute du contenu d'une base de données de comptes compromis avec une demande de préfixes arbitraires, les données transmises sont cryptées en relation avec une clé générée sur la base d'une combinaison vérifiée de login et de mot de passe.
Source: opennet.ru