Si l'utilisateur est sujet à une attaque, c'est contrecarré par le fait que le cookie de session HTTPS ne sera lu côté serveur que si la connexion est bien en HTTPS, donc même si l'attaque réussi à forger des requêtes avec le navigateur de l'utilisateur, elle ne pourra pas pour autant prendre son identité, puisqu'une requête aboutissant en HTTP ne permettra pas au code malicieux de faire quoi que ce soit. Et puis finalement tout ce que ça pourra faire est une infinite redirect loop, puisqu'en bloquant la redirection puis en tapant de nouveau le serveur, il redirigera de nouveau, etc… Si vraiment le hacker vire le cookie non secure et tente une action sur le site, le site sait que la connexion à la base provient d'une session HTTPS et n'identifiera normalement pas l'utilisateur en HTTP, encore une fois.
[^] # Re: Redirection ?
Posté par Christie Poutrelle (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 0.
Si l'utilisateur est sujet à une attaque, c'est contrecarré par le fait que le cookie de session HTTPS ne sera lu côté serveur que si la connexion est bien en HTTPS, donc même si l'attaque réussi à forger des requêtes avec le navigateur de l'utilisateur, elle ne pourra pas pour autant prendre son identité, puisqu'une requête aboutissant en HTTP ne permettra pas au code malicieux de faire quoi que ce soit. Et puis finalement tout ce que ça pourra faire est une infinite redirect loop, puisqu'en bloquant la redirection puis en tapant de nouveau le serveur, il redirigera de nouveau, etc… Si vraiment le hacker vire le cookie non secure et tente une action sur le site, le site sait que la connexion à la base provient d'une session HTTPS et n'identifiera normalement pas l'utilisateur en HTTP, encore une fois.