Kazumi
dimanche 15 avril 2007 à 13:40
/* simple quote, double-quote == évil car analyse de la chaine pour remplacement des variables, test de l'existence de la variable en cas de requête forgée par un p'tit malin */
if(isset($_POST['pseudo']) && $_POST['pseudo'] != '' && isset($_POST['mdp']) && $_POST['mdp'] != '') {
// traitement de l'erreur
}
// faire ta connexion à MYSQL ici, traiter les erreurs de connexion
$pseudo = str_replace('"', '\"', $_POST['pseudo']); // parade à l'
SQL Injection, comme le disait Méthylbro
$login = mysql_query('SELECT mdp FROM inscrits WHERE pseudo="'.$pseudo.'";'); // concaténation manuelle
// traitement de la requête ici
Le mot de passe devrait être en plus hashé (pas de stockage en clair dans la base de données). Eviter le md5 qui est trop utilisé et dont des dictionnaires se trouvent facilement. Utiliser une comparaison et un mode de stockage "entier" et pas "chaîne" sur le hash obtenu pour plus de performance.
Je vérifierais le mot de passe en dehors de la requête, contrairement à Bashi, de façon à pouvoir personnaliser le message d'erreur (on peut savoir au row count si c'est le nom d'utilisateur qui est invalide ou à la comparaison si c'est le mot de passe). C'est peut-être pas forcément intéressant, voire risqué de personnaliser le message, mais en tout cas, on peut repérer plus facilement si quelqu'un tente de bruteforcer le système.
Pour les sessions, c'est pas très secure d'utiliser les sessions PHP. Les même problèmes s'appliquent qu'à la sécu des cookies. Le passer en GET, c'est pareil, c'est pas très bon. Cookies + HTTPS serait sans doute le plus fiable. Sans ça, faire son propre système de transaction de sessionid avec des clés changeantes... faudrait voir...