ou Comment Protéger les Données de l’Utilisateur contre l’Injection SQL

xkcd

détails:

l’injection SQL a été autour assez bien depuis que les sites web ont des données stockées dans des bases de données.

Le projet Open Web Application Security a classé les attaques par injection parmi les 10 principales menaces auxquelles sont confrontées les applications web en 2017.,

L’injection SQL est toujours responsable de nombreuses fuites de données importantes. En 2016, les bases de données du Conseil des élections de L’État de L’Illinois et de l’Arizona ont été violées. Bien qu’aucune information n’ait été volée en Arizona, dans L’Illinois, les attaquants avaient accès aux données des électeurs, y compris le nom, l’adresse, la date de naissance, le sexe et les numéros de sécurité sociale partiels, pour environ 80 000 personnes.⁴

C’est terrifiant, Qu’est-ce que c’est?

L’injection SQL est un type d’attaque qui cible la base de données d’une application par l’insertion de code involontaire dans les champs de saisie utilisateur., En tirant parti de la syntaxe SQL, l’attaquant peut utiliser des champs de saisie pour capturer des informations à partir de ces bases de données, notamment des mots de passe et des numéros de carte de crédit. Quelqu’un pourrait même prendre le contrôle de votre base de données ou supprimer toutes les informations qu’elle détient.

Comment Ça marche?

L’Injection SQL fonctionne en utilisant des informations insérées dans un champ pour manipuler l’instruction SQL correspondante afin d’effectuer une action involontaire.,

Voici un exemple de base:

SELECT * FROM customers WHERE name = " + user_name + ";

Dans cet exemple, nous allons dire que la variable user_name est créée directement à partir de l’entrée de l’utilisateur sur un site web. Cette chaîne est insérée dans l’instruction SQL ci-dessus et tous les champs relatifs à ce nom d’utilisateur sont renvoyés. Pas une grosse affaire.

Mais que se passe – t — il si Quelqu’un tape Steve” ou 1=1; – comme nom d’utilisateur? ensuite, le SQL généré serait le suivant:

SELECT * FROM customers WHERE name = "Steve" OR 1=1;--";

puisque 1=1 est toujours vrai, cela retournerait toutes les données de la table. Pas Bon!!!,

Let’s take one more look at that comic.

xkcd

The son’s name is Robert’); DROP TABLE students; — What would that do exactly?,

Eh bien, nous pouvons supposer que si de petites tables Bobby étaient ajoutées à la base de données des étudiants de l’école, l’instruction SQL ressemblerait à:

INSERT INTO students (name) VALUES ('<Student Name>');

and et lorsque nous insérons Bobby

INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');

puisque le nom de Bobby contient le ); L’argument VALUES est fermé au milieu follows drop table students est une nouvelle instruction SQL qui supprime la table entière. Enfin, le-à la fin commente le SQL restant, ignorant essentiellement le reste du code d’origine et s’assurant qu’aucune erreur ne se produit.,

Donc, Ce Que Vous Dites Est Que Mes Données Ne Sera Jamais De Nouveau En Sécurité?

Non! Il ya effectivement beaucoup de mesures que vous pouvez prendre pour vous protéger contre ce genre d’attaque. Regardons quelques-uns:

  1. assainir les données. La première étape consiste à contrôler ce que l’utilisateur est autorisé à saisir. La meilleure façon de le faire est de limiter les types d’entrée autorisé pour un certain domaine., Par exemple, dans un champ Numéro de téléphone, vous ne pouvez autoriser que la saisie numérique ou dans un champ e-mail, autoriser uniquement les caractères qui se trouvent dans une adresse e-mail valide. Évidemment, certains champs nécessiteront des caractères qui pourraient être utilisés dans une attaque, donc cette méthode n’est pas imbattable.
  2. Configurer les Rapports d’Erreurs. Souvent, les rapports d’erreur par défaut sur les systèmes de gestion de base de données contiennent des informations de débogage de développeur. Cela peut renvoyer des informations utiles à l’attaquant, comme les noms de table ou les noms de colonne., Assurez-vous de ne pas montrer ce type d’informations à des utilisateurs externes, car cela pourrait faciliter la vie d’un attaquant potentiel.
  3. Utiliser les Paramètres Liés. Les paramètres liés vous permettent de stocker des données utilisateur dans une variable, puis de les insérer dans une instruction SQL créée avec des espaces réservés. Étant donné que L’instruction SQL et la variable sont envoyées séparément au serveur, les paramètres liés sont bons pour protéger contre l’injection. Prends ce petit Bobby t!, Un exemple de paramètres liés à une méthode de mise à jour en Ruby devrait ressembler à ceci:
def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end

C’est fou de penser que quelque chose de si simple et bien compris, c’est encore responsable de tant de grands violations de données., Même dans des cas très médiatisés comme les piratages d’inscription des électeurs mentionnés ci-dessus et la récente violation D’Equifax (qui n’était pas due à L’injection SQL, mais à une vulnérabilité similaire que la société n’a pas corrigée), la racine de la vulnérabilité se résume à une erreur humaine et à un manque d’attention aux détails. Prendre le temps de bien réfléchir au problème peut nous aider considérablement à protéger les données des utilisateurs contre les violations courantes, en particulier les injections SQL.