Votre question

securité injection SQL

Tags :
  • Web
  • Sécurité
  • Sql
Dernière réponse : dans Sécurité et virus
1 Avril 2014 23:39:17

Bonjour a tous, ma question ce portant sur de la sécurité pur il m'a paru pertinent de la poster ici.

je suis développeur web et pour me protéger des injections SQL je me sert de la fonction "addslashes" de PHP

or j’ai entendu dire que cette sécurité pouvait être contourné ( sa m’inquiète)

on m'a dit qu'avec un certain nombre d'anti-slashs la fonction finissait par défaillir.
j'ai personnellement essayer avec un script php qui simulé une injection SQL avec un nombre différant de "\" ( de 1 a plusieurs millions ! en mettant un temps d’exécution très long a PHP ) et l'injection n'est jamais passé a travers la protection addslashes ...

pouvez vous me dire si il a été avéré que addslashes est faillible avec preuve a l’appuie ?

merci de votre réponse,
mdj de normandie

Autres pages sur : securite injection sql

2 Avril 2014 15:57:30

Salut

Pour répondre simplement, il faut absolument éviter d'utiliser des fonctions faisant ce genre de chose (ajouter automatiquement des caractères pour échapper les caractères spéciaux). Il me semblait que ces fonctions étaient marquées comme deprecated depuis php 4 ou 5, mais j'ai rien retrouvé.

Cependant, l'exploitation n'est pas aussi trivial, ça va dépendre du contexte, des traitements, de la base de données, etc. Maintenant, on sait que c'est faisable.

L'idéal, c'est soit de trouver des fonctions de confiance, soit le faire soi-même (mais c'est plus dur).
m
0
l
Contenus similaires
Pas de réponse à votre question ? Demandez !
2 Avril 2014 22:57:25

re, j'avais jeté un oeuil au prépare et exec de PDO ( je suis un adepte de PDO ) mais je trouvé le comportement bizarre et ne m’inspirai pas confiance.

quant au lien sur la vulnérabilité du addslash, j'ai compris que la methode consisté a envoyer le code du caractère d'apostrophe codé sur un octet, mais cette faille ne semple fonctionner que sur l'utilisation de certains encodage il est d'ailleur spécifié en bas de la page que UTF-8 ne soit pas un encodage sensible a cette faille.

par chance que n'utilise exclusivement que de l'encodage UTF-8 ( que je force via une balise meta charset, et un set names utf8 dans mes requêtes SQL), j'ai tout de même refait des essai en exploitant la méthode décrite, l'injection n'est pas passé ...

d'autres idées ?
m
0
l
3 Avril 2014 18:29:55

Du coup UTF8 + PDO (+ éventuellement des str_replace) = pas de soucis ?
m
0
l
4 Avril 2014 10:15:17

personnellement je passe toutes mes variables destiné a être utilisé dans une raquette dans cette fonction afin de me protéger des injections SQL et XSS :
  1. public function protect_var($var) {
  2. return addslashes(htmlspecialchars(htmlspecialchars_decode($var)));
  3. }


et en amont je fait un $pdo->query("SET NAMES UTF8");

je n'ai pour le moment trouver aucune faille a ma sécurité mais je sais que rien n'est infaillible ... je voulais juste savoir si quelqu'un voyait une faille et pouvais la démontrer...
m
0
l
Tom's guide dans le monde
  • Allemagne
  • Italie
  • Irlande
  • Royaume Uni
  • Etats Unis
Suivre Tom's Guide
Inscrivez-vous à la Newsletter
  • ajouter à twitter
  • ajouter à facebook
  • ajouter un flux RSS