Sécurité PHP-Injection SQL

Injection SQL

SQL L'injection est l'une des vulnérabilités les plus courantes dans les applications PHP. En fait, il est étonnant qu'un développeur doive commettre deux erreurs en même temps pour déclencher une vulnérabilité d'injection SQL. L'une ne filtre pas les données d'entrée (filtrant l'entrée) et l'autre ne filtre pas les données envoyées à la base de données. . Échapper (sortie d'échappement). Ces deux étapes importantes sont indispensables et nécessitent une attention particulière pour réduire les erreurs de programme.

Pour les attaquants, mener des attaques par injection SQL nécessite réflexion et expérimentation, et il est absolument nécessaire de mener un raisonnement fondé sur la solution de base de données (en supposant bien sûr que l'attaquant ne puisse pas voir votre programme source et votre solution de base de données). Considérez le simple formulaire de connexion suivant. :

CODE :

<form action="/login.php" method="POST">
<p>Username: <input type="text"
name="username" /></p>
<p>Password: <input type="password"
name="password" /></p>
<p><input type="submit" value="Log In"
/></p>
</form>

La figure 3-1 montre l'affichage de ce formulaire dans le navigateur.

En tant qu'attaquant, il commencerait par spéculer sur une requête visant à vérifier le nom d'utilisateur et le mot de passe. En regardant les fichiers sources, il peut commencer à deviner vos habitudes.

Figure 3-1 Affichage du formulaire de connexion dans le navigateur

Convention de dénomination. On suppose généralement que les noms de champs de votre formulaire sont les mêmes que ceux de la table de données. Bien entendu, s’assurer qu’ils sont différents n’est pas nécessairement une mesure de sécurité fiable.

Pour la première hypothèse, vous utiliserez généralement la requête dans l'exemple suivant :

CODE :

<?php
 
$password_hash = md5($_POST[&#39;password&#39;]);
 
$sql = "SELECT count(*)
      FROM   users
      WHERE  username = &#39;{$_POST[&#39;username&#39;]}&#39;
      AND    password = &#39;$password_hash&#39;";
 
?>

L'utilisation de la valeur MD5 du mot de passe utilisateur était à l'origine une pratique courante, mais maintenant ce n'est pas spécial, c'est sûr. Des recherches récentes montrent que l'algorithme MD5 est défectueux et que le grand nombre de bases de données MD5 réduit la difficulté du craquage inverse MD5. Veuillez visiter http://www.php.cn/ Découvrez la démo.

Note de traduction : Il s'agit du texte original. Les recherches menées par Wang Xiaoyun, professeur à l'Université du Shandong, montrent que la « collision » MD5 peut être rapidement trouvée, c'est-à-dire deux fichiers et chaînes différents qui peuvent produire la même valeur MD5. MD5 est un algorithme de synthèse d'informations, pas un algorithme de chiffrement, donc le piratage inversé est hors de question. Cependant, d'après ce résultat, dans le cas particulier ci-dessus, il est dangereux d'utiliser directement md5.

La meilleure méthode de protection consiste à ajouter une chaîne de votre propre définition au mot de passe, par exemple :

CODE :

<?php
 
$salt = &#39;SHIFLETT&#39;;
$password_hash = md5($salt . md5($_POST[&#39;password&#39;]
. $salt));
 
?>

Bien entendu, les attaquants peuvent ne pas réussir du premier coup et doivent souvent procéder à quelques expérimentations. Une meilleure façon d'expérimenter consiste à saisir des guillemets simples comme nom d'utilisateur, car cela peut révéler certaines informations importantes. De nombreux développeurs appellent la fonction mysql_error() pour signaler l'erreur lorsqu'une erreur se produit lors de l'exécution d'une instruction Mysql. Voir l'exemple ci-dessous :

CODE :

<?php
 
mysql_query($sql) or exit(mysql_error());
 
?>

Bien que cette méthode soit utile en développement, elle peut exposer des informations importantes à un attaquant. Si l'attaquant utilise des guillemets simples comme nom d'utilisateur et mypass comme mot de passe, l'instruction de requête deviendra :

CODE :

<?php
 
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;&#39;&#39;
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
 
?>

Lorsque la déclaration est envoyée à MySQL, le système affichera le message d'erreur suivant :

You have an error in your SQL syntax. Check the
manual that corresponds to your
MySQL server version for the right syntax to use
near 'WHERE username = ''' AND
password = 'a029d0df84eb55

Sans aucun effort, l’attaquant connaît déjà les deux noms de champs (nom d’utilisateur et mot de passe) ainsi que l’ordre dans lequel ils apparaissent dans la requête. De plus, l'attaquant sait également que les données ne sont pas filtrées correctement (le programme ne demande pas de noms d'utilisateur illégaux) et échappées (une erreur de base de données se produit), et le format de l'intégralité de la condition WHERE est également exposé, afin que l'attaquant puisse essayez de manipuler Il existe des enregistrements qui correspondent à la requête.

À ce stade, l’attaquant dispose de nombreuses options. La première consiste à essayer de saisir un nom d'utilisateur spécial afin que la requête corresponde, que le nom d'utilisateur et le mot de passe correspondent ou non :

myuser' or 'foo' = 'foo' --

假定将mypass作为密码，整个查询就会变成：

CODE:

<?php
 
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;myuser&#39; or &#39;foo&#39; = &#39;foo&#39;
--
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
 
?>

由于中间插入了一个SQL注释标记，所以查询语句会在此中断。这就允许了一个攻击者在不知道任何合法用户名和密码的情况下登录。

如果知道合法的用户名，攻击者就可以该用户(如chris)身份登录：

chris' --

只要chris是合法的用户名，攻击者就可以控制该帐号。原因是查询变成了下面的样子：

CODE:

<?php
$sql = "SELECT *
      FROM   users
      WHERE  username = &#39;chris&#39; --
      AND    password =
&#39;a029d0df84eb5549c641e04a9ef389e5&#39;";
?>

幸运的是，SQL注入是很容易避免的。正如第一章所提及的，你必须坚持过滤输入和转义输出。

虽然两个步骤都不能省略，但只要实现其中的一个就能消除大多数的SQL注入风险。如果你只是过滤输入而没有转义输出，你很可能会遇到数据库错误（合法的数据也可能影响SQL查询的正确格式），但这也不可靠，合法的数据还可能改变SQL语句的行为。另一方面，如果你转义了输出，而没有过滤输入，就能保证数据不会影响SQL语句的格式，同时也防止了多种常见SQL注入攻击的方法。

当然，还是要坚持同时使用这两个步骤。过滤输入的方式完全取决于输入数据的类型（见第一章的示例），但转义用于向数据库发送的输出数据只要使用同一个函数即可。对于MySQL用户，可以使用函数mysql_real_escape_string( )：

CODE:

<?php
 
$clean = array();
$mysql = array();
 
$clean[&#39;last_name&#39;] = "O&#39;Reilly";
$mysql[&#39;last_name&#39;] =
mysql_real_escape_string($clean[&#39;last_name&#39;]);
 
$sql = "INSERT
      INTO   user (last_name)
      VALUES (&#39;{$mysql[&#39;last_name&#39;]}&#39;)";
 
?>

尽量使用为你的数据库设计的转义函数。如果没有，使用函数addslashes( )是最终的比较好的方法。

当所有用于建立一个SQL语句的数据被正确过滤和转义时，实际上也就避免了SQL注入的风险。

CODE:

如果你正在使用支持参数化查询语句和占位符的数据库操作类（如PEAR::DB, PDO等），你就会多得到一层保护。见下面的使用PEAR::DB的例子：

CODE:

<?php
$sql = &#39;INSERT
      INTO   user (last_name)
      VALUES (?)&#39;;
$dbh->query($sql,
array($clean[&#39;last_name&#39;]));
?>

CODE:

 

由于在上例中数据不能直接影响查询语句的格式，SQL注入的风险就降低了。PEAR::DB会自动根据你的数据库的要求进行转义，所以你只需要过滤输出即可。

如果你正在使用参数化查询语句，输入的内容就只会作为数据来处理。这样就没有必要进行转义了，尽管你可能认为这是必要的一步（如果你希望坚持转义输出习惯的话）。实际上，这时是否转义基本上不会产生影响，因为这时没有特殊字符需要转换。在防止SQL注入这一点上，参数化查询语句为你的程序提供了强大的保护。

 

  译注：关于SQL注入，不得不说的是现在大多虚拟主机都会把magic_quotes_gpc选项打开，在这种情况下所有的客户端GET和POST的数据都会自动进行addslashes处理，所以此时对字符串值的SQL注入是不可行的，但要防止对数字值的SQL注入，如用intval()等函数进行处理。但如果你编写的是通用软件，则需要读取服务器的magic_quotes_gpc后进行相应处理。

 以上就是PHP安全-SQL 注入的内容，更多相关内容请关注PHP中文网（www.php.cn）！