Images fournies par l'utilisateur sur un site HTTPS sans avertissements de contenu mixte

J'ai un forum où, comme la plupart des forums, les utilisateurs peuvent publier des images. J'ai configuré HTTPS sur le site, mais bien sûr, la plupart des images externes sont liées via HTTP, pas HTTPS. Ainsi, le chargement du forum via HTTPS affiche des avertissements de contenu mixtes, etc.

Quelles sont les stratégies pour résoudre ce problème? Certaines images proviennent de mon propre site, je peux donc réécrire ces URL pour utiliser HTTPS car je sais que cela fonctionnera. Mais pour les URL externes, beaucoup ne fonctionnent pas avec HTTPS, je ne peux donc pas réécrire une couverture.

Je pourrais réécrire des images non sécurisées en liens au lieu d'images en ligne, mais cela n'a pas l'air génial et peut être déroutant pour les utilisateurs. De meilleures solutions?

https images

— Chèvre mécontente
source

Vous pouvez utiliser le camouflage …

— wb9688

Google n'a pas résolu ce problème pour la recherche d'images. La recherche d'images n'est pas sécurisée: i.imgur.com/8XVTQsi.png

— Stephen Ostermiller

Voir aussi sur StackOverflow: Traiter le contenu HTTP dans les pages HTTPS

— Stephen Ostermiller

Mieux, je ne sais pas, et cela peut aller à l'encontre de la législation sur le droit d'auteur, mais une solution technique serait de faire une copie de l'image et de la diffuser à partir d'un domaine sous votre contrôle, via HTTPS ...

— un CVn le

La mauvaise façon de l'homme: lors de l'enregistrement / de la modification, vous pouvez appliquer une logique pour réécrire toutes les données qui sont destinées à être src="http://someimage.jpg"structurées à la src="//someimage.jpg"place ... ou simplement les valider. Si vous voulez un verrou vert strict (où une image non sécurisée ne gagnera pas votre verrou), appliquez HSTS. Ensuite, dans l'interface de l'éditeur, notez que les images doivent actuellement être disponibles via HTTPS, sinon elles n'apparaîtront pas du tout. Quelque chose comme "Oups, vous avez fait une erreur. Pour éviter les abus et les attaques MITM, tous les médias doivent utiliser HTTPS. Revenez en arrière et corrigez-le, ou choisissez un autre fournisseur d'images.".

— dhaupin

Réponses:

Il n'est pas possible d'avoir des ressources non sécurisées dans une page sécurisée et de ne pas recevoir l'avertissement de contenu mixte.

Pour les agents utilisateurs qui la prennent en charge, la upgrade-insecure-requestsdirective est une instruction pour tenter de charger la ressource via https ou échouer.

Les autres agents utilisateurs ignoreront la directive et continueront de charger les ressources non sécurisées.

Voici un article sur le site Google Developers traitant de cette option et d'autres.

— Robert K. Bell
source

Je viens de réaliser que je n'ai jamais posté ma solution. La réponse fournie dans le commentaire de Stephen est ce qui l'a résolu pour moi. En bref, j'ai créé un script proxy qui fait ce qui suit:

Si l'image est https, laissez-la tranquille.
Si l'image est http et d'un site connu pour prendre en charge https (par exemple mon propre site, imgur.com, etc.), réécrivez-le sur https.
Sinon, si l'image est http, réécrivez-la pour l'utiliser http://example.com/imgproxy?img=ORIGINALURL&hash=KEY

Le script proxy récupère ensuite l'image HTTP, la met en cache localement et génère les données d'image. Lors de demandes répétées, il génère directement les données mises en cache. La réponse SO liée décrit le hachage de sécurité et d'autres détails.

— Chèvre mécontente
source