mysql_real_escape_string pas assez bon?

Question

Donc, en utilisant% 27 vous pouvez simplement SQL Inject même si les données sont désinfecté avec mysql_real_escape_string

%27) SQL INJECTION HERE %2F*

Que faire?

Modifier par exemple:

$sql = sprintf("SELECT *, MATCH(post) AGAINST ('%s*' IN BOOLEAN MODE) AS score FROM Posts WHERE MATCH(post) AGAINST('%s*' IN BOOLEAN MODE)",
                mysql_real_escape_string($_GET['searchterm']),
                mysql_real_escape_string($_GET['searchterm']));

$results = $db->queryAsArray($sql);

Si vous passez %27) SQL INJECTION HERE %2F* à la querystring de searchterm, je reçois sur la page en sortie:

Vous avez une erreur dans votre syntaxe SQL; vérifier le manuel qui correspond à votre version du serveur MySQL pour la bonne syntaxe à utiliser près de « BOOLEAN MODE) » à la ligne 1

Merci à tous pour trouver le problème dans la classe db ..

Answer 1

Raisonnement du nom de la méthode queryAsArray, il semble que vous utilisez ce < em> DBBase classe des commentaires des fonctions de MySQL page de manuel . Si oui, il est la méthode query qui supprime le caractère d'échappement des guillemets échappées:

function query($sql, &$records = null){
    $sql = str_replace(array('\\"', "\\'"), array('"', "'"), $sql);
    // …
}

Alors ce n'est pas un miracle que vos œuvres par exemple (j'ai simplifié il):

$input = "', BAD SQL INJECTION --";

$sql = "SELECT '".mysql_real_escape_string($input)."'";
var_dump($sql);  // string(33) "SELECT '\', BAD SQL INJECTION --'"
//                      everything’s OK ↑

$sql = str_replace(array('\\"', "\\'"), array('"', "'"), $sql);
var_dump($sql);  // string(32) "SELECT '', BAD SQL INJECTION --'"
//                                Oops! ↑

Answer 2

La note mentionné dans notre manuel a été marqué pour la suppression. Une fois qu'il se propage à travers tous les miroirs de notre réseau, il n'apparaîtra plus attaché à la documentation officielle.

~ Daniel P. Brown
  Network Infrastructure Manager
  http://php.net/

Answer 3

Il est préférable de ne pas les déclarations de construction comme celui-ci à tous, et utiliser à la place des requêtes avec des paramètres en utilisant mysqli ou AOP. Cela traitera du problème de l'injection MySQL et un jour (pas encore, malheureusement), il fonctionnera mieux aussi, car les requêtes sont mises en cache sans paramètres, qui signifie que vous n'avez une requête dans le cache au lieu de dizaines de requêtes différentes à cause d'un seule valeur d'entrée change tout le temps. D'autres bases de données utilisent ce depuis longtemps, mais MySQL juste réussi à ne pas faire des requêtes paramétrées plus lent depuis la dernière version.

Il ne semble pas plausible que 27% prendra fin en fait la chaîne. Il semble plus comme une possibilité de citations imbriquer l'intérieur d'une chaîne, mais je ne suis pas sûr.

Pour être sûr, j'ai décidé de sacrifier mon serveur et tester. Quand j'entre 27% dans un champ d'entrée et textarea qui sont échappé avec mysql_real_escape_string et sont ensuite insérées dans la base de données, je reçois aucune erreur. Le %27 texte est vient d'être inséré. Donc pas de problème du tout.

Answer 4

Vous avez tort. Aucune injection possible ici.

En suivant ces trois règles simples

1. du client codant correctement défini par mysql_set_charset()
2. Les données étant using mysql_real_escape_string() échappé
3. Et entre guillemets

vous pouvez être sûr qu'aucune injection possible