Bonjour à tous !
 
Voilà, en fait, j'ai un gros problème de sécurité avec le site pour lequel je travaille :
Lorsqu'on fait la recherche de ce site dans MSN search, le moteur de recherche nous retourne un lien contenant le PHPSESSID d'un membre connecté.
( /reglement.php?PHPSESSID=14e42cdddddce976a5b1f1e7fe92bec1 )
Résultat, quand on clique dessus, parfois, la personne se retrouve connectée au compte de quelqu'un d'autre et certains petits malins n'hésitent pas à pourrir ces comptes
 
Savez-vous ce que je peux faire ?
 
Merci d'avance

Je te suggère de colmater la faille.

...et il fait comment pour obtenir l'id de session d'un membre, le moteur de recherche?

Un admin qui s'est identifié sur le site avec la machine serveur?

ini_set() est ton ami ...
 
session.use_cookies
session.use_only_cookies
session.use_trans_sid
 
et pour les config recalcitrantes
url_rewriter.tags

Et ne pas mettre un truc entre crochets au début du titre du topic...
Enfin je dis ca comme ca...

oui, la je saisis pas
 
 a moins d'avoir soumis soit meme l'URL au moteur avec le sessionid dedans

Ouai mais la faut vraiment être con!  

Si je comprends bien, ça ne permet pas les sessions par SID, c'est bien ça ?
Merci
 
Backdafuckup>

Moi non plus je ne comprends : personne ne se connecte au site de cette façon
 
Et en cherchant bien sur MSN Search, je suis tombé sur plein d'adresses avec le SID dedans

Y a un certain nombre de sites qui créent un id de session pour tous les visiteurs y compris les robos et un certain nombre d'entre eux permettent d'avoir cet id dans l'adresse quand le navigateur n'accepte pas les cookies.
Du coup, c'est logique de voir pleins de sites avec des id de session dans des moteurs de recherche.
 
 
Ce qui ne l'est pas, c'est que cet id corresponde à quelqu'un qui c'est loggué sur le site.
 
EDIT : Enfin, c'est logique si le webmaster n'a pas indiqué au robos de valider le formulaire de conection avec tel contenu. (ca s'indique dans le fichier "robos.txt" situé à la racine du site si je me souviens bien.)

donc soit tu sors le PHPSESSID de l'URL via ini_set(), soit tu renforces tes sessions avec une validation par ip + un timeout plus sérré, en sachant que cette dernière solution laisse qd même qlqs risques ...

Hmm, je n'ai que quelques notions en PHP et je n'utilise les session php que depuis peu de temps.
Je ne comprends vraiment pas comment le PHPSESSID se retrouve dans une url... c'est l'admin qui a créé un lien surrement ?
 
Moi, j'identifie l'utilisateur avec une variable de session du style : $_SESSION[id_user]="123456" et il me semble (dites moi si je me trompes) que la seule façon d'écrire "123456" dans $_SESSION[id_user] est le code de mes page PHP et non une url, n'est-ce pas ?
Rassurez moi svp !

PHP a pour comportement "par défaut"  
1. d'utiliser les "transient IDs" i.e. d'ajouter l'id de session dans les URLs "foo.php?PHPSESSID=[a-z0-9]{32}"
2. de réécrire toutes les URLs présentes dans la page (et qui matche la directive url_rewiter.tags) pour positionner le fameux session_id afin de faire suivre l'id de session
maintenant ce comportement par défaut est pas tjrs souhaitable : sécu, référencement ...
 
> Mams : oui, la seule façon d'écrire 'admin' dans $_SESSION['user'], c'est bien via du code (enfin si ton code est bien conçu ) mais si je met la main sur le session_id qu'a utilisé 'admin' (alors que la session n'est pas déjà détruite) je deviens par la même occasion 'admin', d'où l'interêt de supprimer les "transient IDs" qui peuvent se retrouver indexés sur un moteur de recherche ou listés sur des logs divers (via referer, proxy, stats de site) donc d'utiliser seulement les cookies, de renforcer le tout par un check d'ip au minimum.
Et surtout de bien penser ton utilisation des sessions pour que, par exemple, un bot (ou un paranoïaque) puisse voir ton site, ou en tout cas, en voir suffisament lorsqu'il ne supporte pas les cookies ...

Suite à mon mail, le lien en question n'est plus retourné par MSN.
Sinon, je vais quand même modifier php.ini comme indiqué par shakpana
 
Merci à vous

Bon, après quelques temps, je viens de me rendre compte qu'il y avait toujours le même problème sur le site.
 
Voici les valeurs des variables concernées :

 
Pouvez-vous me dire ce qu'il est préférable d'avoir comme valeurs pour résoudre ce problème SVP ?
 
Merci d'avance

 
Voilà le top si tu veux que les moteurs de recherche n'aient pas cette info dans l'URL.
Si tu laisses "session.use_only_cookies" à 0 alors php proposera l'id de session dans l'URl quand le cookie est indisponible (toujours le cas avec les moteurs de recherche)

Ok, merci, c'est ce que je pensais, mais je préférais avoir une confirmation

session.use_trans_sid = 0

J'ai eu un probleme simmilaire sur mon site, j'ai été contraint de stocker l'ip de l'utilisateur dans la session et de checker si l'ip etait toujours la meme, dans le cas contraire, je kill la session et j'en recré une.
Je suis conciens que ce n'est pas forcement "la" bonne solution, mais ça a le merite de fonctionner dans mon cas.

Voilà, c'est modifié dans php.ini. Il ne reste plus qu'à attendre voir si les problèmes continuent
 
Sinon, si je comprends bien, session.use_cookies autorise l'utilisation de cookies pour les sessions, session.use_only_cookies n'autorise que l'utilisation des cookies pour les sessions.
Par contre, pour session.use_trans_id, je ne vois pas ce que cela veut dire : ça correspond à l'autorisation du SID dans l'url ?

quand même je comprends pas. Comment le sessionID du moteur de recherche peut-il être encore valable ?
Par défaut, la session est détruite quand tu fermes le naviguateur. Tu as modifié ça ?

Oui, elle est détruite à la fermeture du navigateur, c'est pourquoi je ne comprends pas ce problème
Le même SID qui serait réutilisé ?  

bah oui, a part ça je vois pas d'autres explications. En même temps, un SID faut quand meme avoir méga pas de bol pour qu'elle soit identique à un SID actuellement utilisé sur le site. Donc c'est clairement pas ça.
 
D'ailleurs sinon ça veut dire qu'il suffirait de se générer quelques cookies avec un id de session aléatoire pour craquer un site. Mais ce n'est pas le cas, vu la probabilité de trouvé un ID de session actuellement utilisé

si seulement c'étais vrai, ca fonctionne quand on fait une page de délogage avec un sessiondestroy mais sinon (l'utilisateur ferme le naviguateur ou change d'URL) il faut attendre que le garbage collector fasse son boulot...
 
ceci dit c'est vrai que compte tenu du temps d'indexation par le moteur, je trouve aussi étonnant que le garbage collector ne l'ai pas encore supprimé...
peut etre y a t'il tres peu de traffic sur son site  

ça peut pas être un problème de trafic, vu que l'ID de session référencée par le moteur est l'ID que le moteur a eu pendant sa visite du site. Donc pas celle d'un utilisateur avec des acces.
 
Là si tu arrives a te connecter avec la sessionid du moteur de recherche, ça veut dire que cet ID de session est couramment utilisé. Puisqu'une session est détruite au bout d'un certain temps, pas en fonction du nombre de visite
 
 
enfin bref, tout ça pour dire que je comprends pas comment c'est possible.
 
Ca pourrait pas etre une faille dans ton code PHP ? Genre tu considères que s'il y a un id de session dans l'url le mec est identifié, ou un truc dans le genre ?

Non, je n'utilise jamais l'Id de Session dans l'URL
 
Sinon, pour le traffic, c'est environ 1000 connectés simultanés.

peut-être un souci dans la configuration de PHP, qui donnerait une durée de vie à tes sessions beaucoup trop importante. C'est la seule explication que je vois, mais je ne connais pas ce qui touche à ça dans la config
 
D'ailleurs c'est facilement vérifiable. Tu te connectes a ton site en forçant ton  navigateur a refusé les cookies, tu notes l'id de session dans l'url. Tu fermes le navigateur sans passer par une page de destruction de session, tu pars manger, et tu reviens qques heures apres en appelant ton site en passant l'id de session précédemment noté dans l'url. Et tu vois ce qui se passe
 
 
Enfin même si c'est ça le problème, je vois pas comment l'id de session d'un robot se retrouve etre celle d'un utilisateur. A aprt une grosse malchance ...

Voila en gros ce que j'ai mis sur mon site pour contourner le probleme :
 

 
de ce fait, ça force le nouvel utilisateur qui viendrait depuis un lien trouvé sur le moteur de recherche à ouvrir une nouvelle session...
ma page delog.php fait un session_destroy et r'ouvre une session

Djebel1> le plus étrange est qu'avec ce lien sur MSN Search, soit je me retrouve sur le site non loggé, soit je me retrouve loggé sur des comptes complètement différents à chaque fois
 
fluminis> pas bête

ce qui est logique, puisque ça va te connecter si l'id est actuellement utilisé, mais elle peut donc être utilisé par différents utilisateurs au cours du temps. Et si l'id n'est pas actuellement utilisé, tu ne seras pas connecté.
 
M'enfin je pense quand même que c'est un problème dans ta config serveur ou dans tes scripts. Du style un problème qui fait que les ID de session générées aléatoirement ne sont pas si aléatoires que ça. Limite reinstalle ton serveur et voie si ça continue

je repense à mon probleme, et donc le meme que toi.
 
Est-ce que tu utilises des cookies pour verifier si ton user est logué ?
 
Car moi je stocke un cookie sur l'ordi de l'utilisateur qui me permet de loguer automatiquement mes visiteurs sans qu'ils retappent leur mots de passe.
 
Si l'utilisateur A vient du moteur de recherche, il a un PHPSESSID donc php ne lui en donne pas un nouveau. Là dessus, ton script lit les cookies et se dit tient il a les bonnes infos dans les cookies... hop il met les variables qui vont bien dans $_SESSION pour que l'utilisateur soit loggué.
Si la dessus un autre utilisateur B vient sur ton site avec le meme PHPSESSID, il va etre logué... en tant que A si la session de A est encore valide.
Si ton site commence a être connu, il y a de forte chance pour que les utilisateurs venant du moteur de recherche réactivent la session encore et encore...
 
Je ne sais pas dutout si ce que je viens de dire est une connerie plus grosse que moi ou si ça se passe réélement comme ça. Mais ça expliquerait pas mal de choses

Non, effectivement, c'est fort probable ce que tu viens de dire car en effet, on stocke les variables de session dans un cookie pour ceux qui veulent rester connectés.
Par contre, comment contourner ce problème ? (car je pense effectivement que tu as mis dans le mille)

oui Fluminis a surement raison, et dans ce cas il te reste les solutions proposées précédemment :
- interdire le passage de l'id par l'url
- faire un controle sur l'Ip et l'heure de derniere activité à chaque page vue

Je pense que le session.use_trans_id=0 résoud ce problème, non ? (car ça ignore le SID dans l'URL si j'ai bien compris)

en fait, faut pas oublier que l'id de session dans l'url peut être utile si le client refuse le cookie
 
le truc le plus basique (on parle pas de sécurité là, mais bel et bien du problème de bots) serait de détecter si l'utilisateur est un bot ou pas, et de ne jamais démarrer de session si c'est le cas
 
y'a des scripts open source de stats et de détections de bots, ça doit pouvoir s'adapter sans problème
 
pas de session = pas de problème
 
après faudrait revoir la sécurité autour de la session en général je pense

En fait, de toute façon, pour une utilisation correcte du site, il faut obligatoirement accepter les cookies (c'est précisé sur le site), donc, ça m'arrange au contraire de refuser les SID dans l'URL

en principe les gens aiment pas trop être obliger à faire qqch, surtout que les cookies beaucoup de personne les accptent.
 
ton cookie doit juste te servir pour relogguer la personne si elle le souhaite. Pour les infos charge les plutot en session

Les infos sont stockées en session
 
Les cookies servent à mémoriser la session pour pouvoir se relogguer plus tard, mais ils servent aussi pour des services disponibles sur le site comme le micropaiement.