Les différences entre plusieurs fonctions d'attaque par injection anti-SQL

L'attaque par injection SQL est la méthode la plus couramment utilisée par les pirates pour attaquer les sites Web. Si votre site n'utilise pas de validation stricte des entrées utilisateur, il est souvent vulnérable aux attaques par injection SQL. Les attaques par injection SQL sont généralement mises en œuvre en soumettant des données incorrectes ou des instructions de requête à la base de données du site, ce qui peut entraîner l'exposition, la modification ou la suppression des enregistrements de la base de données.

Afin de prévenir les attaques par injection SQL, PHP est livré avec une fonction qui peut traiter la chaîne d'entrée et effectuer un traitement de sécurité préliminaire sur l'entrée au niveau inférieur, c'est-à-dire Magic Quotes. (php.ini magic_quotes_gpc). Si l'option magic_quotes_gpc est activée, les guillemets simples, les guillemets doubles et les autres caractères de la chaîne d'entrée seront automatiquement précédés d'une barre oblique inverse /.

Mais Magic Quotes n'est pas une solution très universelle, elle ne bloque pas tous les personnages potentiellement dangereux, et Magic Quotes n'est pas activé sur de nombreux serveurs. Par conséquent, nous devons également utiliser diverses autres méthodes pour empêcher l’injection SQL.

De nombreuses bases de données fournissent nativement cette fonctionnalité de traitement des données d’entrée. Par exemple, les fonctions d'opération MySQL de PHP incluent addlashes(), mysql_real_escape_string(), mysql_escape_string() et d'autres fonctions, qui peuvent échapper aux caractères spéciaux et aux caractères pouvant provoquer des erreurs de fonctionnement de la base de données. Alors, quelles sont les différences entre ces trois fonctions fonctionnelles ? Parlons-en en détail ci-dessous.

Bien que de nombreux programmeurs PHP nationaux s'appuient encore sur les addlashes pour empêcher l'injection SQL, il est recommandé à chacun de renforcer les contrôles pour empêcher l'injection SQL en chinois. Le problème avec les addlashes est que les pirates peuvent utiliser 0xbf27 au lieu de guillemets simples, tandis que les addlashes ne changent que 0xbf27 en 0xbf5c27, qui devient un caractère multi-octets valide. 0xbf5c est toujours considéré comme un guillemet simple, donc les addlashes ne peuvent pas être interceptés avec succès.

Bien sûr, les addlashes ne sont pas inutiles. Ils sont utilisés pour traiter des chaînes à un octet. Pour les caractères multi-octets, utilisez mysql_real_escape_string.

De plus, pour l'exemple de get_magic_quotes_gpc dans le manuel PHP :

if (!get_magic_quotes_gpc()) {
$lastname = addslashes($_POST[‘lastname’]);
} else {
$lastname = $_POST[‘lastname’];
}

Il est préférable de vérifier $_POST['lastname'] lorsque magic_quotes_gpc est déjà ouvert.

Parlons de la différence entre les deux fonctions mysql_real_escape_string et mysql_escape_string :

mysql_real_escape_string doit être utilisé sous (PHP 4 >= 4.3.0, PHP 5). Sinon, vous ne pouvez utiliser que mysql_escape_string. La différence entre les deux est la suivante : mysql_real_escape_string prend en compte le jeu de caractères actuel de la connexion, contrairement à mysql_escape_string.

Pour résumer :

* addlashes() est un ajout forcé de /;
* mysql_real_escape_string() déterminera le jeu de caractères, mais il y a des exigences pour la version PHP;
* mysql_escape_string ne prend pas en compte le jeu de caractères actuel de la connexion.

Pour empêcher l'injection de SQL dans dz, vous utilisez la fonction addlashes. En même temps, il y a quelques remplacements dans la fonction dthmlspecialchars $string = preg_replace('/&(((#(/d{3). ,5}|x [a-fA-F0-9]{4}));)/', '&//1', ce remplacement résout le problème d'injection et résout également certains problèmes de caractères chinois tronqués

Apprentissage recommandé : Tutoriel vidéo PHP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!