stripslashes, htmlentities et/ou mysql_real_escape_string

Bonjour,

Je me tourne vers vous afin d'avoir une réponse sur les bonnes pratiques. Je récupère d'un formulaire 2 variables que je nettoie :

Code:

---

1 2	$username = stripslashes(htmlentities($_POST["_username"])); $user_pass = stripslashes(htmlentities($_POST["_password"]));

---

Ces deux variables sont ensuite intégré à une requête afin de vérifier l'existence de l'utilisateur :

Code:

---

sprintf("SELECT `id` FROM `users` WHERE `username` = '$username' AND `password` = '$password';", mysql_real_escape_string($username), mysql_real_escape_string($password));

---

J'en arrive à ma question, en sachant que les deux variables ne sont pas réutilisé ensuite, est ce que mes 2 premières lignes ont un réel intérêt ?

Bonjour,

htmlentities ne "nettoie" pas elle transforme certains caracteres en entités HTML.
Cette fonction existe non pas pour insérer des données dans une base mais pour au contraire pour placer les données d'une base dans du code html.

Si tu utilises cette fonction stripslashes(), je suppose que tu travailles avec les magic quotes actifs.
En fait les magic quotes et mysql_real_escape_string() font la meme chose.
Et stripslashes() lui fait l'inverse.
Donc actuellement tu decouds et recouds tes variables.

En resumé :
- pour l'insertion dans la base : si les magic quotes ne sont pas actifs (ce qui serait une bonne chose), utilise mysql_real_escape_string()
- pour l'afficahge html : utilise htmlentities()

Merci pour l'explication sur la fonction htmlentities(). J'ai du mal comprendre.. je pensais que cette fonction jouait sur la sécurité au même titre que htmlspecialchars() en bloquant les balises HTML.

Oui, magic_quotes_gpc est configuré à ON sur le serveur. Peux tu m'indiquer pourquoi il serait bon de désactiver cette directive ? Après une petite recherche, il parait bon de laisser ce paramètre à ON.
J'ai trouvé quelques infos dans le manuel

Les deux premières lignes sont donc inutiles..

Mes questions :

Si magic_quotes_gpc est activé, il est inutile d'utiliser mysql_real_escape_string (le mieux étant de tester si la directive est activée ou pas) ?
Pour se protéger des balises HTML, je dois donc me tourner vers la fonction strip_tags ?

Oui htmlspecialchars() et htmlentities() ont le meme but : permettre d'afficher n'importe quoi sans craindre de perturber le code html.
Mais les données inserées dans la base n'ont pas de raison d'être pré-formatée pour un affichage HTML.
Imagine qu'un jour tu veuilles utiliser ta base d'utilisateurs avec une application tierce : elle ne s'attendra surement pas a ce que les login/pass contiennent des conversions en entités HTML.

Il est préférable de travailler sans les magic_quotes car ils disparaitront avec PHP6 mais sinon ils font le meme travail que mysql_real_escape();

Globalement pour ton soucis de HTML moi je vois les choses comme cela :
- un utilisateur saisi comme login "<b>toto"
- j'inscris dans la base "<b>toto" sans le modifier, c'est son droit de s'appeller comme ca
- Quand j'affiche, cela ne pose pas de probleme car j'utilise htmlspecialchars("<b>toto");

ou alors

- je décide qu'il est interdit d'avoir un symbole comme < dans son login
- je filtre avant l'enregistrement dans la base les logins incorrects.
- j'affiche toujours avec htmlspecialchars(), ca ne mange pas de pain et si je change ma politique plus tard, mon code est déjà prêt.

Au passage pour les mots de passe, il est par contre de bon ton d'utiliser des fonctions MD5.

Un grand merci sabotage pour ces explications.

Donc htmlspecialchars() et htmlentities() s'utilise en sortie. J'avais déjà lu plusieurs discussions qui parlaient de stocker les données brut dans la base.

Pour le reste, j'ai bien compris le raisonnement :king:
A l'authentification, je vérifie uniquement, il est donc inutile d'effacer les éventuelle balise HTML. Cette opération s'effectuera à l'enregistrement ou avant l'affichage.

Pour le cryptage, je me suis tourné vers un hash sha1+GDS

Code:

---

sha1(sha1($user_pass).$username);

---