PROTECTION CONTRE LE XSS ET L'SQL INJECTION
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
29 janv. 2007 à 22:37
Buildos Messages postés 1 Date d'inscription mercredi 6 avril 2011 Statut Membre Dernière intervention 30 juin 2011 - 30 juin 2011 à 15:27
Buildos Messages postés 1 Date d'inscription mercredi 6 avril 2011 Statut Membre Dernière intervention 30 juin 2011 - 30 juin 2011 à 15:27
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
https://codes-sources.commentcamarche.net/source/41312-protection-contre-le-xss-et-l-sql-injection
30 juin 2011 à 15:27
3 juin 2010 à 12:27
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 ;)
26 mai 2007 à 11:02
@ 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°
26 mai 2007 à 00:37
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 ?
19 mai 2007 à 18:22
index.php?>'><ScRiPt%20%0a%0d>alert(1687822802)%3B</ScRiPt>
une soluce je m arrache les cheveux
8 mai 2007 à 12:58
Pour ton code...
/* avant une requete */
if(get_magic_quotes_gpc())
$data = stripslashes($data);
$data = mysql_escape_real_string($data);
// on effectue la requete... .. .
----------------------------------
/* après une requete */
// on effectue et on traite la requete... .. .
while(false !($data mysql_fetch_assoc($result)))
{
echo htmlentities($data['myField']).'
';
}
Voili voilou... .. .
@ tchaOo°
8 mai 2007 à 12:41
Je ne comprend pas quand certain disent qu'il faut effectuer les vérifications en sortie de bd, on ne bloque pas les injections dans ce cas il me semble...
$data = addslashes($data);
$trans = get_html_translation_table(HTML_ENTITIES);
$data = strtr(trim($data), $trans);
$data = mysql_escape_real_string($data);
Je vous demande: j'en met trop ? pas assez ? c'est infaillible ?
Je vous propose de modifier la vérification pour qu'elle couvre un maximum de type d'injection.
Cordialement,
Kevin
8 févr. 2007 à 21:33
8 févr. 2007 à 13:13
@ tchaOo°
7 févr. 2007 à 20:39
Le transtypage annule tout effet de surprise au niveau des entiers ^^ (ou flottant, c'est pareil :))
7 févr. 2007 à 19:23
7 févr. 2007 à 18:49
une légende raconte qu'il reste quelques failles... mais je ne sais pas ou coté échapements...
une chose est sure : sans parler de quotes, on peut parfois passer un truc genre UNION SELECT log, pass FROM admin dans un champ numérique...
7 févr. 2007 à 18:37
6 févr. 2007 à 16:37
++
1 févr. 2007 à 12:37
@ tchaOo°
31 janv. 2007 à 17:23
J'ai une question concernant les dates faut-il aussi ajouter mysql_escape_real_string ? ou bien autres choses ?
Merci à vous tous
31 janv. 2007 à 15:25
un peu de lecture...
http://www.phpsecure.info/v2/zone/pArticle
(tout n'est pas à jour)
@ tchaOo°
31 janv. 2007 à 15:10
Merci beaucoup et bonne journée
31 janv. 2007 à 15:09
31 janv. 2007 à 15:06
@ psykocrash... FhX à mal formuler son commentaire je pense... ou plutot il l'a formulé de façon subtile le (int) voulant dire faire un cast... .. . ;o)
@ tchaOo°
31 janv. 2007 à 14:43
Je voulais dire par cela "une recherche sur un tuto qui donnent des exemples sur sécurisé ces données..." et le partager à tout le monde vu que cela intéresse du monde..
Merci
31 janv. 2007 à 14:39
Mais l'objectif c'est justement que ça passe !
IOMEGA: "le" ? De quoi tu parles ?
31 janv. 2007 à 14:23
Merci A+
31 janv. 2007 à 14:04
$maVar = '1 or 1<2;#';
var_dump((int)$maVar);
Ton pirate il pourra passer ce qu'il veut en argument, il pourra croire au père noel ou avoir vu la vierge à poil les mains dans les poches ça n'y changera rien... .. . ;o)
@ tchaOo°
31 janv. 2007 à 13:59
Non, soit c'est du type string... donc entre quote, soit c'est du type (int) et dans ce cas la le résultat de "1 or 1<2;#" ==> 1
Aucune chance que ca passe.
31 janv. 2007 à 13:53
"tu utilise un int et dans ce cas un cast fera l'affaire et le pirate pourra passer ce qu'il veut en arguments ça changera rien..."
Je ne sais pas ce que tu entends par "un cast", donc je donne quelques infos :
-> On peut ajouter à la protection générique un is_numeric() comme je l'ai dit plus haut.
-> Si on ne le fait pas, un pirate peut très bien faire ça :
1 or 1<2;#
Ce qui aura pour effet de valider la requête. Cette faille permet de faire énormément de choses dans utiliser d'apostrophe.
31 janv. 2007 à 13:31
@ Psykocrash...
"Pour l'SQL Injection, les injections sans apostrophes (avec des calculs arithmétiques) peuvent passer aussi."
faux... si tu n'utilise pas les quotes dans ta requete c'est soit qu'elle est mal construite (et donc ça plantera) soit que tu utilise un int et dans ce cas un cast fera l'affaire et le pirate pourra passer ce qu'il veut en arguments ça changera rien... et si tu utilise les quote (pour une string donc) mysql_real_escape() string se chargera d'échapper les quotes et le pirate pourra passer ce qu'il veut (avec ou sans quote) ça sera considéré comme texte... example...
si je passe jean peaul';DROP TABLE pwet# dans WHERE nom=\''.$nom.'\'' pour faire une injection avec mysql_real_escape_string ça donnera
WHERE nom='jean peaul\';DROP TABLE pwet#'
aucune chance que ça passe...
en fait la plus grosse erreur que font les codeur et qui peut créer des failles c'est de ne pas prendre en compte magic_quotes
@ tchaOo°
31 janv. 2007 à 08:19
Merci à vous tous
31 janv. 2007 à 01:47
En sortie, pas en entrée ! Normalement un htmlspecialchars() fait largement l'affaire.
30 janv. 2007 à 21:01
Pour le reste, mysql_real_escape_string() fonctionne très bien, à condition de bien s'en servir ( genre sur des entiers ou des objets... moyen moyen ^^) !
30 janv. 2007 à 20:44
C'est une protection "de base" à compléter. Pour le XSS, du code javascript sans apostrophes ni balises peut être passé et exécuté. Pour l'SQL Injection, les injections sans apostrophes (avec des calculs arithmétiques) peuvent passer aussi. Il faut compléter cette protection avec à coup de vérifications comme is_numeric pour l'sql injection par exemple...
Je le répète : Une protection générique n'est JAMAIS suffisante !
30 janv. 2007 à 17:03
sinon, deux array_walk, ça aurait été plus rapide...
30 janv. 2007 à 15:43
Merci
30 janv. 2007 à 14:45
si tu utilise un int tu fais...
'SELECT ... .. . WHERE id='.(int)$id
si tu utilise une chaine de charactère il faut la passer dans mysql_real_escape_string()... mais attention au magic_quotes si elle sont activées
function escapeDatas($data)
{
if(is_numeric($data))
return $data;
if (get_magic_quotes_gpc())
$data = stripslashes($data);
return mysql_real_escape_string($data);
}
'SELECT ... .. . WHERE nom=\''.escapeDatas($nom).'\''
Etc... fais une recherche sur le net tu trouvera bon nombre de doc traitant du sujet... .. .
@ tchaOo°
30 janv. 2007 à 14:08
Peux-tu nous donner des exemples ?
Merci beaucoup
30 janv. 2007 à 13:55
30 janv. 2007 à 12:24
Si on recoit dans POST ou GET, ca veut pas forcément dire qu'on va les mettres en BDD.
De plus, il aurait été judicieux d'utiliser mysql_real_escape_string() que pour du type chaine. Bah vi, y'a que sur ca que ca fonctionne cette fonction.
:)
30 janv. 2007 à 11:25
Sinon le code est, à mon sens, inutile car il traite tout le tableau ce qui n'est pas nécessaire vu que généralement on ne se sert que d'une ou deux valeur pour une requete sql ou pour un affichage... qui plus est en se qui concerne le mysql_real_escape_string() tu ne vérifie pas si magic_quotes est activé ou non... .. .
@ tchaOo°
30 janv. 2007 à 10:59
30 janv. 2007 à 10:24
30 janv. 2007 à 08:58
pourriez-vous m'expliquer ce que signifie une connexion à la bdd doit être active ? et aussi pourriez-vous expliquer un peu votre code ? merci beaucoup je suis novice et j'aime bien comprendre
30 janv. 2007 à 08:13
ce n'est pas contre les SQL injections, mais contre les MYSQL injections, ça.
Sinon, ça aurait plus sa place sur codyx.org qu'ici, mais bon...
29 janv. 2007 à 23:34
29 janv. 2007 à 23:29
29 janv. 2007 à 22:38
29 janv. 2007 à 22:37
mysql_real_escape_string() ne marche que si une connection mysql est active.