PROTECTION CONTRE LE XSS ET L'SQL INJECTION

Signaler
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
Buildos
Messages postés
1
Date d'inscription
mercredi 6 avril 2011
Statut
Membre
Dernière intervention
30 juin 2011
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/41312-protection-contre-le-xss-et-l-sql-injection

Buildos
Messages postés
1
Date d'inscription
mercredi 6 avril 2011
Statut
Membre
Dernière intervention
30 juin 2011

Je suis un des plus débutants dans le PHP , je voudrais savoir ou mettre ce code? est ce que en bas de toutes les pages que j'utilise ou ?
djshaker
Messages postés
4
Date d'inscription
jeudi 13 novembre 2003
Statut
Membre
Dernière intervention
3 juin 2010

Bonjour,

Concernant les injections SQL je vous recommande d'utiliser la classe PHP PDO,
qui avec les méthode prépare / bind_param / execute permet de se prémunir contre tous types d'injections SQL.

Bon dev ;)
kankrelune
Messages postés
1293
Date d'inscription
mardi 9 novembre 2004
Statut
Membre
Dernière intervention
21 mai 2015

@ GFPL => $maVar = strip_tags(urldecode($maVar));

@ Pulp... le htmlspecialchars(), htmlentities() ou strip_chars() est inutile pour une requête SQL en effet les base de données ne sont pas sensible au html, javascript, php, etc... au final tu ne fais que surcharger ta base de données en caractères supplémentaires... .. .

Concernant l'injection SQL... tout d'abord le but dépend du pirate et donc de ce qu'il veut faire... .. .

Pour ce qui est du traitement des données magic_quotes n'échappe que des caractères généraliste ça n'est ni suffisant ni portable selon la SGDB utilisée ce qui ne fait que donner une illusion de sécurité... c'est d'ailleurs pour ça qu'elle n'existera plus à partir de PhP6... cependant certain caractères non échappés par magic_quotes doivent l'être avec certaines SGDB... il faut donc au préalable virer l'échappement de magic_quotes pour ne pas échapper les caractères d'échappement (lol) ce qui reviendrait à ne rien échapper du tout... d'où le stripslashes()... .. .

Un autre avantage de cette façon de procéder est que mysql_real_escape_string() n'est pas une fonction généraliste comme addslashes() ou magic_quotes... étant spécialisé dans le traitement de données destinées à MySQL si cette dernière évolue tu est sur que tes données seront toujours traitées comme il se doit... .. . ;o)

@ tchaOo°
cs_PuLP
Messages postés
16
Date d'inscription
dimanche 9 mars 2003
Statut
Membre
Dernière intervention
26 mai 2007

Moi non plus je ne comprend pas trop cette histoire de htmlspecialchars uniquement pour un cas, que ce soit une insertion de donnée ou une extraction, dans les deux cas il y a un requete mysql, et c'est la requete qu'on sécurise.

D'ailleurs mysql_escape_real_string, ça protege de l'injection avec quotes avec des slash, la methode d'injection est la meme que ce soit INSERT ou SELECT ca change rien vu que le but c'est de faire un UNION, non?

autre chose KANKRE je comprend pas trop ton code avec get_magic_quotes_gpc(), tu verifie si il y a des slash, pour les enlever, et finaler les remettres, enfin les remettres uniquement aux char concerner par la fonction mysql_escape_real_string ok, mais ça sert à quoi ? si ya magic quotes tu fais rien tout simplement..
Ou alors c'est que magic quotes a une faille que mysql_escape_real_string n'a pas ?