[Cookies] Sécurité avec les sessions et actions importantes

[Jihnn]

Bonjour,

Je suis en pleine programmation d'un petit projet personnel. Possibilité de se créer un compte, de poster des news, des commentaires, etc.

Je travaille beaucoup avec les sessions, et j'ai justement une variable session qui me donne le flag de mon utilisateur connecté. Par exemple, si le flag est x, l'utilisateur est un admin.
L'admin peut poster, modifier ou effacer des news. Il peut aussi effacer les commentaires des utilisateurs.

Vous comprenez, j'ai un peu peur pour la sécurité de mon site. J'ai l'impression qu'une personne malveillante pourrait tout à fait voler ma session, ou celle d'un supermodérateur, pour modifier le site. Bon, on s'entend, modifier les news ou effacer des commentaires, c'est pas super grave, mais c'est pour le principe.

J'ai lu le début du tutoriel de sécurité des sessions (avec la BDD).

Question #1: Est-ce que j'ai vraiment à m'en faire à propos des sessions ?
Question #2: Si oui, est-ce qu'ajouter une fonction à la page de connexion pour ajouter la session à la BDD, et enlever l'entrée à la déconnexion, est assez ?

Merci d'avance,

Jihnn

[Sayrus]

Normalement c'est bon.

Si par exemple tu utilises les cookies, là tu peux t'inquiéter et vérifier qu'il n'y a pas de failles XSS sur ton site.

[Fladnag]

une session EST un cookie. Plus précisement, l'ID de session est stockée dans un cookie. Se faire voler le cookie c'est se faire voler la session.

Dejà, plusieurs choses :

* Soit tes admin doivent se relogger a chaque fois => dans ce cas la le cookie a une durée de vie tres limitée (limité au seul temps de connection sur le site, le risque est faible)
* Soit tu autorise une fonction "se souvenir de moi" et dans ce cas là tu augmente le risque, puisque le cookie peut persister 1 jour, 1 semaine, 3 mois, 2 ans... selon ce que tu parametre

Ensuite, tu as 4 cas de vols je dirais :
* L'acces physique a la machine. Tu peux pas y faire grand chose, mais le risque est faible, sauf en cas d'utilisation d'une machine publique (cyber café, etc...). Dans tout les cas, éviter de mettre l'ID de session en parametre d'une URL... tout passer dans des cookies c'est quand meme mieux
* Le "man in the middle" : En gros un gars qui va sniffer les paquets qui passe et récuperer toutes les infos... si tu n'as pas un chiffre d'affaire de quelques millions avec 300 concurrents, le risque se limite a l'apprenti hacker qui veux se faire les dents... mais ca demande trop de matos pour lui (a moins d'etre sur un reseau local ;o)
* La faille exploitée par un pirate
Tu as une faille sur ton site qui permet de voler ton ID de session. echo $_GET['toto']; par exemple (et oui, c'est une faille ^^). Une personne mal intentionnée peut l'utiliser pour récuperer l'ID de session
* La faille exploitée a son insu par le super utilisateur... uniquement si tu construit des URL avec l'ID de session en parametre. Le super admin veux montrer une page *publique* a de ses amis et copie/colle l'URL contenant... son ID de session => son ami pourra se connecter avec sa session.
Plus méchant, il clic sur un lien externe... le site cible peut enregistrer l'adresse HTTP_REFERER d'ou il vient... qui peut contenir l'ID de session dans l'URL ;o)

Se prémunir du vol de session ?
-- sans impact pour l'utilisateur --
=> ne JAMAIS passer l'ID de session en parametre d'une URL
=> éviter d'avoir des failles de sécurité classique sur son site ;o)
-- avec impact pour l'utilisateur (a pondérer selon ce que tu souhaites comme sécurité --
=> définir une durée de cookie la plus courte possible ;o)
=> implémenter des controles de session (par exemple lier une ID de session a une adresse IP. Si quelqu'un charge une session mais que son IP n'est pas celle qui a servie a créer la session... c'est qu'il y a vol... ou qu'il est derriere un proxy avec plusieurs point de sortie (par exemple AOL... pas de bol ^^))
=> implémenter des controles divers et variés. Tu peux enregistrer le type et la version du navigateur dans la session. Avec un peu de chance, le voleur n'aura pas la meme version du navigateur et tu pourras le detecter.

[chtipitou]

tres bon article Fladnag, je prend note

[Jihnn]

Merci beaucoup Fladnag.

Pour l'accès physique et le "man in the middle", on peut pas faire grand chose j'imagine

Mais tu donnes comme exemple "echo $_GET['toto'];", je ne comprends pas comment, avec celà, quelqu'un peut retrouver l'id de la session...

Sinon, je ne mets jamais la session_id en paramètre.

Par contre pour les cookies, c'est déjà un autre problème, j'aurais aimé compléter mon système en instaurant une fonction de ce genre... Par contre, un doute me vient à l'esprit : Est-ce que tu parles, par exemple, de mettre la session_id dans la valeur d'un cookie ? Par exemple, si je mettais seulement un cookie du genre "se_souvenir" avec valeur "true", "account" contenant le compte de l'utilisateur et "password" contenant le password (crypté évidemment :p), et que je connecte l'utilisateur via un script, y a-t-il un risque ?

Merci encore,

Jihnn

[Fladnag]

Alors, a choisir, il vaut mieux mettre l'ID de session dans un cookie plutot que le login ou le pass, meme crypté ;o)

Pour le echo $_GET['toto']; :

Code :

page.php?toto=<script>alert(document.cookies);</script>

Si tu fait ca, tu va executer du code javascript... qui va lire un cookie. Donc tu pourrais executer du code javascript qui redirige vers une page (le site du pirate) avec le cookie en parametre (rappel = le cookie contient l'ID de session !!)

Ca s'appelle du CSS (Cross Site Scripting) ou CCS (Cross Code Scripting) ou XSS, bref, y a quelques acronymes, tu choisis celui que tu veux ;o)

Apres, l'idée c'est d'envoyer un mail a un des membres contenant un lien piégé contenant l'URL "construite". Si le membre clic sur le lien, son ID de session sera envoyé sur le site du pirate, stockée, et le membre redirigé vers une page 404 de ton site, ni vu ni connu ;o)

Pour s'en protéger... verifier TOUTES les variables qui viennent de l'exterieur ($_GET, $_POST, $_COOKIE, $_FILES) et dans le cas de l'exemple :

Code :

echo htmlentities($_GET['toto']);

[Jihnn]

Ah oui, j'y avais pas pensé, même si je protège toutes mes variables :p

Bon, alors je ne sais plus trop quoi faire pour le truc de "Se souvenir" maintenant :o

[Fladnag]

Bah, apres ca c'est la theorie... en pratique, le "Se souvenir" est bien plus pratique que dangereux ;o) Rien ne t'empeche de mettre des cases "Se souvenir" avec des durées de cookies d'un ou deux mois pour tes utilisateurs "de base" qui ne peuvent que modifier leur données, et de mettre des cases "Se souvenir" avec des durées de cookies parametrables ou de durée inferieure (1 semaine, 2 jours) pour tes super utilisateurs, s'ils manipulent des données sensibles.

Tu peux aussi implémenter le controle de l'IP pour des super utilisateurs... s'il n'y en a aucun chez AOL ;o)

[juliens9]

Pour augmenter aussi la sécurité pense a bien configurer ton pare feu. SI tu as iptables, change bien les politiques de INPUT, OUTPUT et FORWARD;
Cela evitera que l'on fasse des acces forcer a ton serveur pour pouvoir récuperer mots de passe et autre.

Ensuite pense bien au code de turing et autre pour le controle des mots de passe et autre variable. Beaucoup de hack sont fait en utilisant des taches automatisés et des robots. Cela te permettra de lutter contre ce type d'attaque.

[12monkeys]

Bonjour

Envoyé par Jihnn

Pour le "man in the middle", on peut pas faire grand chose j'imagine

Pour compléter cet excellent post de Fladnag : http://guillaume-affringue.developpe...rement/?page=2, lire cette page et la suivante, pour voir comment y remédier, et d'ailleurs l'article en entier parce qu'il est excellent lui aussi...