Chrome commencera à bloquer les ressources HTTP sur les pages HTTPS et vérifiera la fiabilité des mots de passe

La société Google prévenu sur le changement d'approche concernant le traitement du contenu mixte sur les pages ouvertes en HTTPS. Auparavant, la présence de composants chargés sans cryptage (via le protocole http://) sur les pages ouvertes en HTTPS entraînait l'affichage d'un indicateur spécial. À l'avenir, il a été décidé de bloquer par défaut le chargement de tels ressources. Ainsi, les pages ouvertes en « https:// » contiendront garantis uniquement des ressources chargées via un canal de communication sécurisé.

Il est noté qu'actuellement plus de 90 % des sites sont ouverts par les utilisateurs de Chrome en utilisant HTTPS. La présence d'inserts chargés sans cryptage crée des menaces de violation de la sécurité par la modification de contenu non sécurisé en cas de contrôle de la liaison (par exemple, en se connectant via des Wi-Fi ouverts). L'indicateur de contenu mixte est jugé 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 contenu mixte les plus dangereux, tels que les scripts et les iframe, sont déjà bloqués par défaut, mais les images, les fichiers audio et les vidéos peuvent toujours être chargés via http://. En remplaçant des images, un attaquant peut insérer des cookies de suivi des actions de l'utilisateur, tenter d'exploiter des vulnérabilités dans les gestionnaires d'images ou falsifier en remplaçant les informations présentées sur l'image.

L'introduction du blocage est divisée en plusieurs étapes. Dans Chrome 79, prévu pour le 10 décembre, un nouveau paramètre sera introduit, permettant de désactiver le blocage pour des sites spécifiques. Ce paramètre s'appliquera au contenu mixte déjà bloqué, tel que les scripts et les iframes, et sera accessible via un menu déroulant en cliquant sur le symbole de cadenas, remplaçant l'indicateur précédemment proposé pour désactiver le blocage.

Dans Chrome 80, qui est prévu pour le 4 février, un schéma de blocage doux sera appliqué aux fichiers audio et vidéo, ce qui impliquera le remplacement automatique des liens http:// par https://, permettant ainsi de maintenir la fonctionnalité si la ressource problématique est également accessible via HTTPS. Les images continueront à se charger sans changements, mais en cas de chargement via http:// sur les pages https://, un indicateur de connexion non sécurisée commencera à s'afficher pour l'ensemble de la page. Pour le remplacement automatique vers https ou le blocage des images, les développeurs de sites pourront utiliser les propriétés CSP upgrade-insecure-requests et block-all-mixed-content. Dans la version Chrome 81, prévue pour le 17 mars, un remplacement automatique sera appliqué pour le chargement d’images mixtes, remplaçant http:// par https://.

De plus, la société Google a annoncé a annoncé l'intégration dans l'une des prochaines versions du navigateur Chrome d'un nouveau composant Password Checkup, précédemment développé sous forme d'extension externe. L'intégration entraînera l'ajout dans le gestionnaire de mots de passe de Chrome d'outils pour analyser la fiabilité des mots de passe utilisés par l'utilisateur. Lors de la tentative de connexion à tout site, une vérification du nom d'utilisateur et du mot de passe sera effectuée contre une base de données de comptes compromis, avec un avertissement affiché en cas de problèmes détectés. La vérification est effectuée sur une base de données couvrant plus de 4 milliards de comptes compromis ayant été exposés dans des fuites de bases de données utilisateurs. Un avertissement sera également affiché lors de l'utilisation de mots de passe trivials tels que « abc123 » (selon Google, 23 % des Américains utilisent de tels mots de passe), ou lors de l'utilisation du même mot de passe sur plusieurs sites. les statistiques Pour préserver la confidentialité lors de l'accès à une API externe, seuls les deux premiers octets du hachage de la combinaison du nom d'utilisateur et du mot de passe sont transmis (l'algorithme de hachage utilisé est

Argon2 ). Le hachage complet est crypté avec une clé générée côté utilisateur. Les hachages d'origine dans la base de Google sont également chiffrés et seuls les deux premiers octets du hachage sont conservés pour indexation. La vérification finale des hachages correspondant au préfixe de deux octets transmis se fait côté utilisateur à l'aide de la technique cryptographique de «l’obscurcissement.«, où aucune des parties ne connaît le contenu des données vérifiées. Pour se protéger contre l'identification du contenu de la base de données des comptes compromis par la tentative de requêtes avec des préfixes aléatoires, les données fournies sont cryptées en lien avec une clé générée sur la base de la combinaison vérifiée du login et du mot de passe.

Source : opennet.ru