nicomilville
Messages postés3472Date d'inscriptionlundi 16 juillet 2007StatutMembreDernière intervention28 février 2014
-
29 juin 2008 à 19:52
Farfadh
Messages postés68Date d'inscriptiondimanche 1 avril 2007StatutMembreDernière intervention 7 juillet 2008
-
1 juil. 2008 à 20:04
Salut,
j'ai un formulaire avec des champs de type hidden auxquels j'essai d'assigné le résultat d'une requête SQL seuleument ça ne marche pas, pouvez vous me dire ce qui ne va pas ?
mysql_query("INSERT INTO connecte VALUES('','".time()."','".$_POST['pseudo']."','".$_SESSION['age']."','".$_SESSION['cp']."','".$_SERVER['REMOTE_ADDR']."')");
Farfadh
Messages postés68Date d'inscriptiondimanche 1 avril 2007StatutMembreDernière intervention 7 juillet 20084 1 juil. 2008 à 17:32
Ma connection a planté pendant toute une journée, je crois qu'elle m'a puni pour avoir été trop dur avec toi . Mais du coup j'ai bossé sur une source sur laquelle te reposer :
Ensuite, je sais très bien que je suis énervant quand je me donne l'air de tout savoir comme ça, mes élèves ne me supportaient pas. Mais vous n'êtes pas obligé de raconter des conneries juste pour le plaisir de me contredire. Donc, [auteur/NEIGEDHIVER/924195.aspx neigedhiver] :
"Si vous utilisez des sessions basées sur les cookies, vous devez
appeler
[file:///D:/M%C3%A9diath%C3%A8que/Documentation%20-%20D%C3%A9veloppement/PHP/Manuel%20PHP%20%28version%20compl%C3%A8te%29/function.session-start.html <tt>session_start</tt>]
avant d'afficher quoi
que ce soit au navigateur."
La configuration par défaut du système de sessions ne dépendant pas de ton bon vouloir ni du fait que ce soit comme ça chez toi. Elle dépend de ta distribution, ou de ton hébergeur, et c'est très partagé. Beaucoup de monde ici utilise Windows et est susceptible de tester ses sites en local via la solution EasyPHP qui utilise les cookies par défaut sur toutes les versions que j'ai connues. [auteur/NICOMILVILLE/1109562.aspx nicomilville] a déjà constaté que je suis sévère, mais je te garantie que je ne dis pas les choses pour rien.
Récupérer les cookies est une chose aisée, tout simplement parce que ça a déjà été fait et qu'il existe des logiciels créés à cet effet pour que le premier neuneu qui se prend pour un hacker puisse se croire malin en allant faire chier son monde. La plupart des piratages sont fait par des ignares en utilisant des solutions préconçues. D'autre part, les cookies sont stockés sur un fichier, et il y a tout ce qu'il faut sur ton disque dur pour les décoder, sans ça tu ne pourrais pas les lire toi même. Fin de la parenthèse, c'est possible, alors on se protège.
Quant aux informations de session, je viens de vérifier et ça a été corrigé depuis la première fois que je l'ai utilisé, car ça a bien été le cas dans les premières versions, ce qui avait soulevé un tôlé d'ailleurs. Quoi qu'il en soit, il y a d'autres failles qui surviennent en utilisant cette méthode.
Je suis tenté de rajouter une couche mais je vais m'arrêter sur le fait que je trouve anormal que tu puisses soutenir un code aussi mal ficelé, ce n'est pas un service que tu rends à son auteur. Son site pouvait buguer pour n'importe quelle raison, et il se serait arraché les cheveaux des semaines durant en cherchant vainement d'où ça pouvait venir. Allez voir ma source, sauf erreur de ma part, je prévoie toutes les éventualités et il est impossible de se retrouver avec des erreurs, MySQL par exemple, qui s'affichent en plein milieu de la page en cassant la présentation, comme on en voit trop souvent sur le Web. Je fabrique des sites professionnels et je n'ai pas droit à ce genre d'erreur, alors il faut espérer que je sais de quoi je parle.
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 1 juil. 2008 à 18:24
Salut,
J'aime bien discuter...
"Si vous utilisez des sessions basées sur les cookies, vous devez appeler <tt>session_start</tt> avant d'afficher quoi que ce soit au navigateur."
Ceci n'implique pas nécessairement l'utilisation de ob_start() : ça n'a même rien à voir.
Personnellement, je place la fonction session_start() suffisament tôt dans le code, de telle manière qu'aucun texte n'est renvoyé avant que tous les entêtes l'aient été.
C'est une possibilité, pas une obligation.
D'ailleurs, si on envoie du texte avant l'utilisation de session_start(), m'est avis que c'est un GRAVE problème de conception, pas du tout en accord avec le modèle MVC (qui, pour moi, fait référence).
Ensuite, ça fait 10 ans que je joue avec PHP, depuis la version 3 : jamais elles n'ont été transmises au client dans les cookies. La doc de PHP est très claire à ce sujet : elles sont gérées côté serveur, point barre. Il n'est fait nulle mention d'une quelconque correction concernant ce problème fantasmatique.
"La configuration par défaut du système de sessions ne dépendant pas de ton bon vouloir ni du fait que ce soit comme ça chez toi."
Oh ! Le pléonasme ! Forcément, la configuration par défaut dépend du bon vouloir des développeurs... Etait-il vraiment utile de le préciser ?
"Je suis tenté de rajouter une couche mais je vais m'arrêter sur le fait
que je trouve anormal que tu puisses soutenir un code aussi mal ficelé"
Ne te prive pas de rajouter une couche, je suis très open. Par contre, je suis curieux de savoir ce qui te fait penser que je soutiens ce code (lequel d'ailleurs ?). Parce que si tu me connaissais un peu, ce qui n'est évidemment pas le cas, tu saurais un peu ce que je préconise, les méthodes que je défends et prône. Si tu avais jeté un oeil à mes sources, tu aurais pu te faire une idée de ce qu'elles valent. Mais non, t'as posté 5 messages sur PHPCS... Et si tu veux, je peux faire des critiques sur ta source d'identification... Parce que je ne doute pas d'y trouver de la matière.
Bonne soirée.
<hr size="2" width="100%" />Neige
N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...
JoJo738
Messages postés1267Date d'inscriptionmercredi 7 juillet 2004StatutMembreDernière intervention29 juin 20102 29 juin 2008 à 22:51
Hello
Qu'est ce qui ne va pas ?
Par contre je viens de voir un truc avec tes hiddens ... Comment veut tu faire une requete SQL si _SESSION['pseudo'] n'existe pas ??? Et fait des vérifications (htmlentities(), mysql_string_escape(), isset(), ....) !
Ho ! Et deux connexions à MySQL ??? Quel intéret ? Surtout si il n'y a pas de déconnexions ...
Ah, et utilise mysql_query(...) or die(mysql_error());
^^
<hr />Si ma reponse te convient, merci de l'accepter !
Farfadh
Messages postés68Date d'inscriptiondimanche 1 avril 2007StatutMembreDernière intervention 7 juillet 20084 30 juin 2008 à 04:39
Je n'ai pas regardé en détail mais je vois des failles majeures dans ton code.
Déjà, $_SESSION est stocké dans les cookies donc l'écriture dans cette variable risque d'échouer la plupart du temps si tu n'active pas le buffer de sortie avec ob_start() au début. Deuxièmement, comme le contenu de $_SESSION est dicté par les cookies de l'utilisateur, tu ne peux absolument pas lui faire confiance pour lui confier des informations de connection, sinon, il suffit d'attendre que quelqu'un est connecté, entrer son pseudo dans les cookies et hop ! Tu as accès à son compte et tu n'as plus qu'à changer son mot de passe pour lui voler son compte. Et si tu veux y mettre une valeur moins évidente, voire même chiffrée, il est toujours possible de voler les cookies à ta victime pour ensuite lui dérober son compte.
Ensuite, pour tes requêtes MySQL, tu oublies de protéger les valeurs de tes chaînes avec mysql_real_escape_string() alors qu'il s'agit de données possiblement sensibles. Ensuite tu utilises mysql_num_rows() et un while sur mysql_fetch_array() sur des résultats qui contiennent au mieux un enregistrement, ce qui est très maladroit. Tu entres dans ta table de connections des informations sur l'utilisateur qui n'ont rien à faire là, et qui constituent une redondance de données particulièrement inutile, d'autant plus que tu voulais déjà sauvegarder ces données dans la session.
On va arrêter cette liste accablante avec le fait que tu ne nous donnes pas le moyen avec lequel tu rétablis une connection active. Je suis en train de préparer un code dont tu pourras te servir sans problème. A tout de suite.
neigedhiver
Messages postés2480Date d'inscriptionjeudi 30 novembre 2006StatutMembreDernière intervention14 janvier 201119 30 juin 2008 à 14:33
Salut,
@Farfadh : "Déjà, $_SESSION est stocké dans les cookies"
Au lieu de dire n'importe quoi, il serait bien de lire la doc de PHP : http://fr3.php.net/manual/fr/book.session.php Les sessions sont gérées côté serveur, SÛREMENT PAS côté client (ça fait même l'objet d'une question dans un test sur le site de Zend)
Lorsqu'on ouvre une session, seul l'identifiant de la session (retourné par session_id() ) est stocké sur le client. RIEN D'AUTRE.
Il peut être :
- stocké dans un cookie si la configuration le permet, et si le client l'accepte
- passé dans l'url si la configuration le permet (cf la directive de configuration session.use_trans_sid)
Par défaut le gestionnaire de session est 'files' : les sessions sont stockées dans des fichiers, écrits dans un répertoire spécifique (déterminé par la directive de configuration session.save_path). Le gestionnaire peut aussi être personnalisé, voire entièrement réécrit (on trouve même des sources sur phpCS pour utiliser une base de données).
Par conséquent, le tampon de sortie n'a absolument rien à voir dans l'histoire. La seule condition est qu'aucun entête ne soit envoyé au client avant l'ouverture de la session (qui tente de placer un cookie, ce qui est une requête HTTP)
"Deuxièmement, comme le contenu de $_SESSION est dicté par les cookies
de l'utilisateur, tu ne peux absolument pas lui faire confiance pour
lui confier des informations de connection,"
La question n'est pas là. Les sessions ne sont pas sécurisées : c'est là qu'est le problème. Placer un cookie est a priori relativement sûr (hormis le fait que sans utilisation de SSL, il circule en clair sur internet). Le vol de sessions est chose rare : récupérer un cookie d'un internaute n'est pas si aisé que cela (il faut sniffer le réseau, intercepter les paquets, identifier la personne, le site visité, spoofer l'ip du client...). Le principal risque est de laisser un cookie sur un ordinateur partagé.
Pour ce qui est du reste de la protection, il suffit de s'imposer quelques règles dans la gestion d'un compte (saisir le mot de passe actuel pour pouvoir le changer, etc).
Quoi qu'il en soit, les variables de sessions sont stockées sur le serveur et ne transitent pas sur le réseau. Point barre. Donc si un pseudo est stocké dans les variables de session, il ne sera pas stocké dans un cookie. Il sera stocké dans le fichier correspondant à la session de l'utilisateur (le tableau $_SESSION est d'ailleurs linéarisé avec serialize() avant d'être stocké, et délinéarisé avec unserialize() lorsque la session est restaurée).
Voilà pour la mise au point qui me paraissait vraiment nécessaire.
Bonne journée.
<hr size="2" width="100%" />Neige
N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...
JoJo738
Messages postés1267Date d'inscriptionmercredi 7 juillet 2004StatutMembreDernière intervention29 juin 20102 30 juin 2008 à 18:47
Lu' ^^
Et avec un code de ce genre ?
<?php
session_start();
// include 'mysql_connexion.php';
if( isset($_POST['pseudo'], $_POST['password']) )
{
$pseudo = mysql_real_escape_string($_POST['pseudo']);
$password = mysql_real_escape_string($_POST['password']);
$query mysql_query('SELECT id FROM utilisateurs WHERE pseudo "' . $pseudo . '" AND password = "' . $password . '" ') or die(mysql_error());
if( mysql_num_rows($query) <> 1 )
{
echo 'Ce compte n\'existe pas, merci de [inscription.php vous inscrire]';
}
else
{
$row = mysql_fetch_assoc($query); $_SESSION['id'] = $row -> id;
// Perso, je stocke l'ID du membre (au pire des cas avec transmission d'une clé généré lors de la connection et avec un petit UPDATE (en dessous) je le mémorise
// mysql_query('UPDATE utilisateurs SET time_connexion NOW(), ip "' . $_SERVER['REMOTE_ADDR'] . '" WHERE id = ' . $row -> id) or die(mysql_error());
// * Mettre ' . $time() . ' à la place de NOW() en fonction du type de champ (varchar, int, date, ...)
// * Je conseil d'utiliser une fonction pour trouver l'IP .... Faut pas oublier les proxys ;)
}
}
?>
<form action ="?" method="POST">
<label for="pseudo">Pseudo :</label>
<label for="password">Mot de passe :</label>
</form>
<hr />Si ma reponse te convient, merci de l'accepter !
Farfadh
Messages postés68Date d'inscriptiondimanche 1 avril 2007StatutMembreDernière intervention 7 juillet 20084 1 juil. 2008 à 20:04
1. Là, on voit clairement un manque d'expérience. Certains hébergements envoient des données sans te demander ton autorisation, ou bien encore le PHP peut générer une alerte imprévue (personne n'est à l'abri de laisser un petit bug ou une petite faille parmi les centaines de lignes dans les dizaines de scripts de son code). La seule solution pour les contrer, et de toute manière d'être absolument certain que ton code va marcher, c'est d'utiliser la bufferisation de sortie, et pour d'autres raisons un gestionnaire d'erreurs personnalisé. Un code bien conçu ne commence pas l'écriture de la réponse avant d'avoir effectué tous les traitements les plus délicats qui sont les plus susceptibles de générer des erreurs - d'autant plus qu'il vaut mieux avoir un code HTML brut le plus lisible possible et ne pas commencer par exemple à y faire ses reqêtes MySQL - donc activer la bufferisation de sortie pendant ces traitements ne mange pas de pain.
Pour ces raisons, il faut systématiquement utiliser la bufferisation de sortie avant de générer la réponse. C'est une question de rigueur et de sécurité, des notions dont tout développeur devrait connaître l'importance.
2. Là, je suis très ennuyé. Comment t'expliquer que la version 3 n'est pas la première version ? Là tu me poses une colle. Tu veux que je rédige une thèse là-dessus ? Sinon merci de m'avoir fait remarqué que ça a changé depuis, je ne pouvait pas m'en rendre compte parce que de toute manière, je n'ai jamais eu l'occasion de croiser une application pour laquelle on a besoin de stocker des informations là-dedans. Ce serait maladroit, sauf situation exceptionnelle que je n'ai jamais rencontré.
3. Apparement tu avais besoin qu'on te le rappelle. D'autant plus que tu ne comprends toujours pas. La configuration par défaut ne dépend pas des développeurs du service mais ceux de la distribution ou des administrateurs du serveur sur lequel il est installé. Donc tu ne peux pas t'y fier, et prétendre que les cookies ne sont pas utilisés par défaut est une erreur puisque je t'ai donné au moins un exemple probant du contraire. Ou peut-être es-tu partisant du sophisme qui veut qu'une exception confirme une règle.
4. Tu soutiens le code parce que tu confortes l'auteur sur sa position. Si tu ne t'en rends pas compte, c'est peut-être que tu as des problèmes de communication aussi importants que les miens. Tu l'auras remarqué mais je parais extrèmement pédant lorsque je parle technique. Ceci dit, je suis quand même ouvert aux opinions des autres, puisque j'ai été vérifier chacune de tes affirmations avant de prétendre d'avoir raison. J'espère que tu en as fait de même pour moi, mais j'ai des doutes.
Voici quelques citations pour prouver que je n'invente rien :
Manuel PHP :
"Les sessions reposent sur un identifiant de session, ce qui signifie
que quelqu'un peut voler cet identifiant, rien qu'en volant l'ID. Ce vol
peut être rendu très difficile, comme par exemple en utilisant les
cookies, mais en aucun cas cela sera impossible. [...] De plus, même les cookies de session peuvent être
surveillés sur un réseau, ou bien notés par un proxy."
A noter qu'ils n'ont pas parlé des spywares que l'on peut avoir sur sa machine sans s'en appercevoir. Ils peuvent être contractés par des sources fiables, la plupart des vols de compte se faisant par une personne connue - au moins virtuellement - par l'utilisateur.
Trouvé sur un forum :
"Et je le répète, la session marche bien sous easyPHP [...], c'est sur le net que ça marche plus :cry: Ce
n'est donc pas un quelconque oubli... [....]
voilà ce que j'ai :
Warning: Cannot send session cookie - headers already sent by (output started at /www/test.php:2) in test.php on line 3
Warning: Cannot send session cache limiter - headers already sent (output started at /www/test.php:2) in test.php on line 3"
Son hébergeur a simplement envoyé des données sans qu'il s'en apperçoive. Sur le forum, personne n'a pensé à ce problème et ce dernier n'a pas été résolu. Quand moi j'y ai été confronté, je n'ai trouvé aucune réponse sur le Web, et c'est en utilisant ob_start par exaspération pour supprimer toute possibilité que des données soient envoyées que j'ai fini par conprendre le problème, et qu'effectivement le début du code HTML généré ne correspondait pas exactement à celui que j'envoyais. Donc je ne suis pas de mauvais conseil à ce sujet, je dirai même que je vous donne une information très utile.
Trouvé sur un forum :
"Cela fonctionnera si le serveur de destination accepte les identifiants
de session par cookie (ce qui est en principe le cas par défaut)."
Quelqu'un a fait la même erreur que toi, mais dans l'autre sens. Je pense toutefois que les cookies sont généralement utilisés pas défaut, parce que ça a été le cas chez tous mes hébergeurs et sur toutes les distributions que j'ai utilisé. D'ailleurs, j'impose la plupart du temps à mes utilisateurs d'activer leurs cookies, parce que je ne comprend pas pourquoi on voudrait s'en passer, surtout qu'ils sont aujourd'hui très largement répandus. Quelle distribution utilises-tu ?
Sinon je ne trouve pas de source prouvant que le stockage des informations de sessions se faisait par cookie. C'est probablement trop vieux et ça a dû être vite résolu, d'autant plus que ce n'était pas logique de procéder ainsi. Mais je ne comprend pas pourquoi c'est si dur de me croire. La plupart des solutions que l'on a aujourd'hui en matière de sécurité, nous les devons à des correctifs d'anciennes failles. Pourquoi pas pour les sessions ?