Bjr,
j'essaye de créer un petit système d'authentification, et je cherche a boucher les trous de securité =) !

Mon code est-il vulnerable aux injections SQL ?
Je ne suis pas sur dans le sens où seul le login ($data[0]) est transmis dans la requete SQL et je ne voi pas quelle valeur peut lui permettre de fausser le resultat... (cf ligne 6 & 7)

contre le mal nommé 'cross site scripting', sufit il de filtrer les caractères "<" et ">" ?
quelles autres failles pouvez vous identifier ds ce code ? (les mdp st en clair mais c'est juste pr l'exemple...)

merci d'avance

houla!! renseigne toi sur l'injection SQL, parce que là, ça craint velu !
http://fr.wikipedia.org/wiki/Injection_SQL

Et je te suggère de t'acheter toi le dernier hors série MISC sur la sécurité si il est encore dispos.

vw

http://fr.php.net/pdo/

ce que j'aimerai ca serai un exemple de ce qu'un utilisateur malveillant pourrai faire et ce qu'il devrai entrer comme login pr le faire...

pdo ? en quoi ca aiderai pr mon pbleme ?

Exemple, si je rentre comme login "admin '--", je suis bien enregistré comme utilisateur admin (si il existe) sans le mot de passe.

Et regarde bien en détails l'article wikipedia que je t'ai donné en lien.

vw

non

j'ai qd meme pris la peine de verifier le mdp ensuite par php
cf ligne 18 stp...

mais merci de m'aider

Pourquoi non?
Je t'avoue que je n'ai pas testé ton code, mais tu mets directement dans une requête ce que rentre l'utilisateur sans traitement, ce sont les conditions idéales d'une injection SQL.
 
vw

ma requete est la suivante:
 
SELECT login, pass FROM $table WHERE login='$data[0]'
 
si $data[0] à été renseigné par l'utilisateur: admin'--
alors la requete devient:
SELECT login, pass FROM $table WHERE login='admin'--'
mais comme la verification n'a pas lieu à ca niveau...

edit: c'es vrai qu'en réalité il ya injection de code, mais ce n'est pas nuisible j'ai l'impression...
edit2: oups

Ca me parait clair que tu as une énorme faille de type injection SQL.
Login : ' OR ''='
Pass : un pass au hasard
 

$query = "SELECT login, pass FROM $table WHERE login='$data[0]'";

devient :

$query = "SELECT login, pass FROM $table WHERE login='' OR ''=''";

 
L'expression ''='' étant toujours vraie, la requête sélectionne toutes les lignes de ta table.

ah oui en effet...

Tu peux t'en sortir avec mysql_real_escape_string, mais je te conseille de passer directement à PDO, qui échappe pour toi les entrées (pas d'oubli) et qui te permet de passer d'un SGBD à un autre assez facilement.
 
Dans un autre registre, je pense que tu peux t'instruire sur les failles de cross site scripting (vérifier que des données entrantes appartiennent à un domaine acceptable) et de man in the middle (la fonction hash est ton amie)

pour le cross site scripting, un verification de "<" et ">" suffit-elle ?

Non, pas du tout.
Regarde un peu ici : http://phpsec.org/projects/guide/fr/index.html

Le truc ultra important : addslashes();
 
Sinon : http://fr.wikipedia.org/wiki/Injection_SQL, cette doc est pas mal faite.

le truc super important les requêtes préparées, point

Ok, je vais voir pour les requetes préparée plus tard, mais là je m'interesse aux details techniques car je m'initie au php.  
Il me parait important d'avoir bien compris les problèmes de cross-scripting et d'injection SQL avant d'adopter la solution parfaite (que je serais peut-être en mesure de choisir ensuite).
 
J'ai donc (temporairement) utilisé mysql_real_escape_string() comme on me l'a suggéré, ce qui fonctionne à merveille.
 
J'ai cru comprendre que le cross-scripting n'était possible que si les donnée envoyée par le client étaient retransmise au navigateur client.
 
Dans la mesure où ce test de page d'authentification n'affiche rien dans aucune page qui provienne du client (seul un test du couple pass/login est effectué sur la BD, d'où le pb d'injection SQL), je n'ai pas a craindre de cross-scripting sur mon site ?

T'as lu le lien de CyberDenix

Voila ce que j'ai lu :
 

 
http://phpsec.org/projects/guide/fr/2.html#2.3
 

1 - Il est tres vivement conseillé d'echapper le nom des champs SQL
2 - Evite des concaténation hasardeuses genre :

Quand il faudrait faire:

D'ailleurs il a été démontré sur plusieurs sites que la déclaration de chaines avec des " au lieu de ' plus adaptés doublait presque le temps d'exécution dufait d'une tentative d'interpréter la chaine.
3 - evite de faire :

Mais fais plutot (L'utilisation de l'operateur ternaire est assez discutable d'ailleurs ... ) :

Je vois pas pourquoi tu fais un session_rgenerate_id() si c'est pas bon, tu rediriges vers une autre page pour vider ton postDADA et tu raffiches ton form

Que si les GPC sont désactivées ! Et d'ailleurs il est préférables d'utiliser mysql_real_escape_string() ou sprintf()

Enfin dernier p'tit truc :
evite de faire du echo directement dans le code. A la limite stocke dans une variable et fais un echo a la fin. Car si a un moment posterieur tu veux faire une redirection ou un envoi de header quelconque , ca sera impossible. Dans ton cas c'est pas important mais ca peux se révéler très utile sur d'autres script

Le "session_rgenerate_id()" est mal placé c'est vrai, je l'ai remonté en haut de la page juste sous le "session_start" pour prevenir la fixation de session.
 
Concernant les messages en echo, c'était pour l'exemple mais en réalité et comme tu le dit tt passe ds des variable car parfois une redirection intervient avant... Mais merci des details =)

 
Il s'agit de vérifier que toute donnée reçue correspond à une valeur acceptable, avant d'effectuer un traitement quelconque dessus (affichage, insertion dans une base de données, etc.).
 
Imagines que tu créées un formulaire d'inscription utilisateur avec une option sexe à Homme ou Femme, et qu'un petit rigolo recopies ton formulaire en local et y en ajoutant un troisième champ Extraterrestre. Il le sélectionne et pouf il s'incrit en tant qu'extraterrestre...
 
Pour éviter ça, tu peux par exemple créer une table sexe (id, name) avec deux valeurs :  
1 - Homme
2 - Femme
Puis tu regardes dans ta base de données si la donnée reçue correspond à une ligne de ta table sexe :  
SELECT 1 FROM sexe WHERE name = '...'
Si aucune ligne n'est sélectionnée, c'est que tu as (peut-être) une tentative de cross site scripting.
Sinon, tu peux inscrire ton utilisateur.