web-dev-qa-db-fra.com

Les domaines qui ne font que des redirections (alias de minuscules URL) devraient-ils être chiffrés (https)?

Pour cette question, j'utiliserai les domaines suivants:

  • example.com - une boutique en ligne
  • exmpl.com - un domaine utilisé pour partager des éléments.

exmpl.com sera utilisé pour les redirections (par exemple, http://exmpl.com/foo redirigera vers https://example.com/items/42).

J'ai les questions suivantes:

  • Est-il important que exmpl.com doit être chiffré?
  • Est-ce important du tout s'il a https ou seulement http?
  • Bien sûr, s'il n'a pas https, celui qui tente d'accéder à https://exmpl.com ne pourra pas le faire, mais y a-t-il des effets secondaires?
  • D'un autre côté, pourquoi une entreprise préférerait-elle prendre en charge uniquement http dans ce contexte?
tlshttpurl-redirection
31
Ionică Bizău

Les sites de redirection doivent-ils utiliser HTTPS

Si le site principal utilise HTTPS, le site de redirection devrait également.

Quelles attaques sont possibles si ce n'est pas le cas

Attaquant passif

  • Peut voir chaque élément consulté par l'utilisateur
  • Peut obtenir des informations supplémentaires (quel site/chat lié à la page)

Attaquant actif

Tout ce qu'un attaquant passif peut et ...

  • Peut MITM la connexion et utiliser quelque chose comme SSLStrip pour empêcher la mise à niveau de la connexion vers HTTPS, permettant ensuite de regarder les mots de passe, les numéros de carte de crédit, etc.
  • Peut ajouter un cookie à la réponse, leur permettant de suivre un utilisateur
  • Peut rediriger le trafic vers un site de phishing ou un site qui installe des logiciels malveillants.

Comment empêcher complètement l'utilisation de HTTP, pour arrêter des outils comme SSLStrip

  • Vous pouvez servir un en-tête HSTS, donc seule la première visite (et la première visite une fois l'en-tête expiré) utilisera HTTP, donc un attaquant ne peut pas intercepter le trafic
  • Si vous souhaitez éviter ces faiblesses, vous pouvez ajouter votre site à la HSTS Preload List , ce qui empêchera les connexions HTTP.
  • Cela devrait s'appliquer aux deux sites, comme si le site principal était HSTS mais la redirection, puis l'attaquant pourrait rediriger vers un site qu'il contrôle à la place, en contournant HSTS.

Dois-je utiliser HTTPS

Généralement, [~ # ~] oui [~ # ~]

Il y a très peu d'occasions où vous pouvez vous en sortir sans utiliser HTTPS, toutes ces conditions doivent s'appliquer:

  • Vous signez manuellement vos données - et vérifiez toujours la signature

  • Peu vous importe que des personnes découvrent que votre logiciel s'exécute sur la machine de quelqu'un

  • Vous ne gérez aucune information sensible ou les utilisateurs peuvent vouloir garder le secret
  • Vous ne recevrez pas accidentellement des informations sensibles sur votre système
    • Un exemple serait ACARS, il n'était pas destiné à des informations sensibles, mais des numéros de carte de crédit ont été envoyés dessus sans se rendre compte des problèmes causés. [ forum , papier ]
  • Vous ne vous souciez pas ou pouvez détecter si quelqu'un échange les fichiers en utilisant d'autres fichiers signés valides
  • Le service n'implique pas de données sensibles (une page sur une maladie peut ne pas être sensible, mais le fait qu'une personne effectue une recherche sur la maladie peut être sensible).
47
jrtapsell

Il y a très peu de cas où l'utilisation de HTTP simple et non de HTTPS est une bonne idée. Ce n'est probablement pas l'un d'entre eux.

Considérez ce scénario: un utilisateur clique sur un lien vers http://exmpl.com/foo, en espérant acheter de nouveaux foo. Un homme au milieu intercepte la demande et répond par une copie de phishing de https://example.com/items/42 au lieu d'une redirection vers la légitime. L'utilisateur, paresseux comme les utilisateurs, ne vérifie pas vers quelle URL il a été redirigé - après tout, il savait qu'il avait cliqué sur le bon lien. Au lieu de cela, il procède à la saisie des détails de sa carte de crédit sur le site de phishing. Il pense qu'il achète du foo sur un site légitime, alors qu'en fait il se fait arnaquer.

Bien sûr, l'utilisateur a fait une erreur ici. Mais c'est une erreur qui n'aurait pas eu d'importance si vous n'aviez utilisé que le HTTPS.

8
Anders

Lorsque l'utilisateur est soucieux de la confidentialité, il peut vouloir minimiser la quantité de données qu'une écoute indiscrète peut collecter à son sujet. Lorsque vous utilisez HTTPS, la demande entière est cryptée. L'espionne sait seulement à quel serveur l'utilisateur a accédé et (approximativement) combien de données ont été échangées.

Lorsque exmpl.com n'utilise pas HTTPS, l'écouteur sait:

  • Objet consulté http://exmpl.com/foo
  • Le sujet a reçu une redirection http vers https://example.com/items/42
  • Le sujet a accédé à une URL inconnue (mais désormais facile à déduire) sur le domaine example.com
  • Le sujet a reçu une longue réponse cryptée

Lorsque vous utilisez HTTPS, tout attaquant sait:

  • Le sujet a accédé à une URL inconnue sur le domaine exmpl.com
  • Le sujet a reçu une courte réponse cryptée
  • Le sujet a accédé à une URL inconnue sur le domaine example.com
  • Le sujet a reçu une longue réponse cryptée

L'attaquant n'apprend pas qui redirige l'utilisateur utilisé et n'apprend donc pas que l'utilisateur a visité items/42. L'attaquant ne peut pas non plus être sûr que ces deux accès étaient liés.

7
Philipp