Pourquoi ?

Sécuriser un site par connexion SSL apporte deux choses :
- cela empêche qu'on puisse intercepter et décoder une transmission entre le navigateur et le serveur Web
- cela garantit que le site visité est bien celui qu'il prétend être

Par exemple, une injection DNS (DNS poisoning) pourrait amener le navigateur sur un serveur différent, mais cela provoquerait un avertissement au niveau du navigateur parce qu'il est impossible de connaître la clef privée du serveur authentique.

Fonctionnement de la persistance HTTP

Comme le HTTP est stateless, Netscape a inventé les cookies pour stocker des informations persistantes entre plusieurs accès successifs. Voici comment cela fonctionne :

- Le navigateur effectue une première requête HTTP (GET ou POST par exemple) sur le serveur Web
- Le serveur retourne un cookie dans les entêtes HTTP, qu'il sauvegarde localement
- Le navigateur sauvegarde également ce cookie
- Aux connexions suivantes, le navigateur transmet son cookie
- Le serveur reconnaît le cookie, permettant d'identifier le navigateur

Le serveur Web a la possibilité de stocker diverses informations dans le cookie, comme le nom d'utilisateur, la date de dernière visite, ainsi de suite. Les informations contenues dans la session sont sécurisées parce qu'elles sont conservées localement sur le serveur ; le navigateur ne peut modifier les informations du cookie de session. Par contre, si le cookie est intercepté pendant sa transmission, une personne malveillante pourrait se faire passer pour l'utilisateur légitime et modifier son mot de passe ou visualiser les informations de son compte, par exemple.

Les pièges à éviter

Le problème réside dans la possibilité de pouvoir accéder simultanément au serveur Web en HTTP normal et SSL. En effet, on peut identifier les deux cas suivants qui pourraient entraîner la perte du cookie de session :

- L'application délivre en HTTP non sécurisé le cookie de session initial

Le cookie restera valide même si la suite de la navigation se fait par une connexion sécurisée.

- Le navigateur accède en HTTP non sécurisé après une navigation sécurisée

Le navigateur va alors transmettre son cookie, précédemment protégé, en clair sur le réseau.

Que faire ?

Il convient de suivre les consignes suivantes pour sécuriser la transmission du cookie de session :

- Empêcher l'application d'émettre son cookie en HTTP non sécurisé

On peut utiliser mod_rewrite pour imposer une redirection http:// vers https:// au niveau du serveur Web. De cette manière, l'application hébergée n'a jamais la possibilité de transmettre son cookie de façon non sécurisée.

- Envoyer ses cookies avec le flag secure

Ce flag informe le navigateur qu'il ne doit jamais divulguer son cookie si la connexion n'est pas sécurisée.

En PHP, on peut procéder comme ceci :



Attention : il est important de respecter l'ordre des commandes dans l'exemple précédent ; la fonction ini_set() doit d'exécuter avant session_start().

Conclusion

Assez simple : il ne faut pas se contenter d'activer mod_ssl pour sécuriser un site Web !

Historique

- Version intiale : 25/12/2009