(re)Bonjour,
 
J'ai créé un systeme qui permet à un utilisateur de se loger sur le site. Lorsqu'il se loge, une session lui est attribué, et son ip est conservée en memoire. A chaque page qu'il consulte, on vérifie que son ip est toujours la meme, pour refuser toute personne ayant piraté l'id de session.
 
MAIS (le hic)
 
Il semblerait que cette technique empeche certaines personnes de se connecter au site, comme :
-les proxys : les utilisateurs qui sont derriere un proxy ont tous la meme ip, donc un seul au plus pourra acceder au site à un moment donné (mais cette limitation est acceptable je penses)
-les utilisateurs d'aol (ca pose tjs pb aol...) changent d'ip à chaque page consultée. Ils seront donc pris pour des pirates et ejecté du site...
 
Ce que je penses :
 
Je penses que l'ip est un le seul élément qui nous informe sur l'identité de l'utilisateur. Donc si on peut pas l'utiliser de maniere fiable et stable, alors on ne peut pas proteger les sessions...
 
Mais il doit tout de meme y avoir un moyen nan??? Il font comment les pros de la sécurité ?

Tu peux utiliser plusieurs infos que tu obtiens du client.
Par exemple :
- l'user agent de son navigateur
- l'ip du visiteur
- s'il passe par un proxy
- l'os du visiteur
- si tu fais un reverse de l'ip tu peux obtenir le provider et le pays
- la resolution d'ecran.
 
Ensuite il te suffit de faire une comparaison ds toutes ces proprietes et de definir un ecart maximun.
 
Tu peux par exemple dire que si le visiteur utilisant une session echoue a 3 comparaisons, alors tu consideres que la session n'est plus valable.
Comme ca, les utilisateurs d'aol, vont echouer a l'ip, mais en revanche vont continuer a reussir la comparaison sur les autres termes.

Mouais ... je reste peu entousiaste de ce genre de controle trop "voluble"

 
(1)Tu me la récupères comment la résolution de l'écran en php ?    
Tu es obligé de passer par un script JavaScript ? Et si l'utilisateur a désactivé le Javascript  ?

Merci Cerel, ta reponse est vraiment interressante :-)) Ce sont ces méthodes qui sont utilisées dans le milieu professionnel ?
 
Dois je en conclure qu'il n'y a pas de methode sur à 100% ?
 
Autre question : comment font les pirates pour recuperer une session ? Ils font des requetes aux serveurs avec un id de session qui s auto incremente jusqu'a ce que ca marche ?
 
Merci

 
J'etais pas sur, il me semblais que c'etait possible. Au temps pour moi, j'ai dit une betise (si ce n'est qu'une seule ca va ).
Faut m'excuser c'est vendredi et il faut chaud (vi je sais, excuse facile).

Deux méthodes à ma connaissance(qui est limitée) :
- Brute force : on envoie des requêtes au serveur avec plein de SESSONID jusqu'à temps d'avoir une "réponse" ;
- Sur un serveur mutualisé, on récupère les sessions dans /tmp.

et comment envoyer des requêtes avec des sessid au serveur?    
 
je suis sur un mutualisé, j'ai pas de dossier tmp.   alors?

Et pourquoi pas, tout simplement, une clé unique générée à l'ouverture de session, stockée à la fois dans la session, et sous forme de cookie chez l'utilisateur ?
Il suffit alors de vérifier que le cookie de l'utilisateur correspond bien à la valeur en session ...

Il faut également chaud, très chaud chez moi ce vendredi apès-midi. La transpiration qui dégouline de mes mains va provoquer des court-circuits dans mon clavier    
 
Pour en Revenir aux sessions, Il y a deux moyens de se protéger(pas testé) :
- Contre le brute force : detecter les "mauvaises" sessions qui se perpétuent pour un même utilisateur. Ou par l'intermédiaire s'un segment de mémoire partagé qui s'occupe de ça ;  
- Pour les mutualisé : prendre un dédié    
 
Sinon, le simple fait de comparer en plus l'user-agent devrait déjà faire reculer pendant quelques temps un piratage(Jusqu'au moment où le pirate trouvera sans difficultés l'user-agent de son "client"...)
 
EDIT : La prposition de dsls est pas mal non plus.
 
Mais pour une sécurité "renforcé", rien ne vaut le ssl avec certificat...

Parce que si le pirate recupere la session, il aura cette variable a disposition...

Ben non ... il aura l'ID de session, pas son contenu ...

Pffffiuuuu vous repondez super vite !!!
 
C'est quoi un serveur mutualisé ???
 
Yoyo j ai pas compris tes methodes contre la force brute, pourrait tu developper un peu?

un mutualisé c'est un serveur "squatté" par d'autres clients du prestataire qui t'heberge.   En gros t'es pas le seul a stocker tes fichiers sur le serveur, d'autres clients ont un espace alloué sur le disque dur de ce serveur.

Merci pmusa
Et sur des serveurs mutualisé, tout le monde a acces au /tmp ?

j'avais lu un dossier sur APACHE et je crois pas que ça se fait, et c'est fort heureux.   on pourrait aussi chiper les fichiers des autres sinon.
 
et j'attend la réponse de yoo à propos du directory /tmp.   j'l'lai pas moua ce truc.
 
 
AU PASSAGE, qqn sait à quoi sert le dossier vti_cnf  

 
On se demande pas ce que tu penses des dédiés    
C'est vrai que les dédiés c'est pas top, mais tout le monde n'a pas les qualifications requises pour configurer et sécuriser un serveur dédié "juste" pour l'hebergement d'un site.  
 
Pour contrer le brute force, rien de mieux qu'un exmple trouvé dans PHPCOOK (chapitre 8.27). (Je suis dégouté, j'achète ce bouqin 40€ et je le retrouve en téléchargement sur le net )
J'ai pas testé ce script, mais en gros, il regarde si les gens se connectent pas trop souvent sur le site ( par exemple : 500 connections en 1 minutes, ça fait beaucoup) et si ils abusent, on leur affiche une page d'erreur.
 
Pour le /tmp et non tmp : ( /tmp est à la racine du serveur, tmp serait à la racine de ton homedire (/home/benji_100/tmp). Ce repertoire comme son nom l'indique contient tout ce qui est temporaire, comme les sessions. On peut remedier à ceci en utilisant session_set_save_handler pour customiser l'enregistrement des sessions(dans une bd(Pour partagé les sessions entres plusieurs serveurs...), un fichier txt, sur une feuille de papier...).

Ce week-end je vais essayer de trouver le temps d'écrire le tuto que j'ai commancer il y a quelques mois, sur comment securiser les sessions ... Chose passionnante (et on ne rigole pas) mais deprimante (vous verrez pourquoi)

esox_ch, ou peut on consutler ce tuto ? Il est deja en ligne ?

Enfin !  
 
 
 
benji_100, esox_ch à dit ce week-end....

Ya peut etre deja une partie en ligne

Je ne connait pas bien ... il faut des prerequis sur le serveur ? Le site est sur un serveur mutualisé en effet, je peut pas faire tout ce que je veut
Je n'utilise pas les cookies ... dommage ... j aurai pu utiliser la solution de dsdl mais certains utilisateurs desactivent les cookies.

Perso (je sens que je vais me faire taper dessus), je n'utilise plus les sessions du tout.
Je suis loin de m'y connaitre comme esox_ch, mais mon petit doigt me dis que ce qui est déprimant, c'est qu'il n'y a pas de moyen fiable à 100%.
Perso, j'utilise uniquement les cookies, y'en a qui les désactive, bah tant pis, au moment de l'inscription sur mon site, je le précise : Si pas de cookies, pas de chocolat mais au moins, les cookies, le seul moyen de les piraters, c'est d'aller sur l'ordi du membre.  

 
bah tu fais bien de ne plus utiliser les sessions, surtout celles du php. Par contre les cookies ne sont pas plus secures, voire meme moins...
 
Avant tout, il faut faire la part des choses. Est-ce que les donnees sont tellement sensibles, ou bien cela ne sert que pour un petit site ou forum?
Dans le premier cas, on utilisera du https, seul protocole sur pour ce genre d'echange. Dans le second cas, arretez de vous casser la tete... y a pas de solution miracle. Prevoyez plutot un bon systeme de backup en cas de degats.

le pirate s'en fout de la clef originale. avec une bonne machine, il ne lui faudra pas longtemp pour en trouver une qui donnera le meme hashing.

Serait ce la conclusion de ce post ? ;-)

 
Encore faut-il que le calcul de clef ai pas un bug
 

A quel niveau ?
 

Elianor, les fonction cette fonction makerand etait propre a CE serveur en particulier non ?

 
reprises intégralement de la doc PHP de l'époque, donc pas mal de site doivent encore avoir le problème

c'est fou ca ...

vol d'info dans le cookie par un site tiers ou un javascript. les seuls infos qu'un cookie devrait contenir sont des preferences d'affichages, et, dans le moins bon cas, des infos de login temporaire modifiees regulierement.

Par un site tiers, c'est possible ça ?  
Bon, sinon, pour le javascript, suffit de pas l'autoriser sur ton site, parce qu'autrement, ni cookies ni sessions ni htaccess ne sont complètement sécurisés à ce que j'imagine.

 
cross site scripting
 
C'est un classique.
 
http://www.phpsecure.info/v2/article/XSS.php

Je ne pense pas que Gizmo parle de ça, faut pas me prendre pour un gros newb non plus, c'est le genre de faille qu'on apprend à son troisième jour de PHP.
Y'a-t-il encore quelqu'un qui affiche des entrées de formulaire de visiteurs sur son site sans passer par un htmlentities ? Si oui, qu'il se lève sans honte.

perso je fait un hash md5 de l'IP concaténée de l'UserAgent pour sécuriser mes sessions et mes cookies.

 
De toute facon et honnetement je vois pas pourquoi vous vous emmerdez avec des sessions ou cookies. Un truc fiable c'est de générer le hash MD5 du mot de passe de l'utilisateur et de le transmettre à chaque demande d'une page. Puis on compare ce hash pour authentifier l'utilisateur du coté serveur...  
 
+ HTTPS pour éviter des analyses de trames entre le client et le serveur    
 
Et là honnetement je vois pas comment on pourrait s'authentifier sur le serveur (faille script php & faille dans les services du serveur exclu).  

 
Parce que dans une session, on peut stocker des informations ?

Tu peux tres bien crée une table qui associe a chaque MD5(password) des informations du coté serveur  

 

 
Je suis désolé mais si tu génére le hash MD5 à partir d'un numéro de session PHP (qui represente 128 bits), tu peux t'accrocher pour le brute forcé, meme avec un super calculateur