Ok, un énorme merci ! :D

[quote="moogli"]... J'avoue qu'a la relecteur c'est pas très clair, je pensais cela sur la ligné de mon 1er message ^^
@+[/quote]

Ton premier message était très bien, mais s'adressant à un débutant, la dernière ligne était à mon avis en trop et prête à confusion.

Il faut distinguer la sécurisation d'une requête, de l'utilisation ultérieure des données.

A la première question, on répond classiquement par l'utilisation de mysql_real_escape_string avec les extensions mysql ou mysqli, et l'utilisation préférentielle des requêtes préparées avec l'extension PDO.

A la deuxième question on répond classiquement qu'il faut protéger l'affichage avec htmlspecialchars ou autre fonction "similaire".

Mais filtrer ou convertir par avance des caractères à l'entrée en bdd, simplement pour éviter d'avoir ensuite à protéger l'affichage est une fausse bonne idée. Dans la même lignée on voit parfois des scripts qui enregistrent les données en bdd avec htmlspecialchars ou htmlentities, ce qui encombre inutilement les tables avec des entités inutiles, les rends incompatibles pour un export propre sans traitement php préalable, et en plus peut poser de gros problèmes pour la recherche ex : [url=http://forum.phpfrance.com/php-debutant/moteur-recherche-accents-t257105.html]ce topic[/url].


@[b]arthur77[/b] : il y a un tuto [url=http://forum.phpfrance.com/faq-tutoriels/inscription-connexion-dans-espace-membres-t242539.html]avec code complet ici[/url] sur l'inscription et la connexion dans un espace membre. L'enregistrement en bdd se fait avec mysql et donc l'utilisation de mysql_real_escape_string pour protéger la requête.
Si tu utiles PDO c'est le même principe excepté que tu n'utilises plus mysql_real_escape_string mais les fonctions spécifiques à PDO, ou mieux, PDO avec des requêtes préparées qui sont réputées fournir un maximum de sécurité (même si techniquement elles ne se justifient pas pour des raisons de performances dans ton script puisqu'elles ne sont pas répétées).

[url]http://www.php.net/manual/fr/pdo.constants.php[/url] => PDO::PARAM_*

entier, chaine etc

@+

juste une dernière question, "letype", c'est des types comment ? est-ce que tu sais où je peux trouver une liste ? j'ai regardé la doc sur pdo-quote() mais ils n'indiquent pas ...

Ok d'accord je fais ça, merci beaucoup :D

$pdo->quote($lavariable,letype) <= me type est important

les <> tu les "autorises" ou pas dans tous ce que tu veux même login / mdp si tu veux, le tout c'est de bien mettre un htmlentities ou htmlspecialchars avant l'affichage :)

@+

Donc si je résume (dîtes moi si je me trompe) : quand je fais une requette SQL je dois entourer mes chaines avec un [b]$pdo->quote()[/b] , je peux autoriser les > et < (sauf dans pseudo/mdp ou je bloque avec une [b]Regex[/b]) a condition de mettre [b]htmlspecialchars ou htmlentities [/b]a l'[b]affichage[/b], pour éviter de déclancher notemment des scripts JS, c'est bien ça ?

ben, sur des choses comme un login ou mot de passe tu peux te le permettre (d'ailleurs beaucoup le font en ne demandant que des chaine alphanumérique) je n'ai pas dit qu'il fallait le faire obligatoirement.
Dans cette je pense surtout à une expression régulière de validation ou non de la chose et pas forcément une suppression pure et dure. J'avoue qu'a la relecteur c'est pas très clair, je pensais cela sur la ligné de mon 1er message ^^

@+

[quote="moogli"]je que j'ai pu indiqué était pour les couples logins / mots de passes où tu peux être intransigeant en indiquant que les >< ne sont pas admis. [/quote]

Nan je suis pas trop d'accord - en fait pas d'accord du tout - pour supprimer les '<' ou les '>' à l'enregistrement en bdd.

Si ça peut poser des pb à l'affichage, et bien il faut traiter le problème à l'affichage.

Il faut bien distinguer les problèmes et ne pas tout mélanger. Sinon en extrapolant un peu cela peut donner aussi l'idée d'utiliser htmlspecialchars ou htmlentities directement à l'enregistrement en bdd ce qui peut poser de gros problèmes par la suite.

Donc le principe est de (sauf exceptions rarissime) pouvoir tout enregistrer en bdd.

je que j'ai pu indiqué était pour les couples logins / mots de passes où tu peux être intransigeant en indiquant que les >< ne sont pas admis.

Par contre dans un texte c'est un peux sévère (peut plus écrire que 5<10 c'est dommage ;) ). C'est la qu'entre en piste htmlspecialchars et ses copines.

il ne faut pas confondre l'insertion en base et l'utilisation a l'affichage qui sont deux choses totalement différentes.

dans un champs mysql se fou des < et > par conte, comme en php, une chiane de caractère doit être délimiter pour que mysql sache où elle commence et où elle se termine (comme en xml / html / xhtml ou cequtuveuxML, un attribut constitué de plusieurs mots séparé d'espace non encadré de " ne sera pas complet).

c'est pour cela que tu fait
insert into matable values('mon champ texte perso a moi','mais comme je suis fort en fait, y en a deux')
et pas
insert into matable values(mon champ texte perso a moi,mais comme je suis fort en fait, y en a deux ) <= la comment MySQL peux savoir qui va où ?

a partir de la il est très simple de se dire que dans un champs de formulaire de login je vais mettre [b]' or 1=1;--[/b]. avec une requête "classique" cela donne select truc, machin from users where login='' or 1&1; --' le reste de la requete
le -- indiquant le début d'un commentaire et la ben ça récupère toute la table puisse que la condition est toujours réalisée (oui oui 1=1).
si tu "protège" tes ' avec \' plus de soucis :)
un article wikipedia sur [url=http://fr.wikipedia.org/wiki/Injection_SQL]les injections SQL[/url] qui explique la chose.

Après les <> ça t'emmerde qu'en html (si tu fait du PDF ou autre c'est pas forcément une gène). donc pour cela [b]à l'affichage[/b] tu utilise htmentities ou htmlspecialchars pour remplacer tous ça par leurs entités html (&glt; par exemple pour le code ascii correspondant). Et la pas de soucis de failles (xss ?) dû au p'tit malin qui insère du JS dans les commentaires par exemple.

[quote="Mazarini"]Pour mysql, la fonction mysql_real_escape_string() (inutile avec PDO ?).[/quote]
inutilisable avec PDO, mysql_real_escape_string est "liée" à une connexion mysql
[quote="Doc de mysql_real_escape_string"]
[url]http://php.net/manual/fr/function.mysql-real-escape-string.php[/url]
Note:

Une connexion MySQL est nécessaire avant d'utiliser la fonction mysql_real_escape_string(), sinon, une erreur de niveau E_WARNING sera générée, et FALSE sera retourné. Si link_identifier n'est pas défini, la dernière connexion MySQL est utilisée. [/quote]

avec PDO il faut utiliser [url=http://www.php.net/manual/fr/pdo.quote.php]la méthode quote[/url] ou une requête préparée et un [url=http://www.php.net/manual/fr/pdostatement.bindvalue.php]binvalue[/url], [url=http://www.php.net/manual/fr/pdostatement.bindparam.php]binparam[/url] ou [url=http://www.php.net/manual/fr/pdostatement.bindcolumn.php]bindcolumn[/url].

[quote="arthur77"]J'ai fait plusieurs tests, et PDO sécurise tout seul les ' et les "[/quote]

attention tous seul c'est vite dit (voir au dessus) ;)

@+

J'ai fait plusieurs tests, et PDO sécurise tout seul les ' et les " , j'ai inséré dans la BDD, j'ai resorti, des chaines avec ces guillemets simples et doubles et aucun problème.
Je crois que je vais utiliser des regex pour détecter les > et les < comme a dit Moogli.

Merci pour vos réponses :D si vous avez d'autres idées, n'hesitez pas merci :)

Pour mysql, la fonction mysql_real_escape_string() (inutile avec PDO ?).

Pour les " dans les "value", str_replace('"','\\"',$variable)

pour les < et > dans l'affichage ou les textarea, str_replace() avec & lt; et & gt; (en supprimant le blanc)

Mazarini, qu'elles sont donc les solutions que tu me propose pour parrer à ces problèmes ? Merci beaucoup pour votre aide :)

Les problèmes que l'on rencontre généralement sont :

La saisie d'un champs avec une quote.
=> Il suffit de faire le test pour voir si la requête SQL qui traite ce champ fonctionne auquel cas tout va bien. Dans le cas contraire, outre le problème de plantage de la requête SQL, des personnes pourraient en profiter avec une saisie astucieuse.

L'affichage de champ de saisie avec des doubles quote : <input ... value="toto"titi" ...>
=> outre le problème d'affichage (toto au lieux de toto"titi ), il est possible de déclencher un javascript malicieux

L'affichage de texte avec du code html, genre echo $users qui afficherai <ul>nom</ul>
=> outre un affichage modifié, on pourrait ajouter un javascript malicieux.

salut moogli !
Merci pour ta réponse,
$pdo->quote() sécurise les guillemets dans mes requette ?

oui je crois que les Regex sont une bonne idée, donc je dois empécher de mettre les > et < et sinon il y a d'autres caractères à interdire ?