Sécurisation requêtes SQL

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Sécurisation requêtes SQL

Re: Sécurisation requêtes SQL

par Ehplod » 17 nov. 2010, 15:09

Donc le contenu de ta base de données est en théorie "propre"
C'est là qu'intervient ma demande... et si on a eu acces à la bdd (vol de mdp, par exemple) et que l'on y a inséré quelque chose de malsain ?
De plus dans ce second cas ta bdd compare les valeurs l'une à l'autre et n'interprète en aucun cas leur contenu, donc rien à craindre de ce côté là
Ok, ça, ça me rassure.

Merci.

Re: Sécurisation requêtes SQL

par Ryle » 04 sept. 2010, 10:01

Je ne comprend pas bien ton problème et je pense que tu te poses une question qui à mon sens n'a pas lieu d'être...

Si lors d'un select tu fais appel a htmlentities et compagnie pour comparer la valeur saisie à la valeur en base, c'est que au moment où tu as enregistré la valeur dans ta base de données tu l'as protégé avec ces mêmes contrôles. Donc le contenu de ta base de données est en théorie "propre" et tout ce que tu as besoin de contrôler ce sont les données envoyées par l'utilisateur.

Quand tu fais une seconde requête après avoir récupéré une valeur de ta base, cette valeur est déjà sécurisée et tu peux donc l'utiliser en toute tranquillité dans ta requête suivante. De même dans une jointure, tu compares les valeurs déjà stockées, donc déjà protégées...

De plus dans ce second cas ta bdd compare les valeurs l'une à l'autre et n'interprète en aucun cas leur contenu, donc rien à craindre de ce côté là ;)

En espérant que cela répondre à ta question (et que j'ai bien compris celle ci :))

Re: Sécurisation requêtes SQL

par Ehplod » 02 sept. 2010, 12:35

D'accord pour les numériques, mais pas d'accord du tout pour le texte où c'est mysql(i)_real_escape_string qu'il faut utiliser avant insert ou update.

Re: Sécurisation requêtes SQL

par AoSiX » 24 août 2010, 10:26

Salut,

en terme pour sécurisation pour ma part...

- Texte divers : addslashes à l'INSERT/UPDATE, puis stripslashes au SELECT
- Entier : intval
- Decimaux : doubleval

Je pense que ça suffit amplement

Re: Sécurisation requêtes SQL

par Ehplod » 24 août 2010, 10:14

Merci, mais ça ne m'apporte rien ce lien. Autant me linker Google. ;-)

De plus, je boycottes CCM pour spam et pollution des SERPs de Google.

Re: Sécurisation requêtes SQL

par alexb » 22 août 2010, 18:58

Sécurisation requêtes SQL

par Ehplod » 14 août 2010, 11:49

Salut,

Bon, je connais comment sécuriser de base mes données, à savoir, contrôler que la variables envoyé correspond à ce que j'attend, utiliser htmlentities avant l'affichage, mysql(i)_real_escape_string avant insertion dans bdd, etc...

ma question porte sur la sécurisation de données insérés dans une requête.

Cas n°1 :
Je récupère $var en $_GET ou $_POST.
Je contrôle qu'elle correspond à mon attente, exemple (-azAZ)
Je fais ma requête SELECT Achamp1 FROM MaTable WHERE Achamp2 = $var
Là, pas de soucis, je pense.

Cas n°2 :
Je récupère $var en $_GET ou $_POST.
Je ne peut contrôler à quoi elle correspond, vu que tous les caractères sont autorisés.
Je fais ma requête SELECT Achamp1 FROM MaTable WHERE Achamp2 = htmlentitie($var, enquote...)
Là, pas de soucis non plus, je pense.

Cas n°3 :
Je fais ma requête SELECT Achamp1, Achamp2 FROM MaTable LIMIT 0,1
De là découle une seconde requête SELECT Bchamp1 FROM MaTable2 WHERE Bchamp2 = Achamp2
Pour x raisons, je n'utilise pas les jointures.
Comment sécuriser cette seconde requête au cas ou mon Achamp2 a été trafiqué ?
Je peux contrôler ce que j'attends de Achamp2, voir utiliser htmlentitie sur Achamp2.
Mais est-ce tout ?

Cas n°4 :
Avec jointure
Je fais ma requête SELECT Achamp1, Bchamp1 FROM MaTable JOIN MaTable2 ON Achamp2 = Bchamp2 LIMIT 0,1
Comment protéger cette requête au cas ou l'on est pas sur de Achamp2 ?

Merci