Discussion :

[Amnael]

Voici ma page de traitement d'inscription à mon site

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
<?php 
	session_start();
	$log=$_POST['Pseudo'];
	$mdp=$_POST['password'];
	$mail=$_POST['mail'];
    $langue=$_COOKIE['langue'];
	//connection base
	require_once("./../BD/connect.php"); //inclusion du fichier connect.php	 
 
    $connexion = mysqli_connect(SERVEUR,NOM,PASSE,BASE);
	if(!$connexion) //si erreur
    {
    	if($_COOKIE['langue']=="French"){
        	echo "Désolé, connexion à ".SERVEUR." temporairement impossible !";
        	echo "Essayez plus tard !";
        }
        if($_COOKIE['langue']=="English"){
        	echo "Sorry, connection to ".SERVEUR." isn't available for the moment !";
        	echo "Try later !";
        }
    }		  
 
    //CONNEXION OK
    $requete="select pseudo from Utilisateur "; 
    $resultat=mysqli_query($connexion,$requete);
    while($emp=mysqli_fetch_assoc($resultat))
	{
		if($emp['pseudo']==$log){
			$_SESSION['wrongUser']=$log;
			header('Location: inscription.php');
			//si pseudo déjà pris on repart à l'inscription
		}
	}
	//on s'inscrit si pseudo libre
	$inscription="insert into Utilisateur(pseudo,mdp,mail,langue,avatar,nbFile,nbCom) values 
    ('$log','$mdp','$mail','$langue','',0,0)";
 
    $resultat=mysqli_query($connexion,$inscription) or die ('Erreur SQL ! <br />'.mysqli_error());
?>

Je vous explique le problème.

Lorsque je veux m'inscrire, je vérifie si le pseudo est déjà existant dans la base.
Si c'est le cas je redirige l'utilisateur vers ma page d'inscription.
Et si ce n'est pas le cas j'inscris l'utilisateur.


D'un point de vue utilisateur ça semble fonctionner, mais en faisant des test j'ai vu des anomalies dans ma base.
Lorsqu'un utilisateur tente de s'inscrire avec un pseudo déjà attribué, il est bien redirigé avec le header sur la page d'inscription MAIS l'insertion des données se font quand même dans la base...sa voudrait dire que le header ne stoppe pas le traitement de la page et je trouve ça vraiment bizarre...alors je pourrais régler le problème avec une simple variable fonctionnant comme un bool mais..j'ai l'impression que ça ne ferait que cacher un problème que je ne vois pas...


EDIT: Je viens tout juste de faire migrer de my_sql à my_sqli, donc si vous voyez des problèmes liés à ce genre de fonction dans le code, j'aimerais bien savoir aussi

En outre il y a un truc que je ne comprends pas, sous my sql, pour vérifier la connexion j'aurais eu un truc de ce style là

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$connexion = mysql_pconnect(SERVEUR,NOM,PASSE);
	if(!$connexion) //si erreur
    {
    	if($_COOKIE['langue']=="French"){
        	echo "Désolé, connexion à ".SERVEUR." temporairement impossible !";
        	echo "Essayez plus tard !";
        }
        if($_COOKIE['langue']=="English"){
        	echo "Sorry, connection to ".SERVEUR." isn't available for the moment !";
        	echo "Try later !";
        }
    }  
    if(!mysql_select_db(BASE,$connexion))	//si erreur connexion à la base	   
	{
		if($_COOKIE['langue']=="French"){
        	 echo "Désolé, accès à la base ".BASE."impossible";
        	 echo "Essayez plus tard !";
        	 exit;
        }
        if($_COOKIE['langue']=="English"){
        	 echo "Sorry, access to the database ".BASE."isn't available for the moment !";
        	 echo "Try later !";
        	 exit;
        }
    }

En fait, je pouvais déterminer si l'erreur provenait du serveur ou de la base en elle même...avec my sqli cette distinction me semble impossible à faire et je trouve ça pas très cool...ou alors j'ai oublié un truc je ne sais pas..

[Celira]

Je te propose d'ajouter un exit juste après le header, histoire d'être sûr qu'il fait rien d'autre après :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
header('Location: inscription.php');
exit(0);

[guibalg]

Bonne réponse de Celira, néanmoins pense à changer ton mysql par un mysqli ou PDO.

[Amnael]

Bonne réponse de Celira, néanmoins pense à changer ton mysql par un mysqli ou PDO.

C'est déjà sous mysqli...


Sinon, je trouve quand même cela bizarre qu'il faille un exit alors que la fonction header est censé stoppé la lecture de ma page...mais bon soit.

[papajoker]

e trouve quand même cela bizarre qu'il faille un exit alors que la fonction header est censé stoppé la lecture de ma page...

non non header ne fait qu'écrire une ligne de texte dans l'entête http, php n’interprète pas cette chaine envoyée donc le code continue. C'est uniquement coté client que ton navigateur l'interprète.

-----------------------------
sinon,
il n'y a dans ton code aucune protection, tu envois directement la variable post dans les tables et le mot de passe est en clair

[Amnael]

Ok d'accord merci !


Du coup, est ce que ça veut dire que on peut faire du pseudo parallélisme grâce aux headers ? J'entends par là exécuter du code serveur et client en même temps plutôt qu'en séquence

il n'y a dans ton code aucune protection, tu envois directement la variable post dans les tables et le mot de passe est en clair

Comment peut-on remédier à un ce problème ? Je pensais que le fait de mettre un champ password était suffisant au niveau du form.

[papajoker]

pour le mot de passe tu as la faq

et sinon il faut tester chaque variable retournée dans ton post : si elle est vide, si elle a des caractères non voulu ...

[Amnael]

Elle ne peut pas être vide car tous les champs de mon form sont en required; d'où le fait que je ne teste pas ce coté là.
Des caractères non voulu, je n'en vois pas vraiment, en tout cas quand j'ai créé ma base, je n'ai mis aucune contrainte check de ce coté là; mais peut-être que je n'ai pas pensé à tout et qu'effectivement je devrais interdire certaines choses...simplement je ne vois pas quoi...


Ok pour le mot de passe je vais aller regarder le lien.

EDIT: Après avoir regardé le lien; en fait l'idée générale c'est de ne pas stocker le mot de passe dans la base, mais de stocké un mot de passe codé ou crypté. Je comprends l'idée générale; mais pour le genre de site que je fais je n'en vois pas l'utilité là. Puis, dans le fond ça revient au même, si ton pirate trouve ta clef pour décoder...

Je te remercie quand même pour la remarque, honnêtement, ça ne m'aurait jamais traversé l'esprit de penser à ne pas stocker un mdp tel quel. Mais tu as raison, si les données étaient "sensibles" il faudrait le faire !

[guibalg]

Required est un attribut de ta balise, donc si la personne le supprime en faisant "Inspectez l'élèment" tout passe.
Pense à toujours échappé tes caractères et surtout tes mots de passes protégent les avec un grain de sel.

[Invité]

@Amnael et @guibalg

Inutile de citer un message pour y répondre !

Merci d'utiliser le bouton "+ Répondre à la discussion" en bas à gauche.

[Invité]

Bonjour,

1/

... tous les champs de mon form sont en required; d'où le fait que je ne teste pas ce coté là...

C'est une GRAVE ERREUR !

Il faut TOUJOURS vérifier les données provenant d'un utilisateur => GESTION d'ERREURS et VALIDITE des données transmises.
Il ne faut pas juste vérifier qu'ils sont remplis. Il faut s'assurer qu'il sont corrects et non vérolés !

• pseudo : unique ? (OK, mais voir point 2/)
• mot de passe : nombre de caractères ? caractères autorisés ? ...
• email : validité ?

Et ce n'est pas la seule dans ton code.

2/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    $requete="select pseudo from Utilisateur "; 
    $resultat=mysqli_query($connexion,$requete);
    while($emp=mysqli_fetch_assoc($resultat))
	{

Pourquoi parcourir toutes les lignes de la table, alors qu'on peut directement vérifier si ce pseudo existe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    $requete="select COUNT(pseudo) as nbre_pseudo from Utilisateur WHERE pseudo = ?"; 
    $resultat=mysqli_query($connexion,$requete); // Là, je te laisse faire la REQUETE PREPAREE NECESSAIRE ! ;)
    $emp=mysqli_fetch_assoc($resultat);
    $nbre_pseudo = $emp['nbre_pseudo'];
	if($nbre_pseudo>0){ // Oups ! ce pseudo existe déjà

[Celira]

Pour les mots de passe, tu peux regarder la fonction password_​hash. Stocker des mots de passe en clair dans la base de données n'est pas du tout une bonne idée.

Pour la protection et l'échappement des données, vu que tu utilises mysqli, tu peux utiliser les requêtes préparées, qui vont faire ça très bien toutes seules, ou au moins mysqli_real_​escape_​string.

Et pour la validation, applique le principe de base "Never trust user input" (ne jamais faire confiance à ce qu'envoie l'utilisateur) Tout ce qui arrive de l'extérieur doit être testé, ou moins géré de façon à ne pas provoquer de failles et/ou de catastrophes.

[Amnael]

Ce que je veux dire c'est que à partir du moment ou mon utilisateur ne m’envoie pas un champ vide (impossible à cause du required).

Alors il peut faire ce qu'il veut des infos derrières, s'il veut choisir *............* comme pseudo moi je m'en fou concrètement =)

Je comprends ce que vous me dîtes, mais, si je considère que toute donnée non vide est valide. Et que une donnée vide ne peut jamais arriver via mon formulaire; alors je n'ai aucune raison de m'en faire non ?

Cela poserait un problème si des données pouvaient arriver d'autre part que depuis mon formulaire, mais j'ai du mal à voir comment ce serait possible...la seule façon pour quelqun de faire ça, ce serait d'avoir accès à mes identifiants ftp et donc à ce moment là il pourrait quoi qu'il arrive tout supprimer ou pire ...


Pour le mot de passe, je suis d'accord, je n'y avais simplement jamais pensé; je regarderais tout ça.



La validité de mail par exemple, c'est pas un problème, si le mec met une fausse id, il s'inscrit, mais ne pourra pas se connecter via mail d'activation donc ça ne servira à rien et lorsque je ferais le ménage à intervalle régulier je verrais bien quels users sont actifs ou inactifs.

Encore une fois, je ne cherche pas à faire un truc parfais sans faille, mais simplement à appliquer un peu tout ce que j'ai appris tout en l'adaptant...car oui en cours on nous apprend encore mysql...je trouve ça stupide de la part des profs d'ailleurs qu'ils ne se mettent pas à jour...enfin bref !

[guibalg]

comme expliqué précèdement, le required est un attribut HTML ce qui signifie que il peut être retiré pour valider le formulaire sans pseudo.

D'où la nécessité de faire un if(isset(condition)) en PHP.

Si tu n'échappe pas les caractères, ton utilisateur pourra injecter du code malveillant et pourra te supprimer le contenu de la base etc...

[Invité]

...Cela poserait un problème si des données pouvaient arriver d'autre part que depuis mon formulaire, mais j'ai du mal à voir comment ce serait possible...

C'est non seulement possible, mais TRÈS simple :
il suffit de créer un formulaire similaire au tien, et de remplir action="..." par l'URL de ta page de traitement.

La validité de mail par exemple, c'est pas un problème, si le mec met une fausse id, il s'inscrit, mais ne pourra pas se connecter via mail d'activation donc ça ne servira à rien...

soit tu es un grand optimiste qui a une confiance aveugle en l'"humanité", soit tu es totalement inconscient des réalités...

[Amnael]

Ah oui ok, je commence à comprendre comment ça peut poser problème.

Donc de façon générale je testerais toujours mes variables maintenant.


Par contre, supputons que pour une raison x ou y; admettons la confiance aveugle en l'humanité par exemple, je ne fasse pas ses modifs.

Faire un formulaire qui va envoyer des données sur ma page est donc simple, ça j'ai compris et je vois bien comment ça peut se passer.


Si je n'ai pas protéger mes variables, ça veut dire que je peux me retrouver avec des cas que je n'ai pas prévu au niveau de mes variables, ça aussi je l'ai compris.


Mais là où j'ai du mal à suivre, c'est que, pour traiter ces données il faut quand même qu'il connaisse le nom des variables à envoyer que je traite; car s'il peut m'envoyer des données pourries, moi coté php je ne traiterais de toute façon que ce que j'ai décidé de traiter (que j'ai vérifié mes variables ou pas).

Comment dire ça autrement...si je reçois un $_POST['FoutLaMerde'] sur ma page php depuis un formulaire ne m'appartenant pas, mais que nulle part je ne traite une telle variable. Comment la variable peut elle causer un quelconque problème ?


En revanche, ça veut dire qu'avec cette méthode c'est assez simple de faire crasher n'importe quel serveur en le spammant de requête de connexion sachant qu'en général les gens utilisent plus ou moins les mêmes noms de variables pour ce genre de choses,, ça doit se faire assez facilement...et même sans les bons id j'imagine que le simple fait de demander la connexion en boucle à l'infini doit être suffisant pour tout faire planter...

[Invité]

Ce n'est pas compliqué d'aller sur la page de ton formulaire, et de regarder les name des input/select,...
Un simple copier-coller de ton formulaire (code HTML généré) suffit.


D'autre part, si TU NE garantis PAS la SÉCURITÉ des données PERSO qu'on te fournit (pseudo, mot de passe, email,...), rappelle-moi de ne jamais m'inscrire sur un de tes sites...

[Amnael]

J'ai pensé à une "méthode" pour sécuriser un peu mieux tout ça, tout en gardant ma logique de ne pas vérifier si une variable obligatoirement non vide via mon formulaire est bien correcte.


Le but ce cette méthode serait, non pas de vérifier la validité d'une variable, mais plutôt de vérifier la validité d'une page.


Autrement dit, voilà comment je proposerais de faire


Chacune de mes pages html et php serait identifié par une variable php de session (donc invisible pour l'utilisateur regardant le code source).


Du coup, je n'ai plus qu'à vérifier lors de mon traitement de formulaire que par exemple la variable de session est bien présente avant de faire quoi que ce soit.

Si elle n'est pas présente c'est que le formulaire n'est pas le mien.

En espérant avoir expliqué à peu près comme il faut à quoi je pensais =)

Si je peux m'assurer de cette façon que seul le code de mes pages soit exécuté alors je n'ai pas besoin de vérifier la validité des variables qui ne pourront pas être falsifié par un faux formulaire !

[papajoker]

la vérification de chaque entrée est une règle en programmation ! elle n'a rien à voir avec le web. Elle est imposée dans toute société qui fait du développement même windows.

tu as des fonctions intégrées dans php.

Mais toi, après une décennie de php, tu vas inventer un nouveau système...
tout le monde n'a pas un navigateur html5 et donc ton "required" et ton histoire de session peut-être détournée (avec curl par exemple)

ps: ton idée de session n'est pas idiote du tout, mais c'est un autre contrôle contre les failles CSRF

[Amnael]

Je ne veux rien réformer du tout...c'était une simple idée comme ça pour prolonger la discussion.

C'est un peu ce que je reproche à l'enseignement en informatique que je reçois à la fac.
C'est bien de nous dire, vous devez faire ça...il faut savoir obéir d'accord mais...l'informatique ça n'en reste pas moins une matière scientifique et je trouve pour ma part plus intéressant que l'on m'explique pourquoi faire une chose plutôt qu'une autre.

Toutes ces histoires de faille de sécurité, en cours on ne nous l'évoquera même pas une seule fois, alors comment nous on est censé savoir quoi faire pour remédier à des choses que l'on ne connaît même pas ? Bien sûr, c'est à nous de faire des recherches à coté, mais pour rechercher quelque chose, ce serait bien au minimum d'avoir des pistes de recherche...ce qui n'est jamais le cas pour moi en tout cas.

J'ai d'ailleurs une tendance des plus fâcheuses à faire les choses à ma façon lorsque je ne comprends pas pourquoi on me demande de faire d'une autre façon. En étant conscient du fait que j'ai tord, mais quelque part, si je ne force pas le passage dans le mur je n'aurais aucune explication sur le "pourquoi c'est mal".

Bref tout un tas d'aspect important mais que pourtant je ne connais pas; grâce à vos messages je peux m'y intéresser et je trouve ça très bien

Mon idée de variable de session ressemble beaucoup à cette histoire de token donc mais c'est insuffisant. Je vais aussi essayer de m'intéresser à Ajax pour comprendre un peu mieux son fonctionnement !