Discussion :

[Thrystan]

Une petite question technique : je rentre dans une base de données Mysql des infos tapées par le visiteur. Pour ensuite afficher ces données, j'utilise la fonction htmlentities(). Mais qu'est-ce qui est le plus judicieux : utiliser cette fonction AVANT d'insérer les données dans la table, ou APRES au moment d'afficher ? Parce que si je le fais deux fois, évidemment, le résultat est décevant...

Je ne vois pas de différence significative, mais j'imagine que d'autres se sont intéressé(e)s à la questions ; je ne pense pas avoir fait le tour du problème, il y a sûrement des points techniques qui m'échappent.. ou pas ?

Thrystan.

[koopajah]

Je dirai qu'il faut utiliser lors de l'insertion mysql_real_escape_string() qui va éviter les injections SQL (et en général les problèmes de quotes).
Lors de l'affichage par contre tu utilises htmlentities() pour ne pas avoir de problèmes avec les caractères spéciaux html

[Thrystan]

Ok merci.
Il me vient une autre question du coup : je vais utiliser mysql_real_escape_string() pour protéger ma base de données, mais si j'utilise déjà :

Code :

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

$values = strip_tags(substr($_POST['values'],x,y));

Je contrôle donc déjà ce que tapent les visiteurs. Est-il alors nécessaire (complémentaire ?) d'utiliser mysql_real_escape_string() ? Est-ce que ça remplace strip_tags() ?

Thrystan.

[koopajah]

C'est complémentaire, strip_tags() va te retirer les balises html tandis que mysql va éviter les injections SQL. Pour ca il va "échapper" toutes les quotes lors de l'insertion dans la base de données
http://securite.developpez.com/faq/?..._sql_injection

[Thrystan]

Je dois donc utiliser ça ?

Code :

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

$values = mysql_real_escape_string(strip_tags(substr($_POST['values'],x,y)));

Deuxièmement, avec ce que je viens de lire sur le lien :

Le code ne contient jamais de données sensibles
Les mots de passe, clef de chiffrement, chaîne de connexion, identifiant de compte, etc… ne doivent pas être codés en dur.

Comment je fais pour me connecter à ma base Mysql sans taper clairement dans le code php mon mot de passe ?

Thrystan.

[koopajah]

Deuxièmement, avec ce que je viens de lire sur le lien :Comment je fais pour me connecter à ma base Mysql sans taper clairement dans le code php mon mot de passe ?

D'après ce que j'ai pu lire sur le forum depuis que j'y suis, tu as un risque de sécurité si tu mets tes logins/mdp en dur dans tes scripts. En effet, le php est interprété par php lancé lui meme par Apache et tu pourrais te retrouver dans un cas ou ton script n'est pas interprété correctement et que le script php est envoyé comme du html au client (il aurait donc ton code).
La solution qui était proposée c'était de mettre tes login/mdp dans un fichier externe, lui meme non présent dans le répertoire www d'Apache.
Maintenant je n'en sais pas beaucoup plus désolé

[Thrystan]

La solution qui était proposée c'était de mettre tes login/mdp dans un fichier externe, lui meme non présent dans le répertoire www d'Apache.

Oui, mais je le mets où du coup ? Parce que si on peut accéder au fichier, le problème est le même, voire pire... D'autant que je crée un site perso sur Free, et je ne sais pas où je pourrais "cacher" un fichier.

Sinon pour la ligne de code, t'en penses quoi ?

Thrystan.

[koopajah]

ta ligne me semble correcte effectivement.

Pour l'endroit où le mettre je te dis ce que j'ai retenu de mes lectures mais je ne me rappelle pas exactement les solutions proposées, il faudrait que tu recherches un peu dans le forum il doit y avoir des posts qui en parlent.

[Thrystan]

Ok, merci pour tout.

Thrystan.

[julp]

Oui, mais je le mets où du coup ? Parce que si on peut accéder au fichier, le problème est le même, voire pire... D'autant que je crée un site perso sur Free, et je ne sais pas où je pourrais "cacher" un fichier.

Là est tout le problème avec les hébergeurs mutualisés : ils ne vous permettent généralement pas de placer des fichiers en dehors de la partie visible par Apache (au pire ça se gère avec un htaccess). C'est à eux de gérer les problèmes de sécurité au niveau du serveur, notamment en ce qui concerne les manipulations de fichier chez autrui mais PHP est prévu pour donner la possibilité de ne pas le permettre (directive open_basedir - voir le safe_mode mais il sera abandonné lors du passage à PHP 6 et n'est pas réellement une solution).

Je voudrais revenir sur la sécurité, dont les bases sont abordées dans le tutoriel : Developpement web : Généralités sur la sécurité. Après lecture, vous aurez une idée beaucoup plus précise sur ce qu'il faut éviter et les solutions.