Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Et dans ce cas pourquoi ne pas générer un md5() à l'inscription, l'expédier dans la base de donnée et dans la session et comparer le md5() de la session à celui de la base de donnée ?
C'est idiot vous allez me dire, si le pirate chope l'id de session il chope aussi le md5() ? Mais n'y a t'il pas un truc à creuser là ?
Je comprend par très bien qd tu dis ça:
Je pensais que si le hacker volais les 2 id ensuite seulement lui récupererait le nouveau id_page et donc l'utilisateur serait le seul à être déconnecté.Envoyé par wamania
Comment fais tu pour dire que le session_id untel n'est plus valide?
exacteJe pensais que si le hacker volais les 2 id ensuite seulement lui récupererait le nouveau id_page
non, car si vol de session y a, les 2 utilisateur ont la meme sessionet donc l'utilisateur serait le seul à être déconnecté.
Personnellement, je n'utilise pas les session PHP, et je génére mes propres idComment fais tu pour dire que le session_id untel n'est plus valide?
au final, ça ne represente qu'1 session_id maison en plus.Et dans ce cas pourquoi ne pas générer un md5() à l'inscription, l'expédier dans la base de donnée et dans la session et comparer le md5() de la session à celui de la base de donnée ?
C'est idiot vous allez me dire, si le pirate chope l'id de session il chope aussi le md5() ?
ça n'apporte rien en plus si ce n'est que le hacker doit en voler 2 au lieu de 1.
Et encore pire si tu le génére à l'incription, il suffira de le voler une seule fois, il ne changera plus jamais
Il me semblait que tu identifiais la session avec les 2 id, or il n'y a que le hacker qui les posssède (excuse-moi d'insister mais j'ai vraiment envie de comprendre).
Je voulais pas dire inscription, je voulais dire identification. Mais c'est vrai que ça ne sert à rien à priori.
Bon alors, si j'essaie ça, pour voir si j'ai bien compris :pour clarifier, un exemple
un gars se connecte
session_id : 2745
session_id_page : 2135
(bien sur les id doivent etre plus long)
page suivante
session_id : 2745
session_id_page : 8634
...
le session_id_page est stocké chez le client (url, cookie..) ET sur le serveur comme le session_id
aisni, à chaque page, on vérifie si session_id client et serveur sont égaux et idem pour session_id_page
si un gars pique la session, un appelle à une page va renouveller le session_id_page, donc
- le hacker a le nouvel id
- l'autre a l'ancien
un seul appel d'une page par l'autre déconnectera les deux, car son session_id_page n'est plus valide, et qu'ils utilisent tous les 2 le meme session_id
De plus, il faut que le hacker ai le temps le piqué les 2 variables et les utilise avant que l'utilisateur ne r'appelle une autre page, sinon le session_id_page sera obselete, et il lui faudra le recapturer à nouveau.
le soucis intervient si le hacker pique la session pil poil au moment ou le gars s'arrete de navigué.
-> d'ou la nécessité de se déconnecter proprement
Voila en gros l'explication
- Le gars s'identifie, un id de session est créé : je l'envoie dans la base, il y reste tout le temps de la session.
- A chaque page visitée, je crée un md5() : je l'envoie dans la base, il change chaque fois que la page visitée change.
- Après la création du md5() et avant l'affichage de la page, je compare l'id de session et le md5() de la page envoyés dans la base avec ceux de la page actuel.
- Si tout est identique, j'affiche, sinon message d'erreur.
J'ai bon ? Ou je me ramasse de nouveau en frottant lamentablement sur les dents de devant ?
oui, mais ils en ontIl me semblait que tu identifiais la session avec les 2 id, or il n'y a que le hacker qui les posssède (excuse-moi d'insister mais j'ai vraiment envie de comprendre).
- 1 en commun, le session_id, et
- 1 qui différe, le session_id_page.
si celui qui a le mauvais appelle la page, il est déco, et le session_id est réinitialiser
l'autre avait tout bon, MAIS, le précedent a été déco et la session est morte.
Comme l'id session est commun, le deuxième est déco comme le premier.
à ces détails pres, tu as saisis l'idée(_session)Bon alors, si j'essaie ça, pour voir si j'ai bien compris :
- Le gars s'identifie, un id de session est créé : je l'envoie dans la base, il y reste tout le temps de la session.
- A chaque page visitée et à la connection, je crée un md5() : je l'envoie dans la base, il change chaque fois que la page visitée change.
- Après la création du md5(),
D'abord tu compare , ensuite tu regénéres
et avant l'affichage de la page, je compare l'id de session et le md5() de la page envoyés dans la base avec ceux de la page actuel.
- Si tout est identique, j'affiche, sinon message d'erreur.
J'ai bon ? Ou je me ramasse de nouveau en frottant lamentablement sur les dents de devant ?
Merci pour ta réponse, c'est bien clair maintenant
Donc Wanania, tu confirmes que l'on peut appliquer ton idée avec l'id de session et un md5(), plutôt qu'un id de session et un id de session de page ?à ces détails pres, tu as saisis l'idée(_session)
(car les sessions, je débute avec et je préfère minimiser l'usage de toutes ces variables de sessions).
comme je l'ai dit, je gére moi-meme mes sessions et devine quoiun md5(), plutôt qu'un id de session et un id de session de page ?
mes 2 id de sessions, c'est des MD5()
Je reprend ce point, voir si j'ai tout compris :Après la création du md5(),
D'abord tu compare , ensuite tu regénéres
-Le gars affiche une page.
- Je génère un md5() : je le stocke dans 2 variables.
- J'envoie une de ces deux variables dont la valeur est le même md5(), dans la base.
- Je fais une requête qui va chercher dans la base l'id de session et le md5().
- Si le md5() stocké dans la base correspond à celui qui avait été stocké dans la deuxième variables lors de la création du md5(), alors on affiche. Sinon on détruit la session (deconnexion).
- Lors de l'affichage de la nouvelle page, on update le md5() précédent.
Ou alors, en plus : Juste après l'affichage de la page et dans la même page, j'update avec un nouveau md5(). Et j'envoie ce nouveau md5() dans la session. Là, sur la nouvelle page, je compare le md5() stocké en session avec celui dans la base, puis je réupdate, etc...
Mais dans ce cas le pirate ne peut-il pas récupérer le md5() entre deux pages ?
J'ai bon ? J'espère parce que j'ai plus beaucoup de dents là.
J'te vois te prendre la tete depuis tout a l'heure, et je me m'interroge sur le bien fondé de tout ca.
Quoi que tu fasse, meme si tu est en SSL, avec des sessions qui se changent toutes les 30 secondes, un cryptage de ton choix, etc... un pirate motivé qui a le temps, l'argent et les moyens pourras toujours faire ce qu'il veux. Il existe une loi : "En informatique, si tu pense que quelque chose est impossible a faire, c'est que tu n'est pas assez fort pour le faire".
Maintenant que l'on sait que de toute facon toute protection est ephemere, quels sont nos moyens d'actions ? On ne peux que ralentir et compliquer la tache du mechant pirate, eventuellement le décourager, mais les plus experts prendront ca comme un défi et s'y atteleront avec encore plus d'ardeur.
Tout tourne ici autour du vol de cookie. Comment cela est possible ? Je distingue 4 cas :
* Tu as une faille de code sur ton site qui permet cela (Cross Site Scripting avec lecture du cookie en javascript). Si tu as une faille de ce genre... autant la corriger directement plutot que de blinder ton code avec 300 identifiants de session
* Ton hebergeur a une faille qui permet a un compte de lire les cookies d'un autre compte. Là je te conseille fortement de changer d'hebergeur (mais ca existe encore hélas ;o)
* Le pirate trouve un moyen d'acceder a l'ordinateur de l'utilisateur et de lire directement le fichier de cookie... Ben là j'aurais tendance a dire que tu peux pas faire grand chose. Si l'utilisateur était dans un cyber café, cela veux dire que le pirate ne fait qu'utiliser un cookie d'un précédent utilisateur du meme poste, tout ce que tu peux faire c'est mettre un timeout assez court et inviter tes utilisateurs a se deconnecter proprement. Si il s'agit de l'ordinateur personnel de l'internaute, auquel le pirate a acces avec un cheval de troie par exemple, rien ne l'empechera de faire ce qu'il souhaite... Un pirate qui a les connaissances techniques pour faire ca ne sera pas géné par de multiples cookies... il lui suffira d'installer un proxy sur la machine piraté et le tour sera joué.
* Le pirate a vraiment les moyens (ou c'est l'admin de l'entreprise...) et il possede une machine entre la machine de l'internaute et ton site, ce qui lui permet de lire les données au passage. Là encore, comment veux tu contrer ca avec quelques astuces de code ? Tu ne peux qu'utiliser un protocole sécurisé style SSL en esperant que le pirate "ratera" l'ouverture de la session SSL qui contient les infos necessaires a son décryptage (en général il le rate pas, c'est fait pour ;o)
En bref, j'aurais tendance a dire que se proteger d'un vol de session n'est qu'un moyen de s'eviter de corriger ses autres failles (point 1).
Encore un petit detail : Apparemment ca ne choque personne de déconnecter l'utilisateur "légal" si un utilisateur pirate vole sa session. Or, d'apres les techniques énoncées, il y a moyen de savoir qui est l'utilisateur pirate et qui est l'utilisateur légal... donc pourquoi ne pas deconnecter que le pirate (avec session_regenerate_id) ?
Si un pirate pique un id de session admin et trouve un moyen d'y avoir acces en permanence, rien ne l'empeche de se connecter a chaque fois que l'admin se connecte... ce qui déconnecte l'admin... et donc rend toute operation de maintenance impossible (ou en tout cas plus difficile)
Très belle réponse,merci Fladnag.
Une question posée plus haut, que je repose :
Est-il à la porté du premier venu de pirater une session et est-ce très courant ?
Une autre aussi, pour me faire une idée :
Les forums phpBB (et les autres) ont-il prévu des systèmes anti vols de session tels que ceux énoncés plus haut ?
mmmmm
tu t'es servi d'un PC pour ecrire ça?Très belle réponse,merci Fladnag
éteint le vite, PC allumé->PC en danger
evidemment qu'un Pirate peut toujours
Ton analyse au niveau des cookies est très interéssante.
oui, maisEn bref, j'aurais tendance a dire que se proteger d'un vol de session n'est qu'un moyen de s'eviter de corriger ses autres failles
- ta liste n'est pas exhaustive
- 3 cas sur 4 ne sont pas du resort du développeur, et comme il va pas attendre bétement un système parfait sans faille, il y met sa couche propre
non, tout dépend qui reprend la session en premier après le vol de la sessionOr, d'apres les techniques énoncées, il y a moyen de savoir qui est l'utilisateur pirate et qui est l'utilisateur légal...
l'id de session est bien sur propre à une seule session et comme les 2 sont déco en cas de vol, l'id est regénéré (différent pour chaque), donc pas de soucisSi un pirate pique un id de session admin et trouve un moyen d'y avoir acces en permanence, rien ne l'empeche de se connecter a chaque fois que l'admin se connecte... ce qui déconnecte l'admin... et donc rend toute operation de maintenance impossible (ou en tout cas plus difficile)
certaines oui, par exemple le vol physique du cookie, tu vas chez un pote avec ta clé USB, tu pique son répertoire de cookie et hop, 1 site sur 2 ayant enregistré dans les cookies t'ouvriront leur porte.Une question posée plus haut, que je repose :
Est-il à la porté du premier venu de pirater une session et est-ce très courant ?
phpBB non, il possède juste 1 seul id, passé en cookie ou par url.Une autre aussi, pour me faire une idée :
Les forums phpBB (et les autres) ont-il prévu des systèmes anti vols de session tels que ceux énoncés plus haut ?
Les autres je sais pas, mais ce n'est pas encore très courant
Pour le 1er cas, en utilisant une faille de ton site, n'importe quel developpeur web peut le faire quand il connait la technique, il n'y a rien de tres sorcier... faut connaitre le javascript et le php. Apres, le vol est plus ou moins efficace en cela qu'il est discret ou pas pour l'utilisateur (puisque il requiert souvent quand meme un peu de phishing)
Pour les autres cas, ca devient plus ardu et ce n'est pas a la portée de n'importe qui... quand a la fréquence... je ne saurais pas te dire, il est difficile d'obtenir des chiffres fiables quand on parle d'attaques informatiques ;o) Je peux te dire que mon site subit environ 1 a 2 tentatives de piratages (qui se soldent par des echecs jusqu'a présent ;o) par mois environ, pour 400 visiteurs uniques humains (sans les robots). Maintenant, ca c'est les tentatives que je detecte... peut y en a t'il d'autres.
Je pense que oui...(mais a verifier) maintenant ont ils fait ca parce que c'était utile ? Ou bien parce que ca fait une fonctionnalité de plus qu'ils peuvent rajouter a la liste de celles offertes ?
Bon alors, après la théorie, soyons pragmatique :
J'ai posé cette question pour sécuriser un forum, pas une banque ou un site avec des données ultra-sensibles.
Je précise aussi que je n'utilise pas de cookie sur mon site, seulement les sessions, via l'url, après identification.
Donc:
Concernant les failles techniques évoquées par Fladnag, je pense que celles-ci se situent au niveau des formulaires. Je pense les avoir correctement filtrés :
- controle de la taille par strlen.
- masque de saisie pour toutes les données avec les regexp.
- htmlspecialchars + mysql_real_escape_string avant l'envoie final dans la base.
A priori c'est quand même du solide, mais si j'ai zappé quelque chose, n'hésitez pas à me casser la figure bien sur.
Reste donc ces fameux vols de sessions. A priori les systèmes évoqués plus haut sont des petits plus, rien d'autre, en revanche c'est un travail de plus à faire.
Donc est-il nécessaire selon vous de plancher là dessus pour un simple forum (rapport travail/risque) ?
Wamania est-il certain que phpBB ne s'en préoccupe pas ? Des forums phpBB ou d'autres, se sont-il déjà fait piraté en passant par là ?
La nature et les animaux vont-ils enfin être respectés ?
j'ai vérifier, phpBB a un controle par IP
Je pense que le travail est mimine (j'ai ajouté ça chez moi en 15 min), pour un apport sécurité, meme si c'est pas parfait, que j'estime bien mieux.Donc est-il nécessaire selon vous de plancher là dessus pour un simple forum (rapport travail/risque)
Mais, c'est mon avis perso.
Ok, donc si tu passe l'ID de session dans la barre d'adresse, il est encore plus "simple" de faire un vol de session puisque n'importe quel site que l'internaute visitera a partir du tien (via un lien) aura l'identifiant de session renseigné dans le HTTP_REFERER... il faut certes encore que l'admin du site en question soit malveillant. Je parlais de cookie car quand tu ne passe pas l'ID de session dans l'adresse, c'est un cookie qui est utilisé. En fait, passer l'ID de session dans l'adresse n'a pour seul interet que de permettre de gerer une session pour ceux qui n'acceptent pas les cookies, mais j'aurais tendance a dire que c'est "moins bien" au niveau sécurité, meme si la différence reste minime.
mysql_real_escape_string avant l'envoi dans la base je veux bien
htmlspecialchars avant l'envoi dans la base... là je veux moins bien ;o)
En principe, ta base devrait contenir le texte qu'a tapé l'internaute *exactement* tel qu'il l'a tappé. C'est uniquement lors de l'affichage de la donnée que le htmlspecialchars ou htmlentities doit etre appliqué... ce qui complique evidemment l'histoire, car il est tres simple de rajouter un htmlspecialchars avant un INSERT ou un UPDATE... mais pas aussi simple de traquer tout les "echo" de son code pour verifier que la chaine est bien filtrée...
Pourquoi ne pas filtrer les données avant l'insertion ?
Prenons un exemple : un forum. Imagine que tu décide de permettre a l'utilisateur (ou a un admin) d'editer un message d'un forum... tu va recuperer le texte dans la base... l'afficher dans ton textarea... et tu aura tout les < remplacés par des < !! Tu va donc devoir coder une fonction *inverse* de htmlspecialchars ! Est-ce vraiment tres propre ? Je ne pense pas ;o)
Pour moi la mise en forme doit se faire a l'affichage, meme si c'est plus lourd (execution du code php a chaque affichage au lieu d'une seule fois, mais apres tu peux mettre en place des systemes de cache de tes pages).
je suis d'acoord
.....avec tout
Répondre avec citation
Partager