web-dev-qa-db-fra.com

Les données seront-elles cryptées si une page HTTP envoie un message à un gestionnaire HTTPS qui le redirige vers HTTP?

Mon hôte m'a donné un sous-domaine de leur domaine qui a HTTPS:

https://mysite.example.com

Mon propre nom de domaine n'a pas de SSL installé. Par conséquent, la seule façon de tirer parti du cryptage consiste à utiliser l'adresse ci-dessus.

Je souhaite sécuriser la page d'inscription de mon site Web en mettant un formulaire sur mon site HTTP. Ce formulaire aura une action URL vers https://mysite.example.com/register_data. Ce gestionnaire de formulaire sera ensuite redirigé vers mon site Web HTTP.

Les utilisateurs ne verront jamais l'adresse HTTPS. Ils ouvriront l'adresse HTTP, mettront les données, soumettront les données et seront redirigés vers le site HTTP.

Les données soumises seront-elles sécurisées et cryptées normalement?

redirectshttpssecurity
6
Mateus Pires

Les données soumises seront-elles sécurisées et cryptées normalement?

Oui, lorsque les données sont envoyées de HTTP à HTTPS (via l'attribut action du formulaire) du formulaire, les données sont envoyées via une connexion cryptée. Cependant, l'utilisateur n'en sera probablement pas conscient et la "confiance utilisateur" fournie par HTTPS est donc inexistante.

... qui redirige vers HTTP?

La redirection (partie) vers HTTP ne sera évidemment pas chiffrée. Aucun mot de passe ne doit être renvoyé à ce stade. Cela ne devrait donc pas poser de problème, bien qu'un nom d'utilisateur puisse l'être si vous remplissez à nouveau le formulaire de connexion en cas d'échec? Mais tout cookie d'autorisation (ou de session) sera également renvoyé non crypté, ce qui pourrait potentiellement le renifler. (Bien que si un cookie d'autorisation est également validé par rapport à l'adresse IP des utilisateurs, il sera plus difficile à détourner, mais également à vos utilisateurs s'ils changent fréquemment d'adresse IP!)

5
MrWhite

Ce n'est pas sécurisé (mais c'est mieux que de poster sur HTTP). Les données ne seront cryptées que dans les cas où aucune attaque par un homme au milie n'est en cours, mais une des raisons pour proposer HTTPS est bien sûr l'hypothèse que de telles attaques MitM pourraient se produire.

Les attaquants seront en mesure de altérer votre page HTTP . Ils pourraient par exemple:

  • remplacez l'URL form-action par une autre sous leur propre contrôle (afin qu'ils récupèrent les données à votre place)
  • changez l'URL form-action de HTTPS à HTTP (afin que toutes les personnes qui l'écoutent puissent voir les données non chiffrées soumises)
  • injecter du code JavaScript qui leur donnera accès aux données saisies dans le formulaire (afin qu’elles obtiennent les données en plus de vous)

Pour vous protéger contre cela, la page d'enregistrement doit également être servie via HTTPS.¹

¹ Mais si vous utilisez uniquement HTTPS sur certaines pages et que vos utilisateurs ne vérifient pas s’ils utilisent actuellement le protocole HTTPS, les attaquants pourraient leur fournir une variante HTTP de la page d’enregistrement. La solution la plus simple consiste à appliquer HTTPS à l'ensemble du site + HSTS .

5
unor

La demande POST sera protégée par SSL, mais il y a d'autres problèmes à considérer:

  1. Lors du basculement entre HTTP et HTTPS, il est plus facile de faire une attaque SSL-Strip .
  2. L'identifiant de session sera également envoyé aux requêtes HTTP et pourra donc être facilement détecté.

C'est sûrement une bonne idée de passer à HTTPS pour l'ensemble du site, mais si cela est hors de question, vous pouvez au moins séparer les autorisations de la gestion de session:

  1. Utilisez un deuxième cookie pour l'autorisation et envoyez-le uniquement aux demandes HTTPS.
  2. Envoyez le cookie de session aux requêtes HTTP et HTTPS, mais utilisez-le uniquement pour gérer la session, pas pour l'autorisation.

Vous trouverez plus d'informations et un exemple sur mon page d'accueil .

3
martinstoeckli