Ce n'est pas ce qu'est l'injection SQL. Chaque fois que vous utilisez des paramètres qui n'ont pas été nettoyés dans votre requête SQL, vous laissez votre base de données ouverte à l'injection SQL, qui n'a pas nécessairement pour objectif de détruire les données. Il peut également s'agir de voler des données ou d'obtenir un accès non autorisé.
Considérez un compte très restreint où tout ce qu'il pourrait faire est SELECT . Vous rédigez une requête d'authentification :
$sql = "SELECT COUNT(*) AS count
FROM users
WHERE user_id='{$_POST['user']}' AND pass='{$_POST['password'}'";
// check if returns a count of 1, if yes, log in
Avec une entrée normale, vous vous attendez à ce que la requête ressemble à :
SELECT COUNT(*) AS count
FROM users
WHERE user_id = 'username' AND pass='********'
Qui devrait renvoyer 1 comme nombre si le nom d'utilisateur et le mot de passe correspondent. Maintenant, un attaquant essaie de se connecter en tant qu'administrateur. Comme vous n'avez pas nettoyé vos entrées, elles envoient $_POST['user'] comme :admin'; -- . La requête entière devient :
SELECT COUNT(*) AS count
FROM users
WHERE user_id = 'admin'; -- AND pass='********'
Tout après -- est un commentaire, donc cela ignore l'autre condition et renvoie 1 malgré tout. Et voilà, vous venez d'accorder un accès administrateur à un utilisateur malveillant. C'est ainsi que sont perpétrées de véritables attaques. Vous commencez avec un compte à faibles privilèges et à travers des failles de sécurité, vous essayez d'accéder à plus de privilèges.
Pour faire court, avoir un compte à l'échelle de l'application avec des privilèges restreints (par exemple :pas de DROP , ALTER , etc.) est bon. Ne donnez jamais à personne ou à une application plus de privilèges que nécessaire. Mais pour empêcher l'injection SQL, utilisez instructions préparées
.
