+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Protection Injection SQL (/showthread.php?tid=2110)
Protection Injection SQL - MyHeadXplod - 06-12-2007
Hello !
Est-ce que vous pensez que l'utilisation de ces deux fonctions est suffisante pour se protéger des injections SQL :
Citation :$query = sprintf("INSERT INTO une_table VALUES('','%s','%s','%s','%s','%s','%s')",
mysql_real_escape_string($var01),
mysql_real_escape_string($var02),
mysql_real_escape_string($var03),
mysql_real_escape_string($var04),
mysql_real_escape_string($var05),
mysql_real_escape_string($var06));
Si vous avez des liens intéressants là dessus je suis preneur.
Merci.
RE: Protection Injection SQL - Sephi-Chan - 06-12-2007
Ou ça 2 fonctions de protéction ? Concernant sprintf() ça ne sécurise pas, ça facile le déboguage. D'ailleurs comme tu fais cette démarche (c'est une bonne chose), je te conseille de citer les champs de la table que tu vas remplir.
Ensuite, mysql_real_escape_string suffit à protéger contre l'injection.
Sephi-Chan
RE: Protection Injection SQL - MyHeadXplod - 06-12-2007
Citation :Ou ça 2 fonctions de protéction ? Concernant sprintf() ça ne sécurise pas, ça facile le déboguage. D'ailleurs comme tu fais cette démarche (c'est une bonne chose), je te conseille de citer les champs de la table que tu vas remplir.Oui je sais que sprintf() ne protège pas, je voulais parler de l'utilisation que je fais de ces deux fonctions, enfin bref. Si je vous pose cette question c'est que j'ai trouvé dans le commentaire d'un article sur php france cette phrase (c'est l'article sur php 6 pour ceux qui veulent aller voir)
Citation :Tu ne fais donc pas les bons tests. htmlentities, ni même addslashes, ne protège pas de l'injection SQL. Une vraie protection passe par un traitement adapté des données entrées (ex: liste blanche, typage, etc.) en fonction du contexte.Vous voyez de quoi il parle? Liste blanche c'est quoi? oO
RE: Protection Injection SQL - Zamentur - 07-12-2007
Euh si j'ai bien compris il dit qu'il faut savoir et controler les variables provenant de l'exterieur (donc les superglobal(POST, GET,COOKIE,SERVER...), et les fichiers lus depuis un domaine externe)
Pour le typage il entand par là: est ce un entier positif? est ce une chaine alphanumerique?
Et pour les listes blanches j'ai jamais entendue parler de çà mais je pense qu'il s'agit des valeur vide retourné quand un utilisateur renvoie un formulaire trop tot sans le remplir totalement.
En fait mysql_real_escape_string($var01) permet de proteger contre l'injection et htmlentities peut proteger contre l'injection html, mais aucun ne te garantie que les données sont valides (dans le sens de l'application)
Il doit donc y avoir un controle avant qui le verifie
Un exemple tout bete qui était reel sur ma propre beta il y a 3 ans:
j'avai une table qui gerais les magasins chaque magasins posserder un compte. Tout comme les perso
Quand un perso acheter un objet une variable "prix" transmise par formulaire mettais à jour les compte. Et çà sans verification.
Jusqu'au jour ou j'ai eu des joueurs qui ouvraient des magasins pour y acheter eux meme un objet à -1000000 mesetas. De cette façon ils devenaient riche à millions
Pourtant il m'a suffit de verifier cette fameuse variable prix qui transiter du client vers le serveur et que je conciderais comme vrai...
RE: Protection Injection SQL - MyHeadXplod - 07-12-2007
Citation :Un exemple tout bete qui était reel sur ma propre beta il y a 3 ans:
j'avai une table qui gerais les magasins chaque magasins posserder un compte. Tout comme les perso
Quand un perso acheter un objet une variable "prix" transmise par formulaire mettais à jour les compte. Et çà sans verification.
Jusqu'au jour ou j'ai eu des joueurs qui ouvraient des magasins pour y acheter eux meme un objet à -1000000 mesetas. De cette façon ils devenaient riche à millions
Pourtant il m'a suffit de verifier cette fameuse variable prix qui transiter du client vers le serveur et que je conciderais comme vrai...
Hé hé, c'est exactement le genre de chose auquel je ne pense pas xD
C'est surtout au niveau de l'injection sql que je me posais des questions car depuis j'utilise seulement mysql_real_escape_string($var01) et le gars de php France m'a fait flipper avec ses histoires de liste blanche... :ninga:
RE: Protection Injection SQL - Sephi-Chan - 07-12-2007
Je vois le genre...
C'est grâce à ce genre de bug exploit que j'ai pu m'enrichir sur une partie de RPG Illusion avec des amis : j'avais défini un prix négatif à une auberge, ce qui me permettait de m'enrichir quand je m'y reposais.
En gros, il faut - à chaque fois que tu reçois une donnée de l'utilisateur - vérifier sa validité. Si tu attends un nom de personnage, tu peux restreindre cela à une trentaine de caractères, vérifier que ça ne contient pas tel ou tel caractères.
Si tu as un champ select donc les valeurs sont 1, 2 ou 3, il faut que tu vérifies à la réception du formulaire si l'entrée contient effectivement l'une de ces valeurs, car elles sont facilement falsifiables. Tu peux te servir pour ça d'un switch.
Ensuite, plus évident, quand tu permets à tes membres de supprimer quelque chose, vérifie bien que la ressource qu'ils ont choisis leur appartient.
Sephi-Chan