Sécurisation de variables

Bonjours à tous et à toutes.

Je reviens de php.net et je suis un peu paumé par rapport à toutes les commandes de sécurisation de variable, entre htmlspecialschars, htmlentites, mysql_......
Donc voila, je vais définir quelques situations, et je voudrais juste savoir si j'ai choisie les bonnes fonctions pour ça =)
Pour chaque situations, la première ligne serra pour l'enregistrement (E: -> mysql_query(....), la seconde serra pour l'affichage (A: -> echo ...).
Ps: oublions que les magics quotes existent pour ce cas :)

1) Une variable de pseudo (alphanum + "-" + "_")

Code:

---

1 2 3 4

E: regex "preg_match('#^[0-9A-Za-z-_]*$#',$var)" //et si ça passe-> mysql_real_escape_string($var) A: htmlentities($donnees['var'], ENT_QUOTES) //($donnees ou $_POST)

---

2) Un variable de mot de passe

Code:

---

1 2	E: md5($var) [ça suffis ?] A : if($donnees['var'] == md5($_POST['pass']))

---

//Je préfère ne sélectionner que le nom d'utilisateur dans la table et vérifier le pass par la suite.

3) Une chaine de caractère sans html interprété (style chat)

Code:

---

1 2	E: mysql_real_escape_string($var) A: htmlentities($var, ENT_QUOTES)

---

4) Une chaine de caractères html (partiel) autorisé (style forum)

Code:

---

1 2 3

E: mysql_real_escape_string(stiptags(bbcode($var))) A: bbcode_decode(stripslashes($var)); //bbcode() & bbcode_decode() -> fonction perso qui remplace les balises autorisées en bbcode

---

5) une chaine de caractère html (complet) autorisé (style backend news (editeur WYSIWYG))

Code:

---

1 2	E: mysql_real_escape_string(htmlentities($var)) A: html_entity_decode(stripslashes($var)) [ou htmlspecialchars là ?]

---

Si vous voyez d'autre situations, ou que vous avez d'autre conseil, je suis preneur :D

Merci d'avance


Edit: ah ouais, et aussi: pour faire un cookie "sur" il faut faire un id compliqué.
un truc du genre:

Code:

---

sha1(md5($user['ip_denregistrement']).$user['password'].md5($user['date_denregistrement']))

---

Vous parrait il correct ?

Salut,

avant tout, la sécurisation de variables est nécessaire afin de prévenir des attaques XSS.
Elle consiste en filtrage de variables en provenance de l'internaute.

Tes scripts cas par cas :

1. OK. Mais attention à l'utilisation de htmlentities à l'affichage.
Si les données retournées par htmlentities() sont utilisées pour un formulaire,
A l'affichage on verra bien des caractères spéciaux ( é,à,etc...) mais lors de la soumission du formulaire
on aura é ou à . Faudra penser à les reconvertir.

2. OK.

Une solution encore plus poussée que j'ai vu sur Joomla consiste à générer une clé unique par utilisateur,
avec uniqid() par example, et faire un md5 avec -> md5( $user_passe . $user_uniqid ).
La clé, bien sûr, doit être sauvegardé dans la BDD sinon - impossible de vérifier le mot de passe.

3. OK
4. OK
5. Inutile de convertir un texte formaté HTML avant de sauvegarder. mysql_real_escape_string() suffit largement.
Par contre il serait bien de tester la presence de cetraines balises html ( <script>,<flash>, <frame> ou autre ).
Si ces balises sont autorisés faudra jeter un coup d'oeuil sur leurs contenu avant de publier cet enregistrement sinon les effacer.

6. Generation de cookie - OK.

Just un conseil d'optimisation.
J'imagine que tu veux logger automatiquement un utilisateur avec un cookie "sur".
Génère la valeur de ce cookie lors de la création d'un compte utilisateur et
enregistre cette valeur dans la table des utilisateus avec un Index sur ce champ dans la BDD ( memo : la recherche est plus rapide avec Index ) .
comme ça tu n'aura qu'à vérifier si la valeur du cookie existe dans la table des utilisateurs.
ça t'evitera de calculer la valeur de cookie pour tout tes utilisateus à chaque fois que une page du site se charge.
La reponse du serveur sera plus rapide et MYSQL moins chargé.

J'espère que ma réponse te sera utile,
Konstantin

Merci beaucoup, c'est exactement la réponse que j'attendais :)
Je cours finir de sécuriser mes scripts :D

juste pour info, dans php6 les librairies mysql* ne seront plus active par défaut donc à forciori mysql_real_escape_string().

il faut songer à migrer en PDO pour etre tranquille.
sachant que en requete préparée la doc affirme qu'il ne peut y avoir d'injection sql après pour les injection xss je sais pas

Citation:

---

la doc affirme qu'il ne peut y avoir d'injection sql après pour les injection xss

---

les injections xss n'ont rien a voir avec les bases de donnée.
par contre effectivement PDO avec les requetes préparées sont l'avenir en PHP et offrent un niveau de protection superieur (a condition évidemment de les utiliser convenablement)