Protection des requetes SQL

rimie · 25-11-2011 02:53:04

Bonjour,

Je fais mes requetes par la methode query, comment puis je proteger mes donnees contre les injections, cote insert, select, update.

$sql = 'INSERT INTO commentaires VALUES (\'\', "'.$level1.'", "'.$level2.'", "'.$level3.'", "'.$num.'", "'.$commentaire.'", "'.$idpseudo.'", "'.$date_posted.'")';

$req = $connexion->query($sql);

merci

Jc · 25-11-2011 04:35:36

Bonjour,

En commençant par suivre ces recommendations.

N'hésite pas à demander si t'as pas compris quelque chose.

++

rimie · 25-11-2011 05:50:18

Jc a écrit :

Bonjour,
En commençant par suivre ces recommendations.
N'hésite pas à demander si t'as pas compris quelque chose.
++

J'ai mis mon code et je voudrais juste savoir comment le proteger des injections, on sait bien que je dois utiliser les quote, mais je voudrais me donner plus de conseils sur la securite de mes codes

Jc · 25-11-2011 11:22:20

Bonjour

Alors, dans ces recommendations, si tu les suis à la lettre tu n'as plus de problèmes d'injection possible.

jc a écrit :

Quand vous développez une fonction pour accomplir une tache A à partir d'un paramètre p (ou plusieurs)
1) La fonction ne sait pas ce qu'est p si ce n'est un paramètre : Assurez vous de la bonne valeur du paramètre p avant de le valider et retourner un message d'erreur ou un Numéro d'erreur pour chaque mauvaise valeur de p qui est tentée d'être passée à la fonction.

Une attaque par injection survient quand par exemple en guise de mot de passe on place du code MySQL à la place pour avoir à éviter d'avoir à rentrer le mot de passe. Donc outre le fait de ne jamais passer les variables de saisie directement dans tes requêtes, le meilleur moyen s'est de vérifier ce qu'à saisi l'utilisateur comme dit précedemment.
Et pour cela, le MIEUX c'est de faire un preg_match sur tes variables.

++

Dernière modification par Jc (27-11-2011 20:37:22)

Maljuna Kris · 25-11-2011 11:34:44

Saluton,
Autre petite précaution qui ne mange pas de pain, inverser, dans le code SQL, l'ordre des arguments de comparaison :

WHERE '$valeur'=nomdecolonne

// au lieu de 

WHERE nomdecolonne='$valeur'

Ceci ne doit pas être considéré comme une alternative à ce que préconise Jc, c'est juste un petit plus.

Jc · 25-11-2011 15:51:23

Ca ne mange pas de pain en effet l'idée est plus que bonne! Merci MK

Dernière modification par Jc (25-11-2011 15:51:57)

rimie · 26-11-2011 15:42:04

et je peux utiliser aussi quote()?

Jc · 26-11-2011 17:15:25

Bonjour,

Oui tu peux, mais cela n'a rien à voir. Moi en général j'utilise addslashes() ou htmlentities() selon le contexte et uniquement pour les champs où je dois accepter que l'utilisateur utilise les simples ou doubles quotes.

++

Pierrot · 27-11-2011 09:57:01

salut
moi, j'utilise PDO
a++

Jc · 27-11-2011 10:02:23

Lol, tiens, y avait longtemps, et je ne comprends pas pourquoi cela ne m'étonnes pas^^ PDO, que j'utilise exclusivement aussi, ne m'évite pas de devoir utiliser addslashes ou htmlentities.^^

Sacré Pierrot

Maljuna Kris · 27-11-2011 10:02:29

Pierrot a écrit :

salut
moi, j'utilise PDO
a++

C'est plus qu'un bon début, Pierrot, mais pour être nécessaire, est-ce suffisant ? (sans vouloir l'être (suffisant))

Pierrot · 27-11-2011 11:07:02

mk->
les sécurités par défauts sont bien au dessus de ce que peu faire un débutant avec mysqli
a++

Maljuna Kris · 27-11-2011 16:34:54

Tu prêches un convaincu, Pierrot, je rappelle ici que je lançai, onques, cette croisade.

rimie · 29-11-2011 04:10:28

est ce qu'on fait ce genre de protection (htmlentities, addslashes,..) meme pour les requete SELECT et DELETE, ou bien juste pour INSERT et UPDATE?

Jc · 29-11-2011 10:51:27

Bonjour,

Cela serait bienvenu d'essayer de réfléchir un peu^^, sincèrement. Voici la doc sur la fonction addslashes.
Et voici le contexte que j'ai utilisé

jc a écrit :

Moi en général j'utilise addslashes() ou htmlentities() selon le contexte et uniquement pour les champs où je dois accepter que l'utilisateur utilise les simples ou doubles quotes.

Si pour saisir un nom de famille l'utilisateur s'appele O'Reilly (exemple du lien du manuel PHP et qui correspond au cas où l'utilisateur utilise une simple quote, que ce passe-t-il si l'on n'échappe pas la simple quote??

Regardons cela de plus près donc.

$nom="O'Reilly"; // on est obligé déjà ici de définir la chaîne de caractères entre double quotes car sinon $nom='O'Reilly'; générait un syntax error par le parseur PHP.

$machainedesortie='Avez-vous vu '.$nom.' sortir de la maison?'; // va générer une erreur par le parseur php également car il va y avoir un conflit entre les simples quotes de définition de la chaîne de caractères et la simple quote contenu dans la variable $nom.

Donc comme je le disais, cela n'a rien à voir avec des problèmes d'injection^^.

Et selon comment vous définissez/structurez votre code vous pouvez même parfois vous en passer.

ex: Cas où vous autorisez uniquement les simples quotes dans la variable $nom via un preg_match préalable (pas de double donc).
Ecrire

$machainedesortie="Avez-vous vu $nom sortir de la maison?"; // ne générera jamais d'erreur et pas besoin du addslashes ni d'autre chose

 

Cas où vous autorisez uniquement les doubles quotes dans votre variable $nom via un preg_match préalable (pas de simple donc).

$machainedesortie='Avez-vous vu '.$nom.' sortir de la maison?'; // ne générera jamais d'erreur et pas besoin du addslashes ni d'autre chose également, mais on a été obligé d'adapter notre écriture de code par rapport à précedemment.

 

Vous autorisez les simples et doubles quotes dans votre variable. Pas le choix: il faut utiliser une fonction comme addslashes.

$nom="\"Je m'appele O'Reilly\" dit-il "; // les doubles quote de citation ont du être échappés pour pouvoir être inclus dans la variable $nom.

 

J'espère que cela est clair maintenant pour vous.
Par conséquent vous avez la réponse à votre dernière question.

Cordialement,

Jc

Dernière modification par Jc (29-11-2011 11:08:56)

rimie · 02-12-2011 02:43:34

Merci Jc pour l'explication

moogli · 02-12-2011 10:25:54

yop,

perso je rappelerais la doc de addslashes

Un exemple d'utilisation d'addslashes() est lorsque vous entrez des données dans une base de données. Par exemple, pour insérer le nom O'reilly dans la base, vous aurez besoin de le protéger. Il est fortement recommandé d'utiliser les fonctions de protection spécifiques à chaque base de données (telle que mysqli_real_escape_string() pour MySQL et pg_escape_string() pour PostGreSQL), mais si la base de données que vous utilisez n'a pas de fonction spécifique, et que cette base utilise \ pour protéger les caractères spéciaux, vous pouvez utiliser cette fonction. Grâce à elle, \ sera ajouté. Si la directive PHP magic_quotes_sybase est activée, ' sera protégé par un autre '.
La directive PHP magic_quotes_gpc est à on par défaut, et elle appelle addslashes() sur toutes les données GET, POST et COOKIE. N'utilisez pas addslashes() sur des données déjà protégées avec magic_quotes_gpc sinon vous doublerez les protections. La fonction get_magic_quotes_gpc() est utile pour vérifier ce paramètre.

donc avec l'extension mysql(i) mysql(i)_real_escape_string
avec PDO quote() (et pas de requête préparée à tout va svp )

pourquoi ?
parce que comme le dit la doc de mysqli_escape_string

Les caractères encodés sont NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.

alors que addslashes dit

Ces caractères sont les guillemets simples ('), guillemets doubles ("), antislash (\) et NUL (le caractère NULL).

Ca fait le même taff en mieux

quand au htmlentities, à réserver pour l'affichage, ceci rien que pour garder la possibilité de faire autre chose que du html avec ta base de donnée, par exemple utilise un soft fait dans un autre, java, C, ce que l'on veux pour utiliser en dehors d'un contexte web, ou plus simplement pour un export sur différent support, comme PDF ou n'importe quoi d'autre

@+

PHP|Débutant :: Forums

Advertisement

#1 25-11-2011 02:53:04

Protection des requetes SQL

#2 25-11-2011 04:35:36

Re : Protection des requetes SQL

#3 25-11-2011 05:50:18

Re : Protection des requetes SQL

#4 25-11-2011 11:22:20

Re : Protection des requetes SQL

#5 25-11-2011 11:34:44

Re : Protection des requetes SQL

#6 25-11-2011 15:51:23

Re : Protection des requetes SQL

#7 26-11-2011 15:42:04

Re : Protection des requetes SQL

#8 26-11-2011 17:15:25

Re : Protection des requetes SQL

#9 27-11-2011 09:57:01

Re : Protection des requetes SQL

#10 27-11-2011 10:02:23

Re : Protection des requetes SQL

#11 27-11-2011 10:02:29

Re : Protection des requetes SQL

#12 27-11-2011 11:07:02

Re : Protection des requetes SQL

#13 27-11-2011 16:34:54

Re : Protection des requetes SQL

#14 29-11-2011 04:10:28

Re : Protection des requetes SQL

#15 29-11-2011 10:51:27

Re : Protection des requetes SQL

#16 02-12-2011 02:43:34

Re : Protection des requetes SQL

#17 02-12-2011 10:25:54

Re : Protection des requetes SQL

Pied de page des forums