Reprise du message précédent :
ben euh la différence, c'est une question de ne pas mélanger les variables du header et des autres pages.
 
pour éviter le conflit entre les variables si tu préfères
 
par exemple tu es connecté mais tu as besoin de la variable $login pour faire autre chose, ben ça ne touchera pas la variable $loginheader qui te sert à l'identification

Artesia > Quelques remarques :
1) les sessions : Sur un serveur mutualisé (quand il y a plusieurs sites web sur le même serveur et qu'ils n'appartiennent pas à la même personne ou société) et si les sessions sont stockés dans des fichiers alors il y a un risque que les scripts d'un site arrive à consulter les fichiers de session des autres sites.
Il est donc très fortement déconseillé de mettre le mot de passe dans la session.
 
En plus de ça, à partir du moment où tu ne stockes le pseudo de l'utilisateur en session qu'après avoir vérifier le mot de passe alors l'existence du pseudo est suffisante pour vérifier que la personne s'est bien connecté. Le mot de passe n'apporte rien de plus en sécurité à ce moment là (au contraire d'ailleurs)
 
2) le SQL : Ta requête d'identification est sensible aux attaques : tu n'as pas protégé le texte que tu rajoutes dans ta requête de recherche de pseudo. Au mieux, je peux mettre comme pseudo "n'importe quoi' or 1='1" et je me connectes sans connaitre de pseudo valide. Ca c'est une attaque gentille. Une attaque plus méchante serait de provoquer des requêtes imbriquer ce qui ralentira énormément le serveur. Les pires attaques peuvent faire planter la base de donnée, détruire des tables, ...
 
Pour se protéger contre ça, il y a une fonction magique en php : mysql_real_escape_string.
 
3) sécurité / important : mot de passe stocké en clair = HORREUR !
Il n'y a aucune raison de garder un mot de passe en clair, que ça soit dans la base de donnée, dans un fichier, dans la session, ou ailleurs.
A noter que la base de donnée est capable de vérifier elle même le mot de passe même si c'est une version codé en md5, en sha ou par tout autre méthode. Il suffit juste de lui donner la version codé à l'inscription et à la vérification.
 
4) sécurité / bonnes habitudes : Il est préférable de vérifier en une seule fois la validité du pseudo et celle du mot de passe. Ca ne sert à rien de facilité la recherche des pseudos. Ca ne ferait qu'aider ceux qui veulent attaquer le site. Pour un site personnel, c'est quasiment sans importance mais mieux vaut prendre les bonnes habitudes dès le début.
 
 
Blatman09 > $login => vient d'un formulaire
$loginheader => vient de la session. Le terme header est d'ailleurs très mal choisit : ça n'a aucun rapport avec les header.
 
Pour le code que t'as récupéré sur le net. Je suis désolé, mais on ne t'aidera pas à le corriger sur ce forum. Je te ferais juste une remarque : il ne faut plus utiliser les variables créé automatiquement à partir des données reçu de l'extérieur. Cette création des variables est déjà désactivé par défaut avec php5 (mais réactivé par les hébergeurs comme free) et elle ne sera plus possible avec php6. Les données venant de l'extérieur doivent être récupéré dans $_POST, $_GET, $_FILES, $_SERVEUR et autres variables du genre.
Vu que tu nous a posté du code récupéré sur le net, je ne peux pas t'aider plus : c'est contraire à la charte de ce forum.

 
ok ok ! merci Artesia. je vais tester tout cela et tâcher de comprendre. Je te tiens au courant... !  

 
Je comprends et m'en excuse, mais j'ai préféré être franc. Merci tout de même pour les infos que tu me donnes.  

Ha mais j'avais bien compris. Ne t'inquiète pas. Je te disais juste pourquoi je ne t'aidais pas plus alors que ça se sent que t'essaye de comprendre et de faire mieux.

 
Ah je ne savais pas ça
J'ai un hébergeur que je paie annuellement
et j'utilise : session_save_path("repertoire que je veux" );
tous les sites web qui peuvent voir ce répertoire m'appartiennent (je suppose que c'est bon)
Mais je ne sais pas si c'est le cas pour blatman09
 

 
C'est bon à savoir
 
Je n'ai pas bien compris le coup 1='1' // Edit : ha si je viens de comprendre (chui trop bete de ne pas y avoir penser lol)
Je ne vois pas comment ça valide la recherche de pseudo // Edit : puis il suffit de mettre un mot de passe vide... (ha ouais lol)
le fait de mettre if ($rows==0) die(); ça ne protège pas ? // Edit : en effet ça ne protège pas
 
Et si on met un maxlengh à l'input du pseudo ? // Edit : Non plus...
 

 
Je stocke en md5 mais là j'ai oublié de le mettre dans mon message précédent  
 

 
C'est à dire ça facilite la recherche de pseudos ?
 

 
Alors ça, je n'ai pas compris du tout  

je n'en peux plus, je sature là. Mal à la tête !  
 
Merci Artesia, merci Omega2, je reviendrai demain, d'ici là, je vais poursuivre la lecture de "php pour les nuls".....
 
j'ai l'impression que je n'arriverai jamais à créer ma section membres sur ce site !

Ta requête : SELECT * FROM table WHERE login='$login'
Le pseudo : toto' or 1='1
le texte envoyé à la base de donnée : SELECT * FROM table WHERE login='toto' or 1='1'
 
Résultat : toutes les lignes sont retourné par la base de donnée vu que 1 est toujours égal à 1.

Avec cette faille, on s'en fiche de ce test : la base retourne des données (toutes les données)
 

ok, alors c'est bon.
 

pseudo : toto & mot de passe : trucmuche => "Cet identifiant n'existe pas"
pseudo : tata & mot de passe : trucmuche => "Cet identifiant n'existe pas"
pseudo : titi & mot de passe : trucmuche => "Vos identifiants ne sont pas corrects"
Chouet maintenant je n'ai plus qu'à varier le mot de passe vu que j'ai trouvé un pseudo existant.
 
Si tu testes les deux à la fois :
pseudo : toto & mot de passe : trucmuche => "Le pseudo ou le mot de passe est incorrect"
pseudo : tata & mot de passe : trucmuche => "Le pseudo ou le mot de passe est incorrect"
pseudo : titi & mot de passe : trucmuche => "Le pseudo ou le mot de passe est incorrect"
pseudo : tutu & mot de passe : trucmuche => "Le pseudo ou le mot de passe est incorrect"
Bon, ces pseudos ils existent ou pas? Je ne peux pas le savoir tant que je n'ai pas trouvé un couple de pseudo et de mot de passe ce qui est beaucoup plus long.
 

Formulaire : <input name="pseudo"/>
en php4 : $pseudo est créé
en php5 : $pseudo n'est pas créé avec les réglages par défaut mais on peut réactiver ce comportement dans le php.ini
en php6 : $pseudo n'est pas créé et on ne peut pas redemander le comportement qu'on avait en php4.
Avec le php5 en réglage par défaut ou en php6, on est obligé de récupérer la valeur dans $_POST['pseudo'] ou dans $_GET['pseudo'] ce qui est plus sécurisé vu qu'on sait d'où vient la valeur.
De plus dans le code si on oublie de créer une variable, on est sur de ne pas se retrouver avec une valeur qui viendrait d'un formulaire fait maison. (c'était une faille potentielle en php4)

Blatman09 > Ne soit pas déçu. Il faut toujours du temps quand on débute. Moi, j'ai débuté avec une calculatrice casio et je peux t'assurer que j'ai mis un grand nombre d'heures avant de m'en sortir un petit peu et j'avais beaucoup moins de choses à retenir que toi avec le php.
Apprend tranquillement à ton rythme.

 
 
merci de ta gentillesse (même si tu es dur parfois ! )
 
le souci c'est que le principal de mon collège me demande de faire une présentation du site à tous les collègues et que je manque de temps, voilà pourquoi je suis allé chercher des trucs tout fait sur le net.... idiot je le sais car :
 
1/ ça marche pas ou mal
2/ je n'y comprends rien.
 
 

un point d'acier dans un gant de velour?
 
Aller repose toi bien.

 
voilà !
 
Aller, bonne nuit à tout le monde, je reviendrai bien décidé à m'en sortir !  

Cool merci, je vais pouvoir améliorer la sécurité de mon site (pff faut que je me retape tous les formulaires de mes sites arf arf arf)
 
Je te comprends blatman09, je viens de lire le lien sur mysql_real_escape_string que m'a donné omega 2, j'ai aussi mal à la tete (bon de toute façon je ne ferais que utiliser la fonction)
 
Je viens de tester la faille sur le formulaire d'identification sur le site que je suis en train de construire, et je n'arrive pas à forcer l'identification, cela me renvoie les messages que j'ai programmé "Ce pseudo n'existe pas" (que je corrigerai par, "ce pseudo ou mot de passe n'existent pas" )
(enfin bon ça me fait penser au logiciel "brutus" et voilà, méthode bien bourrin lol)
 
Je me demande si mon hébergeur peut modifier le php de son serveur pour inclure certaine sécurité (il fournit un service sécurité) par exemple je n'ai pas besoin de mettre de addslashes ou stripslashes sur mes variables à la sortie d'un formulaire et cela ne fait pas planter mes scripts, alors qu'avant j'étais en php4 et le même scripts en faisait planter la page. (l'hébergeur propose un php4 ou php5 qu'on régle soi meme en fonction de nos sous domaines)

magic_quotes_gpc
C'est un réglage qui se trouve dans le php.ini (le fichier de configuration de php).
Comme indiqué dans la documentation, ça sera supprimé dès php6 : ça donnait une impression de sécurité, mais ça protège très mal (ça ne bloque pas tous les caractères pour tous les éléments attaquable) et ça a des effets secondaires (si tu postes le texte "je l'ai eu", la page php se retrouve avec "je l\'ai eu" )
 
Dans le cas présent, oui, ça bloque cette attaque là. Mais d'autres caractères peuvent être utiliser pour embêter le serveur mysql et tous le sont pas neutralisé par le magic_quotes_gpc.

Ah merci
 
Non ce ne doit pas être cette fonction car quand je regarde dans le table, il n'y a pas les \ devant les ' ou les "
Quand je récupère la variable ça ne met pas non plus les \ et je peux mettre des espaces dans mes pseudos, ça prend tout bien en charge. C'est bizarre lol
 
Je ne sais pas, c'est un mystère de l'informatique pour moi lol

Les antislash sont bien rajouté. mais mysql fait lui aussi des traitements sur les chaines de caractères qu'il reçoit. Grâce au magic_quotes_gpc, la requête que j'avais mis en exemple plus haut à partir de la tienne devient celle ci :
SELECT * FROM table WHERE login='toto\' or 1=\'1'  
 
Pour mysql, " \' " veut dire que le ' après "toto" et celui avant le dernier 1 n'indique pas la fin de la chaine qui commence par un ' mais qu'il est un caractère ' sans signification particulière.
On appelle ça échapper un caractère (faire précéder le caractère par un autre caractère, dans le cas présent l'antislash, pour enlever sa signification spéciale).
 
Grâce à ce principe, on peut mettre des ' dans une chaine qui commence par un ' et des " dan une chaine qui commence par un ". C'est le même système que pour le code php en fait.
 
Pour en revenir à cette requête, on a donc :
- magic_quotes_gpc qui rajoute les \ sans que tu le saches
- mysql qui comprend que \ suivit d'un caractère = le caractère
Ces deux effets s'annulent donc et les données inséré dans la table sont identique à ce qui est saisie par le visiteur.
 
Les inconvénients du magic_quotes_gpc, c'est que  
1) tu te rends pas compte de ce comportement de mysql et tu risques de te faire avoir quand tu récupères des données venus d'ailleurs (un fichier texte, ton propre code, des données retourné par une requête SQL, ...)
2) si tu affiches le texte saisie dans la nouvelle page, tu auras des slash qui vont se rajouter sans arrêt. C'est gênant si tu fais, par exemple, un formulaire dans lequel on saisie son pseudo, son mot de passe et un message. Celui qui se trompe devra corriger le texte de son message à chaque tentative.
3) comme dit plus haut, ça ne protège pas complètement les bases de données.
 
Il y a déjà eu plusieurs discutions sur le forum où on a donné le code qui permet de détecter et neutraliser le magic_quotes_gpc . Ensuite on peut travailler l'esprit tranquille en appliquant les bonnes protections en fonction de ce qu'on en fait (affichage dans la page avec htmlentities, stockage dans une base de donné avec les *escape_string, etc)
 
 
PS : J'espère ne pas être trop lourd et pas trop dur à comprendre.

euh

Bon, je vais essayer de faire sans grosse explication alors :
 
pseudo saisie : toto' or 1='1
 
sans magic_quotes_gpc :
requête reçu par mysql :
    SELECT * FROM table WHERE login='toto' or 1='1'  
description sommaire de la requête :
1) comparaison du contenu de la colonne "login" avec le texte "toto"
2) comparaison du chiffre 1 avec la chaine de caractère "1". Les deux sont considéré comme égaux par mysql.
3) on retourne toute les lignes dont le 'login' est 'toto' et toutes celles pour lesquelles 1 est égal à 1.
En résumé, on retourne tout.
 
 
Avec magic_quotes_gpc :
requête reçu par mysql :
    SELECT * FROM table WHERE login='toto\' or 1=\'1'  
description sommaire de la requête :
1) comparaison du contenu de la colonne 'login' avec le texte "toto' or 1='1".
2) On retourne donc les lignes dont le 'login' est "toto' or 1='1"
En résumé, on retourne soit une ligne soit aucune.
 
-------------------------------------------------
 
Maintenant, si on fait pareil avec un pseudo qui a une seule tilde, ça donne :
pseudo saisie : O'Reilly
 
sans magic_quotes_gpc :
requête reçu par mysql :
    SELECT * FROM table WHERE login='O'Reilly'  
description sommaire de la requête :
1) la chaine qui suit le = commence au premier ' et finis au second '.  
2) Mysql trouve du texte après la fin de la chaine et ce texte est pour lui incompréhensible.
3) Mysql retourne une erreur.
 
 
Avec magic_quotes_gpc :
requête reçu par mysql :
    SELECT * FROM table WHERE login='O\'Reilly'  
description sommaire de la requête :
1) comparaison du contenu de la colonne 'login' avec le texte "O'Reilly".
2) On retourne donc les lignes dont le 'login' est "O'Reilly"
En résumé, on retourne soit une ligne soit aucune.
 
 
 
-------------------------------------
Voilà pourquoi tes requêtes ne plantaient plus. Comme en plus mysql comprend que le texte \' doit devenir ' avant d'être utilisé pour les comparaisons ou le stockage, tu ne te rendais pas compte du rajout des antislash. C'était transparent/invisible pour toi.
 
 
A l'usage, la communauté qui utilise php c'est rendus compte que le magic_quote_gpc donne une fausse impression de sécurité par ce que les développeurs débutant pensent que leur site est protégé alors que ça ne bloque pas, entre autre, les attaques suivantes :
- attaque des bases de données avec des caractères autre que \, ' et "
- attaque d'une page html par exemple quand le texte reçu comprend du javascript sans tilde (explication ici )

oki merci j'ai compris