Google Chrome
Google a mis en garde contre un changement d'approche de la gestion du contenu mixte sur les pages ouvertes via HTTPS. Précédemment, s'il y avait des composants sur des pages ouvertes avec HTTPS chargé sans cryptage (en utilisant le protocole http: //), une invite spéciale a été affichée.
Désormais, pour les prochaines versions du navigateur, il a été décidé de bloquer le chargement de ces ressources par défaut. On s'assurera donc que les pages ouvertes via "https: //" ne contiennent que des ressources chargées via un canal de communication sécurisé.
On constate qu'actuellement les utilisateurs de Chrome ouvrent plus de 90% des sites en HTTPS. La présence d'inserts téléchargés sans cryptage crée une menace de faille de sécurité via la modification de contenu non sécurisé en présence d'un contrôle sur le canal de communication (par exemple, lors de la connexion via Wi-Fi ouvert).
L'indicateur de contenu mixte est reconnu comme inefficace et trompeur, car il n'offre pas une évaluation sans équivoque de la sécurité de la page.
Actuellement, les types de contenu mixte les plus dangereux, comme les scripts et les iframes, sont déjà bloqués par défaut, mais les images, les fichiers audio et les vidéos peuvent toujours être téléchargés via «http: //».
En substituant des images, l'attaquant peut substituer des actions de suivi des cookies, tenter d'exploiter les vulnérabilités des processeurs d'images ou commettre une falsification, en remplaçant les informations présentées dans l'image.
L'introduction du blocus se divise en plusieurs étapes. Dans Chrome 79 (qui est prévu pour le 10 décembre), Un nouveau paramètre apparaîtra qui désactivera le blocage de sites spécifiques.
Les paramètres spécifiés seront appliqués au contenu mixte déjà bloqué, tels que les scripts et les iframes, et seront activés via le menu qui apparaît lorsque vous cliquez sur le symbole de verrouillage, remplaçant l'indicateur précédemment proposé pour désactiver le verrouillage.
Alors que pour Chrome 80 (attendu le 4 février) un schéma de blocage sera utilisé pour les fichiers audio et vidéo, ce qui implique un remplacement automatique de http: // à https: //, ce qui le maintiendra en fonctionnement si la ressource problématique est également disponible via HTTPS.
Les images continueront d'être téléchargées sans modification, mais en cas de téléchargement via http: // sur les pages https: // pour toute la page, un indicateur d'une connexion non sécurisée sera initié. Pour le remplacement automatique par https ou des images de bloc, les développeurs de sites pourront utiliser les propriétés CSP mises à jour non sécurisées et bloquer tout le contenu mixte.
Le lancement de Chrome 81, prévue le 17 mars utilisera la correction automatique de http: // à https: // pour les téléchargements d'images mixtes.
De plus, Google a annoncé intégration dans l'une des prochaines versions du navigateur Chome, un nouveau composant de Vérification du mot de passe, précédemment développé en tant que plugin externe.
L'intégration conduira à l'apparition dans le gestionnaire de mots de passe à temps plein Outils Chrome d'analyser la fiabilité des mots de passe utilisés par l'utilisateur. Lorsque vous essayez d'accéder à un site, le nom d'utilisateur et le mot de passe seront vérifiés par rapport à la base de données des comptes compromis avec un avertissement en cas de problèmes.
La validation est effectuée sur une base de données qui couvre plus de 4 milliards de comptes compromis qui sont présentés dans des fuites de bases de données d'utilisateurs. Un avertissement sera également affiché lors de l'utilisation de mots de passe triviaux tels que "abc123" (statistiques Google 23% des Américains utilisent ces mots de passe), ou lorsqu'ils utilisent le même mot de passe sur plusieurs sites.
Pour préserver la confidentialité, lors de l'accès à l'API externe, seuls les deux premiers octets du hachage sont transférés de la connexion à partir du login et du mot de passe (l'algorithme Argon2 est utilisé pour le hachage). Le hachage complet est chiffré avec une clé générée par l'utilisateur.
Les hachages d'origine dans la base de données Google sont également chiffrés en plus et seuls les deux premiers octets du hachage restent pour l'indexation.
Pour éviter de déterminer le contenu de la base de données des comptes compromis en énumérant avec des préfixes aléatoires, les données renvoyées sont chiffrées par rapport à la clé générée sur la base du lien de connexion et de mot de passe vérifié.
source: https://security.googleblog.com