2017-07-28 2 views
0

J'ai regardé dans opencart, qui est écrit en PHP.PHP SQL injection possibilité

Si vous regardez le fichier php suivant,

https://github.com/opencart/opencart/blob/master/upload/admin/model/customer/customer.php

L'instruction SQL ressemble à ceci

$this->db->query("INSERT INTO " . DB_PREFIX . "customer 
SET customer_group_id = '" . (int)$data['customer_group_id'] . "', 
firstname = '" . $this->db->escape($data['firstname']) . "', 
lastname = '" . $this->db->escape($data['lastname']) . "', 
email = '" . $this->db->escape($data['email']) . "', 
telephone = '" . $this->db->escape($data['telephone']) . "', 
custom_field = '" . $this->db->escape(isset($data['custom_field']) ? json_encode($data['custom_field']) : json_encode(array())) . "', 
newsletter = '" . (int)$data['newsletter'] . "', 
salt = '', 
password = '" . $this->db->escape(password_hash($data['password'], PASSWORD_DEFAULT)) . "', 
status = '" . (int)$data['status'] . "', 
safe = '" . (int)$data['safe'] . "', 
date_added = NOW()"); 

La méthode recommandée pour éviter l'injection PHP SQL est d'utiliser les commandes préparées .

Ma question est de savoir comment ce code n'utilise pas les instructions préparées, ce code est-il vulnérable à l'injection sql?

Je ne suis pas un expert en php alors je pourrais manquer quelque chose d'évident ici.

EDIT:

Permettez-moi d'énumérer les raisons pour lesquelles je suis un peu inquiet d'accepter que ce code est vulnérable.

  1. OpenCart (https://github.com/opencart/opencart) est un projet open source populaire avec plus de 200 fourches. C'est en fait une solution de panier d'achat (e-commerce), donc le développeur aurait pensé à la sécurité, et les injections sql comme celle-ci sont l'une des premières choses qu'ils auraient vérifiées.

  2. Il ne ressemble à une sorte d'échappements est fait en utilisant $this->db->escape($data['telephone'])

+5

Oui, ce code est vulnérable, car il n'utilise pas [Prepared Statements] (https://www.w3schools.com/php/php_mysql_prepared_statements.asp), ** Escaping strings n'est plus la solution recommandée pour SQL Injection, et il ne suffit PAS ** – GrumpyCrouton

+3

duplication possible de [Comment puis-je empêcher l'injection SQL en PHP?] (https://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php – Qirel

+0

Le seul moyen de protection contre l'injection SQL consiste à utiliser des instructions préparées.Ceci est également mieux dans de nombreux autres aspects - évitez d'échapper, utilisez simplement des instructions préparées. – Qirel

Répondre

1

Comme tout est soit ou se sont échappés converti en un entier, je dirais que ce n'est pas vulnérable à l'injection SQL.

Bien sûr, Qirel a raison de dire que l'utilisation d'instructions préparées est une meilleure solution de toutes les manières imaginables. Il est beaucoup plus difficile à lire et il peut facilement être rendu vulnérable par erreur lors de la modification du code dans le futur. Après un peu de recherche, il semble que cela ne soit vrai que sous l'hypothèse que le jeu de caractères de la base de données a été correctement défini. Autrement il peut être vulnérable aux attaques multi-octets. OpenCart semble être vulnérable lors de l'utilisation de MySQL si un jeu de caractères incorrect est défini au niveau du serveur car il utilise la requête SET CHARACTER SET au lieu de mysql_real_escape_string. Vous pouvez le voir dans latest v3.0.2.0 sur Github. Pour plus de détails, voir MySQL Character sets dans le manuel PHP. J'ai proposé une solution de ce problème particulier dans !5812.