Ben c'est le sujet du mois, on dirais...
bref, je suis confronté au problème suivant: il se trouve que les sessions
php ne me satisfont pas tout à fait
à vrai dire, il semblerait que dans certains cas, avec certaines configs de
client, les sessions ne fonctionnent pas (notamment si le type refuse tous
les cookies, mais ce n'est pas tout à fait le seul cas, visiblement.) et
comme je n'ai pas trouvé de config du php.ini avec session_use_cookies = 0
qui fonctionne (à part en utilisant le session_trans_id qui ne me satisfait
pas), j'ai décidé de développer mon propre module de session.
du coup, en 2 mots comment je procède:
1. je génère un id que je veux etre le plus caractéristique possible: a
priori c'est un mix entre le HTTP_USER_AGENT et l'adresse ip
2. a partir de cet id, je génére sur mon serveur un fichier, dont le nom
correspond (aux caratères interdits pres).
3. au début de chaque script, grace à l'appel de _sessionLascap_start(), je
(re)génére l'id, regarde si le fichier existe, et si c'est le cas, charge
les variables
4. a la fin de chaque script, je "sérialise" les variables et les écrits
dans un fichier qui porte le nom généré.
le tout fonctionne très bien, MAIS
j'imagine plus que je me trouve confronté le problème suivant:
si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le même
navigateur, quoi), utilisent le même proxy et regardent le même site en
même temps, ça va poser un gros problème.
je me demande donc s'il est possible de récupérer une information typique
d'un poste que je pourrais concatener à mon id pour un faire quelque chose
de vraiment unique. (genre si je pouvais récupérer le nom du poste, style,
ça serait génial.)
mais voilà, est-ce possible?????
ps/ pour ceux que ça intéresse, les sources d'un script de test et de la
lib.
je me demande donc s'il est possible de récupérer une information typique d'un poste que je pourrais concatener à mon id pour un faire quelque chose de vraiment unique. (genre si je pouvais récupérer le nom du poste, style, ça serait génial.) mais voilà, est-ce possible?????
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer tes id ? Ou bien faire une fonction prennant les memes regles de generation que apache : pid + ip + timestamp
Il cherche à ne pas utiliser de variable de sessions, donc il faut retrouver les bonnes variables entre deux requêtes, si tu introduis une information volatile (timestamp) il n'aura jamais le même ID entre deux requêtes...
dominique - zdoum@nerim.net :
Lascap wrote:
je me demande donc s'il est possible de récupérer une information
typique d'un poste que je pourrais concatener à mon id pour un faire
quelque chose de vraiment unique. (genre si je pouvais récupérer le
nom du poste, style, ça serait génial.)
mais voilà, est-ce possible?????
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer
tes id ? Ou bien faire une fonction prennant les memes regles de
generation que apache :
pid + ip + timestamp
Il cherche à ne pas utiliser de variable de sessions, donc il faut
retrouver les bonnes variables entre deux requêtes, si tu introduis une
information volatile (timestamp) il n'aura jamais le même ID entre deux
requêtes...
je me demande donc s'il est possible de récupérer une information typique d'un poste que je pourrais concatener à mon id pour un faire quelque chose de vraiment unique. (genre si je pouvais récupérer le nom du poste, style, ça serait génial.) mais voilà, est-ce possible?????
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer tes id ? Ou bien faire une fonction prennant les memes regles de generation que apache : pid + ip + timestamp
Il cherche à ne pas utiliser de variable de sessions, donc il faut retrouver les bonnes variables entre deux requêtes, si tu introduis une information volatile (timestamp) il n'aura jamais le même ID entre deux requêtes...
Zouplaz
Lascap - :
si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le même navigateur, quoi), utilisent le même proxy et regardent le même site en même temps, ça va poser un gros problème.
je me demande donc s'il est possible de récupérer une information typique d'un poste que je pourrais concatener à mon id pour un faire quelque chose de vraiment unique. (genre si je pouvais récupérer le nom du poste, style, ça serait génial.) mais voilà, est-ce possible?????
Et la situation risque de se poser... Dans une entreprise où les postes utilisent le même OS, le même navigateur et passe par un routeur ou firewall et donc la même adresse IP...
Mais ton idée est très bonne, reste à trouver un moyen de générer un ID qui soit propre à chaque poste. Et là y a peut-être un moyen, allez délirons un peu ;-)
voici la séquence : 1) monscript.php est appellé une première fois 2) $_GET['UID'] existe ? 3) oui on continue l'exécution du script et on récupère les variables stockées lors du dernier appel, s'il y en a 4) non on redirige vers genUID.php?url=monscript.php 5) genUID.php génère une page htm contenant une applet java, on passe à l'applet java le nom du script (en l'occurence ici monscript.php) 6) lors de l'exécution de l'applet java on récupère un maximum d'infos sur le poste (IP, résolution d'écran, "os.arch", "os.name", "os.version", "user.name", etc) et calcule un ID numérique 7) a la fin de l'exécution de l'applet, on redirige vers le script passé en paramètre auquel on ajouté UID= avec la valeur de l'ID
et retour en 1)
Bon... ahem... Amusant... Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
Par contre comme l'applet s'exécute côté client il y a peu être d'autres renseignements disponibles qui pourraient permettre de générer un ID beaucoup plus spécifique (voire totalement spécifique ???) au poste client...
Allez, je retourne bosser au lieu de délirer...
Lascap - lascap@dkmastering.com :
si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le
même navigateur, quoi), utilisent le même proxy et regardent le même
site en même temps, ça va poser un gros problème.
je me demande donc s'il est possible de récupérer une information
typique d'un poste que je pourrais concatener à mon id pour un faire
quelque chose de vraiment unique. (genre si je pouvais récupérer le
nom du poste, style, ça serait génial.)
mais voilà, est-ce possible?????
Et la situation risque de se poser... Dans une entreprise où les postes
utilisent le même OS, le même navigateur et passe par un routeur ou
firewall et donc la même adresse IP...
Mais ton idée est très bonne, reste à trouver un moyen de générer un ID
qui soit propre à chaque poste. Et là y a peut-être un moyen, allez
délirons un peu ;-)
voici la séquence :
1) monscript.php est appellé une première fois
2) $_GET['UID'] existe ?
3) oui on continue l'exécution du script et on récupère les variables
stockées lors du dernier appel, s'il y en a
4) non on redirige vers genUID.php?url=monscript.php
5) genUID.php génère une page htm contenant une applet java, on passe à
l'applet java le nom du script (en l'occurence ici monscript.php)
6) lors de l'exécution de l'applet java on récupère un maximum d'infos
sur le poste (IP, résolution d'écran, "os.arch", "os.name", "os.version",
"user.name", etc) et calcule un ID numérique
7) a la fin de l'exécution de l'applet, on redirige vers le script passé
en paramètre auquel on ajouté UID= avec la valeur de l'ID
et retour en 1)
Bon... ahem... Amusant...
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id
unique (enfin, un peu moins générique disons) ? la résolution d'écran,
peut-être le nom de l'utilisateur (et encore je connais rien à java
alors)..
Par contre comme l'applet s'exécute côté client il y a peu être d'autres
renseignements disponibles qui pourraient permettre de générer un ID
beaucoup plus spécifique (voire totalement spécifique ???) au poste
client...
si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le même navigateur, quoi), utilisent le même proxy et regardent le même site en même temps, ça va poser un gros problème.
je me demande donc s'il est possible de récupérer une information typique d'un poste que je pourrais concatener à mon id pour un faire quelque chose de vraiment unique. (genre si je pouvais récupérer le nom du poste, style, ça serait génial.) mais voilà, est-ce possible?????
Et la situation risque de se poser... Dans une entreprise où les postes utilisent le même OS, le même navigateur et passe par un routeur ou firewall et donc la même adresse IP...
Mais ton idée est très bonne, reste à trouver un moyen de générer un ID qui soit propre à chaque poste. Et là y a peut-être un moyen, allez délirons un peu ;-)
voici la séquence : 1) monscript.php est appellé une première fois 2) $_GET['UID'] existe ? 3) oui on continue l'exécution du script et on récupère les variables stockées lors du dernier appel, s'il y en a 4) non on redirige vers genUID.php?url=monscript.php 5) genUID.php génère une page htm contenant une applet java, on passe à l'applet java le nom du script (en l'occurence ici monscript.php) 6) lors de l'exécution de l'applet java on récupère un maximum d'infos sur le poste (IP, résolution d'écran, "os.arch", "os.name", "os.version", "user.name", etc) et calcule un ID numérique 7) a la fin de l'exécution de l'applet, on redirige vers le script passé en paramètre auquel on ajouté UID= avec la valeur de l'ID
et retour en 1)
Bon... ahem... Amusant... Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
Par contre comme l'applet s'exécute côté client il y a peu être d'autres renseignements disponibles qui pourraient permettre de générer un ID beaucoup plus spécifique (voire totalement spécifique ???) au poste client...
Allez, je retourne bosser au lieu de délirer...
Guillaume Bouchard
marc guillaume wrote:
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à http autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un protocole non connecté en protocole connecté.
Mais php à le truc parfait pour faire ca, les cookies. Pourquoi vous embetez vous avec des trucs a l'arach alors que les cookies sont là pour ca. De nos jours tout les navigateurs supportent les cookies, et ceux qui les ont désactivés savent pourquoi et savent qu'ils se privent d'une possibilité...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de bien caracteristique pour faire un id et de plus faire un ID en GET.
Scernario, utilisateur lambda va sur un site, et ensuite se rend sur un autre site, dans les log de cette autre site, il y a un beau referer qui contient l'id de session de la personne. De plus, l'utilisateur toto va sur IRC et discute du site Y, le mechand monsieur Z voie que le site en question fait des ID ressemblant fortement à un USER_AGENT + IP, il lui suffit de recuperer l'ip de la personne, pas dure, et son user_agent, suffit de lui demander :)
Bref, les cookies c'est bon, mangez en.
-- Guillaume.
marc guillaume wrote:
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à http
autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un
protocole non connecté en protocole connecté.
Mais php à le truc parfait pour faire ca, les cookies.
Pourquoi vous embetez vous avec des trucs a l'arach alors que les
cookies sont là pour ca. De nos jours tout les navigateurs supportent
les cookies, et ceux qui les ont désactivés savent pourquoi et savent
qu'ils se privent d'une possibilité...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de
bien caracteristique pour faire un id et de plus faire un ID en GET.
Scernario, utilisateur lambda va sur un site, et ensuite se rend sur un
autre site, dans les log de cette autre site, il y a un beau referer qui
contient l'id de session de la personne.
De plus, l'utilisateur toto va sur IRC et discute du site Y, le mechand
monsieur Z voie que le site en question fait des ID ressemblant
fortement à un USER_AGENT + IP, il lui suffit de recuperer l'ip de la
personne, pas dure, et son user_agent, suffit de lui demander :)
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à http autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un protocole non connecté en protocole connecté.
Mais php à le truc parfait pour faire ca, les cookies. Pourquoi vous embetez vous avec des trucs a l'arach alors que les cookies sont là pour ca. De nos jours tout les navigateurs supportent les cookies, et ceux qui les ont désactivés savent pourquoi et savent qu'ils se privent d'une possibilité...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de bien caracteristique pour faire un id et de plus faire un ID en GET.
Scernario, utilisateur lambda va sur un site, et ensuite se rend sur un autre site, dans les log de cette autre site, il y a un beau referer qui contient l'id de session de la personne. De plus, l'utilisateur toto va sur IRC et discute du site Y, le mechand monsieur Z voie que le site en question fait des ID ressemblant fortement à un USER_AGENT + IP, il lui suffit de recuperer l'ip de la personne, pas dure, et son user_agent, suffit de lui demander :)
Bref, les cookies c'est bon, mangez en.
-- Guillaume.
Lascap
Sinon pour l'id, pourquoi ne pas faire : $globales["SESS_GLOB_ID"] = md5($useragent . "_" . $_SERVER["REMOTE_ADDR"]);
Ca ferais un id plus court je pense et sans caractères spéciaux, auquel cas tu
n'aurais pas à les enlever plus haut.
merci pour le "md5", c'est vrai que c'est intéressant. je l'ai rajouté direct ;) (sinon, c'est vrai que les noms de fichier sont un peu longuets ... Lascap
Sinon pour l'id, pourquoi ne pas faire :
$globales["SESS_GLOB_ID"] = md5($useragent . "_" .
$_SERVER["REMOTE_ADDR"]);
Ca ferais un id plus court je pense et sans caractères spéciaux, auquel
cas tu
n'aurais pas à les enlever plus haut.
merci pour le "md5", c'est vrai que c'est intéressant. je l'ai rajouté
direct ;)
(sinon, c'est vrai que les noms de fichier sont un peu longuets ...
Lascap
Sinon pour l'id, pourquoi ne pas faire : $globales["SESS_GLOB_ID"] = md5($useragent . "_" . $_SERVER["REMOTE_ADDR"]);
Ca ferais un id plus court je pense et sans caractères spéciaux, auquel cas tu
n'aurais pas à les enlever plus haut.
merci pour le "md5", c'est vrai que c'est intéressant. je l'ai rajouté direct ;) (sinon, c'est vrai que les noms de fichier sont un peu longuets ... Lascap
Lascap
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer tes id ? Ou bien faire une fonction prennant les memes regles de generation que apache : pid + ip + timestamp
Mais non mais non, c'est justement ce que je ne veux pas faire: si je génère un id à base de timestamp, il faudra que je trouve un moyen de faire passer l'id de page en page, par l'url, par ex, ou par cookie. Mais ça ne m'intéresse pas, je veux pouvoir m'affranchir complétement de ces choses horribles (cookie, c'est pas la peine d'expliquer, et id dans l'url, je trouve ça trop dangereux au niveau de la sécurité, et trop lourd à gérer. du coup, je cherche à générer un id, à partir du client, que je puisse regénérer à chaque page chargée de la même manière, et que j'obtienne à chaque fois le même. Il me faut donc des infos du navigateur du type, qui soit le plus "typique" possible.
Lascap
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer tes
id ? Ou bien faire une fonction prennant les memes regles de generation
que apache :
pid + ip + timestamp
Mais non mais non, c'est justement ce que je ne veux pas faire: si je génère
un id à base de timestamp, il faudra que je trouve un moyen de faire passer
l'id de page en page, par l'url, par ex, ou par cookie. Mais ça ne
m'intéresse pas, je veux pouvoir m'affranchir complétement de ces choses
horribles (cookie, c'est pas la peine d'expliquer, et id dans l'url, je
trouve ça trop dangereux au niveau de la sécurité, et trop lourd à gérer.
du coup, je cherche à générer un id, à partir du client, que je puisse
regénérer à chaque page chargée de la même manière, et que j'obtienne à
chaque fois le même. Il me faut donc des infos du navigateur du type, qui
soit le plus "typique" possible.
Pourquoi ne pas utiliser le mod unique_id de apache pour te generer tes id ? Ou bien faire une fonction prennant les memes regles de generation que apache : pid + ip + timestamp
Mais non mais non, c'est justement ce que je ne veux pas faire: si je génère un id à base de timestamp, il faudra que je trouve un moyen de faire passer l'id de page en page, par l'url, par ex, ou par cookie. Mais ça ne m'intéresse pas, je veux pouvoir m'affranchir complétement de ces choses horribles (cookie, c'est pas la peine d'expliquer, et id dans l'url, je trouve ça trop dangereux au niveau de la sécurité, et trop lourd à gérer. du coup, je cherche à générer un id, à partir du client, que je puisse regénérer à chaque page chargée de la même manière, et que j'obtienne à chaque fois le même. Il me faut donc des infos du navigateur du type, qui soit le plus "typique" possible.
Lascap
Lascap
Oui c'est une bonne question que je me suis déjà posée. Mais je n'ai pas trouvé de réposnes. De plus je pense que s'il existait quelque chose qui caractérise un poste de façon absoluement certaine et unique je pense que tous les gens qui ont eu à implémenter des systèmes de session ne se seraient pas ennuyés avec des cookies, mais auraient utilisé cela (à commencer par les développeurs php).
c'est bien le problème :(
Après mûre réflexion je m'étais dit que le seul élément vraiment unique était la MAC adresse de la carte réseau. Mais ça ne tient pas car, d'une part je ne pense pas que php puisse récupérer cette info, ensuite de l'extérieur, de même qu'on voit uniquement l'adresse IP de ma passerelle on
ne voit que sa macadress à elle. De plus quand on est plusieurs (c'est le cas chez moi) à travailler de petits terminaux sur un poste linux on a aussi une IP unique et une mac adresse unique pour tous.
oui, bon, je n'ai pas pensé aller si loin, non plus... mais c'est uniquement parce que le niveau de sécurité que l'on souhaite dépend en grande partie du niveau d'importance des données que l'on traite, et que dans mon cas, les données n'ont pas une si grande importance que ça... c'est su que si je bossais pour une banque, je ferais moins le malin.
Par contre je vais regarder ton code car il peut avoir un intérêt pour débusquer quelqu'un qui voudrait usurper une session (sur un autre réseau bien entendu sinon on retombe dans ce dont on parlait plus haut).
l'ursupation de session... la grande question... en fait, jusqu'ici, je m'étais dit que niveau sécurité ce n'était pas mal, mon système, jusqu'au moment ou je me suis dit que le HTTP_USER_AGENT de certains navigateurs se modifie aisément... et que une adresse ip, c'est usurpable.. du coup, le hackeur (assez renseigné sur mon système de session, qd même, ainsi que sur le type qu'il voudrait hacker (mais pour le deuxieme point, un coup de sniff permet sans aucuns doutes d'avoir les infos nécessaires) pourrait bidouiller son http_user_agent, son ip, pour avoir la même signature que l'autre type. encore faudrait-il qu'il soit au même moment sur le réseau. De toute façon, il n'aurait pas besoin de faire ça, je pense. Il suffirait d'une "sequence reloading" sur le couple login-mot de passe qui si ça se trouvent ne sont même pas cryptés pour avoir tout ce qu'il veut.
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à http
autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un protocole non connecté en protocole connecté.
Ben oui, le pire c'est que c'est vrai. Tant qu'on sera en non connecté, le problème des sessions ne sera jamais jamais résolu.
:(( Lascap, en larmes, mais qui sens qu'il va "dire que les gens qui vont sur le même site derrière un proxy avec des systèmes clonés sont qd même vachement trop rares ;)" ... ouh comme c'est pas beau, ce que je me prépare à faire
Oui c'est une bonne question que je me suis déjà posée. Mais je n'ai pas
trouvé de réposnes. De plus je pense que s'il existait quelque chose qui
caractérise un poste de façon absoluement certaine et unique je pense que
tous les gens qui ont eu à implémenter des systèmes de session ne se
seraient pas ennuyés avec des cookies, mais auraient utilisé cela (à
commencer par les développeurs php).
c'est bien le problème :(
Après mûre réflexion je m'étais dit que le seul élément vraiment unique
était la MAC adresse de la carte réseau. Mais ça ne tient pas car, d'une
part je ne pense pas que php puisse récupérer cette info, ensuite de
l'extérieur, de même qu'on voit uniquement l'adresse IP de ma passerelle
on
ne voit que sa macadress à elle. De plus quand on est plusieurs (c'est le
cas chez moi) à travailler de petits terminaux sur un poste linux on a
aussi une IP unique et une mac adresse unique pour tous.
oui, bon, je n'ai pas pensé aller si loin, non plus... mais c'est uniquement
parce que le niveau de sécurité que l'on souhaite dépend en grande partie du
niveau d'importance des données que l'on traite, et que dans mon cas, les
données n'ont pas une si grande importance que ça... c'est su que si je
bossais pour une banque, je ferais moins le malin.
Par contre je vais regarder ton code car il peut avoir un intérêt pour
débusquer quelqu'un qui voudrait usurper une session (sur un autre réseau
bien entendu sinon on retombe dans ce dont on parlait plus haut).
l'ursupation de session... la grande question... en fait, jusqu'ici, je
m'étais dit que niveau sécurité ce n'était pas mal, mon système, jusqu'au
moment ou je me suis dit que le HTTP_USER_AGENT de certains navigateurs se
modifie aisément... et que une adresse ip, c'est usurpable.. du coup, le
hackeur (assez renseigné sur mon système de session, qd même, ainsi que sur
le type qu'il voudrait hacker (mais pour le deuxieme point, un coup de sniff
permet sans aucuns doutes d'avoir les infos nécessaires) pourrait bidouiller
son http_user_agent, son ip, pour avoir la même signature que l'autre type.
encore faudrait-il qu'il soit au même moment sur le réseau. De toute façon,
il n'aurait pas besoin de faire ça, je pense. Il suffirait d'une "sequence
reloading" sur le couple login-mot de passe qui si ça se trouvent ne sont
même pas cryptés pour avoir tout ce qu'il veut.
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à
http
autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un
protocole non connecté en protocole connecté.
Ben oui, le pire c'est que c'est vrai. Tant qu'on sera en non connecté, le
problème des sessions ne sera jamais jamais résolu.
:((
Lascap, en larmes, mais qui sens qu'il va "dire que les gens qui vont sur le
même site derrière un proxy avec des systèmes clonés sont qd même vachement
trop rares ;)" ... ouh comme c'est pas beau, ce que je me prépare à faire
Oui c'est une bonne question que je me suis déjà posée. Mais je n'ai pas trouvé de réposnes. De plus je pense que s'il existait quelque chose qui caractérise un poste de façon absoluement certaine et unique je pense que tous les gens qui ont eu à implémenter des systèmes de session ne se seraient pas ennuyés avec des cookies, mais auraient utilisé cela (à commencer par les développeurs php).
c'est bien le problème :(
Après mûre réflexion je m'étais dit que le seul élément vraiment unique était la MAC adresse de la carte réseau. Mais ça ne tient pas car, d'une part je ne pense pas que php puisse récupérer cette info, ensuite de l'extérieur, de même qu'on voit uniquement l'adresse IP de ma passerelle on
ne voit que sa macadress à elle. De plus quand on est plusieurs (c'est le cas chez moi) à travailler de petits terminaux sur un poste linux on a aussi une IP unique et une mac adresse unique pour tous.
oui, bon, je n'ai pas pensé aller si loin, non plus... mais c'est uniquement parce que le niveau de sécurité que l'on souhaite dépend en grande partie du niveau d'importance des données que l'on traite, et que dans mon cas, les données n'ont pas une si grande importance que ça... c'est su que si je bossais pour une banque, je ferais moins le malin.
Par contre je vais regarder ton code car il peut avoir un intérêt pour débusquer quelqu'un qui voudrait usurper une session (sur un autre réseau bien entendu sinon on retombe dans ce dont on parlait plus haut).
l'ursupation de session... la grande question... en fait, jusqu'ici, je m'étais dit que niveau sécurité ce n'était pas mal, mon système, jusqu'au moment ou je me suis dit que le HTTP_USER_AGENT de certains navigateurs se modifie aisément... et que une adresse ip, c'est usurpable.. du coup, le hackeur (assez renseigné sur mon système de session, qd même, ainsi que sur le type qu'il voudrait hacker (mais pour le deuxieme point, un coup de sniff permet sans aucuns doutes d'avoir les infos nécessaires) pourrait bidouiller son http_user_agent, son ip, pour avoir la même signature que l'autre type. encore faudrait-il qu'il soit au même moment sur le réseau. De toute façon, il n'aurait pas besoin de faire ça, je pense. Il suffirait d'une "sequence reloading" sur le couple login-mot de passe qui si ça se trouvent ne sont même pas cryptés pour avoir tout ce qu'il veut.
et dire que tous ces ennuis c'est juste parce qu'on veut faire faire à http
autre chose que ce pour quoi il a été conçu... qu'on veut faire marcher un protocole non connecté en protocole connecté.
Ben oui, le pire c'est que c'est vrai. Tant qu'on sera en non connecté, le problème des sessions ne sera jamais jamais résolu.
:(( Lascap, en larmes, mais qui sens qu'il va "dire que les gens qui vont sur le même site derrière un proxy avec des systèmes clonés sont qd même vachement trop rares ;)" ... ouh comme c'est pas beau, ce que je me prépare à faire
Lascap
Bon... ahem... Amusant...
comme tu dis... :)
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
la résolution d'écran, oui, c'est pt'et un truc à retenir, ça. si je concatene tout plein de trucs du style, et que j'utilise md5 pour en faire un id plus court, ça peut finalement amener à quelque chose.
par contre l'applet java, hein, heu... je srais plutot pour du bete javascript. ;)
Bon... ahem... Amusant...
comme tu dis... :)
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id
unique (enfin, un peu moins générique disons) ? la résolution d'écran,
peut-être le nom de l'utilisateur (et encore je connais rien à java
alors)..
la résolution d'écran, oui, c'est pt'et un truc à retenir, ça. si je
concatene tout plein de trucs du style, et que j'utilise md5 pour en faire
un id plus court, ça peut finalement amener à quelque chose.
par contre l'applet java, hein, heu... je srais plutot pour du bete
javascript. ;)
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
la résolution d'écran, oui, c'est pt'et un truc à retenir, ça. si je concatene tout plein de trucs du style, et que j'utilise md5 pour en faire un id plus court, ça peut finalement amener à quelque chose.
par contre l'applet java, hein, heu... je srais plutot pour du bete javascript. ;)
marc guillaume
Guillaume Bouchard wrote:
Mais php à le truc parfait pour faire ca, les cookies. Pourquoi vous embetez vous avec des trucs a l'arach alors que les cookies sont là pour ca. De nos jours tout les navigateurs supportent les cookies, et ceux qui les ont désactivés savent pourquoi et savent qu'ils se privent d'une possibilité...
je ne dirais pas que les cookies soient une chose parfaite... c'est un pis aller, je suis d'accord, c'est ce qu'on a trouvé de moins mauvais, sans doute, mais au point de vue de la sécurité et de la simple satisfaction intellectuelle, ce n'est pas ça...
Je n'aime ni les cookies ni le javascript, car c'est trop aléatoire. Et pourtant comme tout le monde je les utilse... en râlant ! Ce sont les "jambes de bois" du web.
Allez, bon WE.
Guillaume Bouchard wrote:
Mais php à le truc parfait pour faire ca, les cookies.
Pourquoi vous embetez vous avec des trucs a l'arach alors que les
cookies sont là pour ca. De nos jours tout les navigateurs supportent
les cookies, et ceux qui les ont désactivés savent pourquoi et savent
qu'ils se privent d'une possibilité...
je ne dirais pas que les cookies soient une chose parfaite... c'est un pis
aller, je suis d'accord, c'est ce qu'on a trouvé de moins mauvais, sans
doute, mais au point de vue de la sécurité et de la simple satisfaction
intellectuelle, ce n'est pas ça...
Je n'aime ni les cookies ni le javascript, car c'est trop aléatoire. Et
pourtant comme tout le monde je les utilse... en râlant ! Ce sont les
"jambes de bois" du web.
Mais php à le truc parfait pour faire ca, les cookies. Pourquoi vous embetez vous avec des trucs a l'arach alors que les cookies sont là pour ca. De nos jours tout les navigateurs supportent les cookies, et ceux qui les ont désactivés savent pourquoi et savent qu'ils se privent d'une possibilité...
je ne dirais pas que les cookies soient une chose parfaite... c'est un pis aller, je suis d'accord, c'est ce qu'on a trouvé de moins mauvais, sans doute, mais au point de vue de la sécurité et de la simple satisfaction intellectuelle, ce n'est pas ça...
Je n'aime ni les cookies ni le javascript, car c'est trop aléatoire. Et pourtant comme tout le monde je les utilse... en râlant ! Ce sont les "jambes de bois" du web.
Allez, bon WE.
marc guillaume
Zouplaz wrote:
Bon... ahem... Amusant... Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
ouaip mais moi je suis allergique à java... je n'ai pas de JVM sur mon poste. On retombe toujours sur le problème des cookies, il faut la participation du client. C'est une démarche non universelle.
Zouplaz wrote:
Bon... ahem... Amusant...
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id
unique (enfin, un peu moins générique disons) ? la résolution d'écran,
peut-être le nom de l'utilisateur (et encore je connais rien à java
alors)..
ouaip mais moi je suis allergique à java... je n'ai pas de JVM sur mon
poste. On retombe toujours sur le problème des cookies, il faut la
participation du client. C'est une démarche non universelle.
Bon... ahem... Amusant... Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id unique (enfin, un peu moins générique disons) ? la résolution d'écran, peut-être le nom de l'utilisateur (et encore je connais rien à java alors)..
ouaip mais moi je suis allergique à java... je n'ai pas de JVM sur mon poste. On retombe toujours sur le problème des cookies, il faut la participation du client. C'est une démarche non universelle.
Guillaume Bouchard
Lascap wrote:
moi perso je n'aime pas du tout du tout.. et en fait il y a finalement beaucoup plus de personne que tu crois qui les désactives.
Je ne tient pas à trooler, mais ceux qui désactivent les cookies, c'est leurs problemes si ils sont parano ou je ne sais quoi...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de bien caracteristique pour faire un id et de plus faire un ID en GET.
là je t'arrete tout de suite, il est hors de question que je passe l'id de session une seule fois en get, post ou autre
Oki, alors tu le passes ou ?
et là encore, grace au subterfuge du md5, pour que le gars devine que l'id est généré à coup d'ip, de user_agent voire de résolution ou autre, faut qu'il soit fort, ou alors qu'il suive de près les post de fr.comp.lang.php ;)
Et si quelqu'un developpe ce systeme dans un projet open source qui se retrouve courament utilisé ?
-- Guillaume.
Lascap wrote:
moi perso je n'aime pas du tout du tout.. et en fait il y a finalement
beaucoup plus de personne que tu crois qui les désactives.
Je ne tient pas à trooler, mais ceux qui désactivent les cookies, c'est
leurs problemes si ils sont parano ou je ne sais quoi...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de
bien caracteristique pour faire un id et de plus faire un ID en GET.
là je t'arrete tout de suite, il est hors de question que je passe l'id de
session une seule fois en get, post ou autre
Oki, alors tu le passes ou ?
et là encore, grace au subterfuge du md5, pour que le gars devine que l'id
est généré à coup d'ip, de user_agent voire de résolution ou autre, faut
qu'il soit fort, ou alors qu'il suive de près les post de fr.comp.lang.php
;)
Et si quelqu'un developpe ce systeme dans un projet open source qui se
retrouve courament utilisé ?
moi perso je n'aime pas du tout du tout.. et en fait il y a finalement beaucoup plus de personne que tu crois qui les désactives.
Je ne tient pas à trooler, mais ceux qui désactivent les cookies, c'est leurs problemes si ils sont parano ou je ne sais quoi...
Sinon je reviens sur l'aberation d'esseyer de trouver quelques chose de bien caracteristique pour faire un id et de plus faire un ID en GET.
là je t'arrete tout de suite, il est hors de question que je passe l'id de session une seule fois en get, post ou autre
Oki, alors tu le passes ou ?
et là encore, grace au subterfuge du md5, pour que le gars devine que l'id est généré à coup d'ip, de user_agent voire de résolution ou autre, faut qu'il soit fort, ou alors qu'il suive de près les post de fr.comp.lang.php ;)
Et si quelqu'un developpe ce systeme dans un projet open source qui se retrouve courament utilisé ?
