[Sécurité] Avis sur protection données formulaire avant insertion dans BDD [Résolu]

[raptorman]

Bonjour à tous,

J'aimerai soliciter l'avis de professionels sur le sujet pour me donner un avis sur la façon dont je protége mes données venant d'un formulaire par méthode $_POST avant de les insérer dans une base de donnée MySql (pour une interface d'inscription et de connexion à un espace sécurisé)

Voici donc comment je protège les données avant l'insertion :

Code :

1
2
3
 
$pseudo = trim(mysql_real_escape_string($_POST['pseudo']));
$mdp =  md5(trim(mysql_real_escape_string($_POST['mdp'])));

Est ce que cela assure une protection efficace contre les tentative de piratage ? (injection sql ou autre)


De plus, j'aimerai vous demandez si il était nécessaire que je protège les données que je récupère de la bdd si je les protège avant de les insérer de la manière décrite ci-dessus ?

Merci par avance pour vos réponses

[Petibidon]

hello,

avis perso sur la question :

pour ce qui est du $pseudo : oui mais...
pour ce qui est de la logique, mysql_real_escape_string (mres pour la suite car je suis fainéant) prépare les données pour l'insertion, trim les transforme. pour moi il est plus logique de transformer les données avant de préparer l'insertion.
donc :

Code :

1
2
 
$pseudo = mysql_real_escape_string(trim($_POST['pseudo']));

m'enfin ça c'est du pointillisme...
par contre on dirait que tu accepte un peu n'importe quoi dans les pseudo, peut etre faut il penser à filtrer un peu plus et n'autoriser que les caracteres les plus "logiques"... car là par exemple tu acceptes les tags HTML par exemple... est ce voulu ?

pour ce qui est des mots de passe :
md5 dans tous les cas transforme les données en une chaine hexadécimale inoffensive pour la base de données. donc mres n'est pas obligatoire (mais ça reste une bonne habitude)

pour le trim, si tu vires les espaces à l'insertion, n'oublie surtout pas de les virer aussi à la vérification car là tu as dénaturé le mot de passe ( md5('toto') != md5(' toto ') ) ces espaces étaient peut-etre intentionnels qui sait ?

en résumé, j'ai peut-etre blablaté pour rien, la principale chose à vérifier je pense, c'est les caracteres autorisés dans les pseudos, et pourquoi pas les mots de passe, avec un petit preg_match par exemple.

bon courage !

[berceker united]

J'ajouterais un avis concernant le mot de passe.
Pour éviter de dénaturer un mot de passe ou la réussite (il faut qu'il soit fort) de détourner la fonction mysql_real_escape_string par l'injection SQL. je proposerais plutôt l'expression réguliere et dire que seul les caractères suivant sont accepté a-z,A-Z,1-9, ....
et je rajouterais ceci.

Code :

1
2
$pseudo = mysql_real_escape_string(trim($_POST['pseudo']));
$Operation=($pseudo===trim($_POST['pseudo']))?true:false;

En gros la chaine à été transformé c'est qu'il y a un eu correction et c'est pas forcément bon concernant le mot de passe. Alors je sais que ceci ne doit pas s'appliquer dans n'importe quel cas mais c'est juste un début d'idée.

[raptorman]

Tout d'abord, merci pour vos réponses

Petitbidon >>>

Code :

Oui, tu a raison, cela semble plus logique, mais en ce qui concerne la sécurité, c'est bon ?

par contre on dirait que tu accepte un peu n'importe quoi dans les pseudo, peut etre faut il penser à filtrer un peu plus et n'autoriser que les caracteres les plus "logiques"... car là par exemple tu acceptes les tags HTML par exemple... est ce voulu ?

Oui, en effet, j'avais oublié de le préciser, j'utilise cette fonction pour autoriser seulement les caractères alphanumériques et les signes - et _ dans le pseudo :

Code :

1
2
3
4
5
function pseudoCorrect($pseudo){
	$pseudo_valide = ereg('^[[:alnum:]_-]{4,32}$',$pseudo);
	if ($pseudo_valide) return 1;
	else return 0;
}

Par contre, je ne sais pas comment faire pour autoriser en plus les espaces et les lettres avec accent ?
Si quelqu'un aurait une idée

Code :

1
2
 
pour le trim, si tu vires les espaces à l'insertion, n'oublie surtout pas de les virer aussi à la vérification car là tu as dénaturé le mot de passe ( md5('toto') != md5(' toto ') ) ces espaces étaient peut-etre intentionnels qui sait ?

Oui, c'est vrai, je crois que je vais enlever trim(), cela complique le boulot pour pas grand chose


berceker united >>>

En effet, cela peut être une idée à développé, mais comme je le disais plus haut, j'ai abandonné l'idée d'utilisé trim() sur le mot de passe.


Sinon, je vous avez encore demandé une petite chose dans le premier post, peut être ne l'avez vous pas vu

Est il nécessaire que je protège les données que je récupère de la bdd si je les protège avant de les insérer de la manière décrite ci-dessus ?

Merci beaucoup !

[Petibidon]

re,

pour la premiere question, mres est fait pour ca, donc pour la sécurité contre les injections sql, c'est nickel normalement

pour ce qui est de ta derniere question, si j'ai bien compris, si tu fais un truc du genre

SELECT machin FROM truc WHERE bidule=$chose

il faut bien évidemment protéger $chose. pour résumer il faut protéger toutes les variables que tu envoie à ta base de données que ce soit en écriture lors des INSERT/UPDATE, qu'en lecture, dans les clauses WHERE.

sinon a priori tu n'as pas a te soucier plus, les données issues de la BDD sont sensées être propres quand tu les insere, donc il en va de meme lorsque tu les relis.

sinon pour les espaces dans ton expression, essaye [:space:] mais je garantis rien.

enfin pour finir, vu que tu protege intelligemment tes données, tu pourrais aussi autoriser les apostrophes pour les pseudos (penser qu'il y a plein de noms qui en contiennent). enfin ça apres... moi ce que j'en dis hein !

[raptorman]

Re

pour la premiere question, mres est fait pour ca, donc pour la sécurité contre les injections sql, c'est nickel normalement

Oki, c'est parfait alors, merci beaucoup

pour ce qui est de ta derniere question, si j'ai bien compris, si tu fais un truc du genre

SELECT machin FROM truc WHERE bidule=$chose

il faut bien évidemment protéger $chose. pour résumer il faut protéger toutes les variables que tu envoie à ta base de données que ce soit en écriture lors des INSERT/UPDATE, qu'en lecture, dans les clauses WHERE.

sinon a priori tu n'as pas a te soucier plus, les données issues de la BDD sont sensées être propres quand tu les insere, donc il en va de meme lorsque tu les relis.

Oui, c'est bien cela, donc ce problème est également réglé

sinon pour les espaces dans ton expression, essaye [:space:] mais je garantis rien.

Effectivement, c'était bien [:space:], une chose de plus de résolue

enfin pour finir, vu que tu protege intelligemment tes données, tu pourrais aussi autoriser les apostrophes pour les pseudos

Oui, en effet, cela peut être interessant
Par contre, ne m'y connaissant pas du tout dans les expressions régulières, je ne vois pas du tout coment m'y prendre


Sinon, une dernière question me passait par la tête :

Lorsque qu'un membre se connecte, une session est alors créee si le couple pseudo/mot de passe correspond dans la bdd.

Dois-je protéger également les variables qui passent par la session ?

Par exemple :

Code :

$_SESSION['pseudo'] = htmlspecialchars(trim($_POST['pseudo']));

[Petibidon]

non, puisque le pseudo pour etre validé doit être "clean", pas de raisons de le transformer pour le passer en session.

pour ce qui est des apostrophes, essaye simplement de rajouter ' dans ton motif je peux pas en dire plus, j'utilise jamais les expressions posix.

[raptorman]

Ok, et bien je te remercie beaucoup pour toutes les indications que tu m'a apportées

Par contre, pour les apostrophes, j'ai tenté de rajouté un ' dans le motif, mais cela n'a pas fonctionné

Je vais donc faire quelques recherches supplémentaires

Merci encore, sujet clos.

[EvilAngel]

Salut à tous,

J'ai lu avec intérêt toutes les infos dans ce post et la FAQ PHP.

Toutefois, une question me taraude toujours.
Comment éviter que les utilisateurs entrent des tags HTML dans les champs texte du formulaire ?

Les fonctions htmlentities ou htmlspecialchars servent uniquement lors de l'affichage de champs texte je crois.

Merci

[zyongh]

Pour éviter les injections SQL du type OR 1='1', tu peux faire comme ceci:

Code :

1
2
3
 
$request = ...; // La requête SQL
if(eregi((OR 1='1'){1}, $request)) exit("Pas d'injection SQL SVP";

Pour éviter les failles XSS, j'utilise

Code :

1
2
 
html_special_chars($variable_post);

[berceker united]

Envoyé par zyongh

Pour éviter les injections SQL du type OR 1='1', tu peux faire comme ceci:

Code :

Pour éviter les failles XSS, j'utilise

Code :

Et si c'est OR 2=2 et pourquoi pas 3=3 le problème ne sera pas reglé.

[David.Schris]

Envoyé par raptorman

Code :

$mdp =  md5(trim(mysql_real_escape_string($_POST['mdp'])));

Bonsoir,

Une remarque en passant : MD5 seul, c'est un peu faible. Pour vous en convaincre, téléchargez/installez un outil comme John the Ripper (avec le patch "Raw MD5" [1]) et faites un "benchmark" :

Code :

john --test

.
Le (raw) MD5 devrait apparaître comme le plus rapide à casser ("cracker")... Comparez avec "blowfish"...

Faites un tour sur la page "Portable PHP password hashing framework", cela peut aider.

Cordialement,
DS.

[1] - il vous faudra le compiler vous-même, le "Raw MD5" n'est pas inclus par défaut (et il ne faut pas le confondre avec le "FreeBSD MD5").

[EvilAngel]

Pour lutter contr les failles XSS, il suffit de faire préparer les affichages avec la fonction htmlentities non ?
Par exemple:

Code :

1
2
3
4
<?php
echo htmlentities($nom);
...
?>