Je suis tombé sur ce site Web (gouvernement) qui devrait être sécurisé par HTTPS, mais Chrome n'affiche pas le verrou vert. Au lieu de cela, il montre ceci:
Qu'est-ce que ça veut dire? Comment les attaquants peuvent-ils exploiter cette vulnérabilité?
La page que votre navigateur affiche à l'écran peut comprendre de nombreux éléments: le code HTML, CSS, des images, etc. Une partie du contenu peut également être fournie, améliorée ou modifiée par des scripts (légitimes) téléchargés à partir du site. Ces éléments peuvent être inclus à partir du même serveur ou d'autres serveurs.
Pour Chrome pour afficher le message "Votre connexion à ce site est privée", pour chaque élément de la page:
Si un ou plusieurs des éléments sont inclus via un lien HTTP non chiffré, alors:
s'il s'agit d'un script, Chrome affichera un message:
Votre connexion à ce site n'est pas privée car le site a chargé un script non sécurisé.
Dans ce cas, il est possible que le script ait été remplacé par un script malveillant. Toutes les données que vous recevez du site ou envoyées sur le site peuvent être interceptées et modifiées.
s'il s'agit (uniquement) d'un contenu passif (comme une image), Chrome affichera un message:
Votre connexion à ce site est privée, mais quelqu'un sur le réseau pourrait être en mesure de modifier l'apparence de la page.
Dans ce cas, personne ne serait en mesure de flairer vos données ou de lire les informations fournies par le site. Cependant, en modifiant l'apparence de la page, vous pourriez être amené à effectuer une action que vous n'aviez pas l'intention de faire, par exemple, réinitialiser votre mot de passe. Bien que le changement de mot de passe lui-même soit sécurisé et légitime, il pourrait bénéficier à l'attaquant.
De plus, ce message n'est pas précis à 100%. En fonction du contenu passif réel inclus, un attaquant passif peut en déduire les actions que vous avez effectuées sur le site crypté. Contrairement à HTTPS, avec HTTP, l'URL complète serait visible, donc si une certaine page chargeait un ensemble unique d'icônes, un attaquant pourrait vous dire que vous avez atteint cette page.
réponse de techraf a une grande explication générale, je veux juste ajouter la cause directe dans la page que vous avez identifiée dans votre commentaire :
L'avertissement que Chrome vous donne est un peu déroutant, mais le problème spécifique sur cette page est le bouton Rechercher en haut, qui fait partie d'un formulaire qui contient un point de terminaison non HTTPS:
<form action="http://www.uscis.gov/portal/site/uscis/menuitem/"
method="get" name="searchForm">
...
<input type="image" name="submit"
src="images/branding/searchButton.gif"
id="uscisSearchBtn" title="Search">
</form>
Chrome se plaint de la cible HTTP de ce formulaire.
La façon dont vous pouvez le découvrir est:
Voici ma tentative d'enregistrer ce processus dans un GIF animé (cliquez dessus pour le voir en pleine résolution):
Désolé, je ne sais pas quels risques sont associés à cela, mais c'est au moins la source précise de l'avertissement de Chrome. J'espère que cela pourra aider.
Cela signifie que le site a chargé les ressources http demandées sur un lien https. Un attaquant pourrait manipuler les ressources http et attaquer à travers celles-ci. Si vous ouvrez la console, vous verrez de nombreux avertissements de contenu mixte, qui l'expliquent.
Référence: https://productforums.google.com/forum/#!topic/chrome/NLTAR28lq
Si vous appuyez sur la console Chrome console, vous verrez ceci:
Contenu mixte: la page à ' https://egov.uscis.gov/crisgwi/go?action=offices ' a été chargée via une connexion sécurisée, mais contient un formulaire qui cible un point de terminaison non sécurisé '- http://www.uscis.gov/portal/site/uscis/menuitem.5600b9f6b2899b1697849110543f6d1a/ '. Ce point de terminaison doit être mis à disposition via une connexion sécurisée.
L'inspection de cette URL révèle qu'il s'agit du <action>
Pour un <form>
Envoyé via http://
<form action="http://www.uscis.gov/portal/site/uscis/menuitem.5600b9f6b2899b1697849110543f6d1a/" method="get" name="searchForm"><label for="criteria" class="s508"><span>Search</span></label><input type="text" id="criteria" onblur="setSearchField(document.searchForm, this);" title="Enter search terms" onfocus="clearSearchField(this);" maxlength="50" value="Search" name="searchQuery"><input type="image" name="submit" src="images/branding/searchButton.gif" id="uscisSearchBtn" title="Search"></form>
En ce qui concerne la raison pour laquelle il dit "pourrait être en mesure de changer l'apparence" - c'est probablement un message générique déclenché lorsque des éléments non sécurisés sont présents. La plupart du temps, il s'agit de médias, css ou js. Dans ce cas, c'est un <form>
.
Si une ressource/ressource/appel/etc est demandé via HTTP, aucun chiffrement n'est appliqué. Cela signifie que n'importe qui "au milieu" peut écouter, récupérer les données, les atténuer et les transmettre. Si les données étaient cryptées, et en utilisant des chiffres, un secret et un TLS appropriés, ils ne pourraient pas écouter et s'ils le faisaient, ils ne "verraient" pas les vraies données.
En fait, ce problème (contenu mixte) peut parfois être très dangereux.
Supposons que vous ayez un site https://example.com/ avec une authentification très fiable, et tout passe sur HTTPS très fiable sauf une petite image qui est utilisée dans une page (peut-être très rarement utilisée) par son http (pas https). par exemple. http://example.com/img/hackme.png ( problème A )
Supposons maintenant que le cookie de session (qui est donné après une authentification réussie) soit utilisé sans attribut "sécurisé". Ce n'est pas très bon, mais assez sûr tant que nous n'avons pas de contenu mixte. ( problème B )
Maintenant, si nous avons à la fois le problème A + le problème B sur le même site, lorsque vous ouvrez une page Web avec un contenu mixte sur https://example.com/ , le navigateur demandera cette image sur HTTP et HTTP aura tous les cookies non sécurisés pour le domaine example.com. Ainsi, MITM peut renifler la chose la plus importante qui pourrait être reniflée sur le réseau - cookie d'authentification à partir des en-têtes de requête http (et reniflera également cette image inutile du corps de réponse http, ce n'est vraiment pas un problème. Le problème est dans le cookie). Maintenant, il peut utiliser n'importe quel addon de navigateur de gestionnaire de cookies pour définir son cookie sur une valeur reniflée et il sera connecté à ce site.
C'est la situation ' deux verrous'. Lorsqu'au moins l'un d'eux est verrouillé - la porte est verrouillée. Mais si les deux verrous sont piratés, la porte est ouverte.