Faille SQL Magento : Comment sécuriser votre magasin Magento contre les attaques par injection SQL

Magento est très populaire dans le monde des affaires. Cela peut être dû à ses origines open-source. Le but premier de Magento était de faciliter le processus de gestion et de création d’un magasin. Étant open-source, il utilise MySql ou MariaDB pour le stockage et la gestion des données. Cette base de données joue un rôle essentiel dans la gestion du magasin Magento. Cela signifie également que le ciblage de la base de données Magento par des attaques par injection SQL est assez courant. Une faille SQL Magento est le résultat d’une entrée utilisateur non assainie. Il s’agit d’une menace importante qui pèse sur les magasins. Un seul codage bâclé peut exposer toute la base de données.

Outre les attaques par injection SQL, Magento est également en proie à l’escroquerie au vol de cartes de crédit, au Cryptojacking, au spam SEO et à d’autres cyber-menaces. Toutefois, dans cet article, nous nous concentrerons sur les attaques par faille SQL Magento et sur la manière dont vous pouvez les empêcher de se produire dans votre magasin.

Suivez les liens ci-dessous si vous cherchez

• Déménagement de Magento Hack
• Guide de sécurité Magento (pour une sécurité à toute épreuve contre XSS, SQLi, le piratage des cartes de crédit, le piratage administratif)

Que peut faire une faille SQL Magento ?

La base de données est l’un des éléments les plus sensibles de votre magasin. La première SQLi a été signalée en 1998. Pourtant, SQLi figure toujours dans la liste des 10 principales vulnérabilités de l’OWASP. Il y a donc une bonne raison de s’en méfier. Une faille SQL Magento peut :

• Lire le contenu d’une base de données.
• Manipuler la base de données. Cela peut modifier le contenu du magasin.
• Supprimer toute la base de données.
• Voler les détails d’une carte de crédit.
• Exposer les informations d’identification de l’administrateur. Cela pourrait ouvrir la voie à d’autres attaques.
• Obtenir un shell inversé dans certains cas. Cela peut aussi entraîner une escalade des privilèges

Des méthodes avancées pour exploiter une faille SQL de Magento sont trouvées chaque année. De nouvelles astuces pour contourner les filtres et les audits de sécurité Magento sont développées chaque mois. Ainsi, la menace d’une attaque par faille SQL Magento augmente de jour en jour. Il existe bien d’autres méthodes pour éviter une faille SQL de Magento.

Votre magasin montre les signes d’une attaque par faille SQL Magento ? Envoyez-nous un message sur le widget de chat et nous serons heureux de vous aider. Sécurisez mon site web Magento maintenant.

Les causes d’une faille SQL de Magento

1) Mise en œuvre du code côté client

Souvent, les développeurs ne prêtent pas attention aux pratiques de codage sécurisé. Par conséquent, une partie du code est exécutée côté client. Comme elle est exécutée sur l’appareil du client, cela peut être modifié par ce dernier et avoir pour conséquence de contourner la validation des entrées. En termes simples, l’attaquant peut passer votre contrôle de sécurité simplement parce que vous l’avez nommé responsable. Demandez à votre développeur d’exécuter les fonctions sensibles du côté serveur pour empêcher les failles SQL Magento.

2) Entrée non analysée

Souvent, les données reçues de l’utilisateur ne sont pas correctement aseptisées. Chaque fois qu’une requête est faite au serveur, une nouvelle requête est générée en utilisant l’entrée donnée. C’est ce qu’on appelle les requêtes dynamiques. Voyons pourquoi elles sont dangereuses. Par exemple, regardez la requête suivante :

txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " ' + txtUserId ' ";

Ce morceau de code demande l’UserId et le soumet ensuite à la requête SQL. Tout semble très bien se passer, mais qu’est-ce qui peut mal tourner ? Voyons voir. Un attaquant peut fournir une entrée telle que 105′ ; DROP TABLE Users. L’agresseur a donc très clairement empilé une déclaration sur l’autre. Ainsi, la deuxième requête sera exécutée après la première. La dernière requête qui sera exécutée sera donc

SELECT * FROM Users WHERE UserId = 105; DROP TABLE Users;

De cette façon, l’attaquant peut modifier le contenu de la base de données. Il est donc préférable d’éviter les requêtes dynamiques. Cependant, ne vous inquiétez pas. Il existe une alternative à ces requêtes dynamiques. C’est ce qu’on appelle des instructions préparées qui aident à empêcher les failles SQL Magento.

3) Tautologies

Premièrement, ce type d’attaque utilise des déclarations qui évaluent la vérité. Elle permet ensuite de contourner les restrictions de connexion. De mauvaises pratiques de codage peuvent entraîner le contournement des restrictions. Par exemple, regardez le code source d’une page de connexion présenté ci-dessous :

<?php

$_POST['username'] = '';

$_POST['password'] = '';

$query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND
password='{$_POST['password']}'";

mysql_query($query);

echo$query;

?>

Il se contente de saisir les données des champs d’utilisateur et de mot de passe. Il les évalue ensuite par rapport à une requête SQL. Maintenant, si l’attaquant devait fournir une entrée en tant qu admin’ or 1=1–, l’instruction SQL exécutée serait donc

SELECT * FROM users WHERE user= 'admin' AND password='' OR 1=1--

Notez les symboles — assurez-vous que toutes les autres déclarations qui suivent sont traitées comme des commentaires. En fait, l’attaquant a contourné la page de connexion et est maintenant l’administrateur. De plus, il existe de multiples variantes de ‘ or 1=1– . Il y a une liste complète de ces paramètres. Un mauvais codage peut rendre vos pages de connexion vulnérables à une attaque par faille SQL Magento.

4) Messages d’erreur

Les messages d’erreur peuvent révéler de nombreux détails concernant votre système. Certains d’entre eux peuvent révéler les colonnes et la version de la base de données. Par exemple, regardez l’image ci-dessous :

Ce message révèle ici la base de données et les colonnes. Ainsi, il y a différents messages pour différentes bases de données. Magento fonctionne sur My SQL, donc cela pourrait ressembler à ceci. Ces messages peuvent aider les attaquants à mener une attaque par injection SQL de Magento. Les erreurs de désactivation peuvent aider à empêcher les failles SQL de Magento. Cependant, si les messages d’erreur sont désactivés, la possibilité d’une SQLi aveugle est toujours présente. Cependant, il est préférable de désactiver les messages d’erreur pour les utilisateurs.

5) Privilèges des bases de données

Des autorisations incorrectes peuvent alimenter les attaques par faille SQL de Magento. Une fois que la base de données est compromise, l’attaquant obtient des privilèges d’administrateur. Cela se produit parce que l’instance de la base de données fonctionnait en tant qu’administrateur. L’attaquant peut donc manipuler le contenu comme il le souhaite. En l’absence de privilèges d’administrateur, l’attaquant ne peut que lire le contenu. Ainsi, les privilèges de la base de données peuvent arrêter les commandes SQL comme Update, Insert, etc. Ainsi, il est sûr de mettre DBA sur False.

6) Le cryptage

Si les valeurs des tableaux sensibles ne sont pas cryptées, cela ajoute de l’huile sur le feu. Ainsi, le stockage des mots de passe en texte clair est une grosse erreur. Assurez-vous que le cryptage est réglé sur True pour votre base de données. Cela peut servir à limiter les dégâts en cas d’attaque par faille SQL Magento.

7) Filtrage à taille variable

S’il n’y a pas de limite à la taille des variables, l’utilisateur peut fournir une longue entrée. Il s’agit généralement d’une entrée malveillante contenant des instructions SQL. Ainsi, si une limite est appliquée sur la taille des variables, cela peut empêcher une faille SQL de Magento et permettre d’éviter les attaques par faille SQL de Magento.

Vous avez besoin d’une aide professionnelle pour sécuriser un Magento Store ? Envoyez-nous un message sur le widget de chat et nous serons heureux de vous aider. Protégez mon site web Magento maintenant.

Audit de sécurité Magento après injection SQL

1) Détection de la vulnérabilité des injections SQL

La meilleure façon de commencer à chercher une faille SQL Magento est de vérifier les logs. Regardez l’image ci-dessous et voyez si votre journal montre quelque chose comme ceci ?

Si la réponse est oui, cela signifie qu’un outil SQLi automatisé a été utilisé. Les journaux du serveur affichent les différentes instructions SQL utilisées. Vérifiez immédiatement les journaux de la base de données pour déterminer les changements qui ont eu lieu. Vérifiez également si de nouveaux utilisateurs sont apparus.

Désactivez temporairement les pages concernées jusqu’à ce que le code soit trié. Assurez-vous également que l’instance de la base de données ne fonctionne pas en tant qu’administrateur sur le serveur. Cela limiterait la capacité d’un attaquant qui ne pourrait que lire. A partir de là, procédez à l’audit de sécurité de Magento.

2) Contrôle des utilisateurs

Une approche heuristique peut être prise en utilisant la commande show tables ;. S’il existe des tables comme Sqlmap, il est fort probable qu’un outil automatisé ait été lancé sur le site web. L’étape suivante consiste à rechercher de nouveaux utilisateurs. Utilisez la commande suivante :

Select * from users  as u
AND u.created > UNIX_TIMESTAMP(STR_TO_DATE('Oct 15 2018', '%M %d %Y '));

Cette déclaration SQL affiche les utilisateurs créés après le 15 octobre. La chaîne de date peut être manipulée pour remonter dans le temps. Les bases de données malveillantes peuvent être supprimées à l’aide de l’instruction SQL suivante :

drop database database-name.dbo;

3) Blocage des utilisateurs

Après la détection des utilisateurs malhonnêtes, il est temps de les bloquer. L’instruction SQL suivante fait donc l’affaire :

update users set pass = concat('ZZZ', sha(concat(pass, md5(rand()))));

La déclaration suivante met à jour les utilisateurs de la table et fixe un nouveau mot de passe. En outre, le mot de passe est défini dans un format crypté. Ainsi, l’attaquant devrait recourir à la force brute et à d’autres techniques connues pour obtenir du texte en clair.

4) Restauration de la base de données

Parfois, l’attaquant peut avoir supprimé la base de données. Dans ce cas, elle peut être restaurée à partir de la sauvegarde. Il suffit d’exécuter le client dans la ligne de commande My SQL. Connectez-vous en utilisant la commande suivante.

mysql -u root -p 'your password'

Ensuite, exécutez les instructions SQL suivantes :

create database new_db;
use new_db;
\. backupfile.sql

La base de données sera ainsi restaurée. Ce qui permet de contrôler les dommages causés par le piratage par faille SQL Magento. Cependant, le magasin a encore besoin d’un audit de sécurité complet de Magento.

Exemple d’attaque par injection SQL à Magento

example.com/?___from_store=en' union select 0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526 -```

Les paramètres URL _ store and _from_store sont utilisés dans les installations de Magento Multistore pour passer d’une version à l’autre du magasin et d’une langue à l’autre. Les pirates attaquent généralement ce paramètre par des requêtes d’injection SQL.

C’est un comportement typique des outils de sécurité automatisés tels que Sqlmap et Acunetix. Si l’outil soupçonne qu’une “injection de syndication” est possible, il essaiera d’abord de déterminer le nombre de champs dont il a besoin dans la requête de syndication, et verra également quels champs finissent par se refléter à la sortie. Le fait d’avoir une requête unique comme celle-ci permet de tester les deux et de contourner certains systèmes de sécurité où il n’est pas possible de se référer à des index de champs dans la requête.

Comment prévenir l’attaque par faille SQL Magento

1) Paramètres de protection

Chaque base de données est assortie de paramètres de protection spécifiques. Ceux-ci permettent d’éviter les attaques par faille SQL Magento. Regardez par exemple ce code :

txtUser = getRequestString("User"); txtPass = getRequestString("Password"); txtOTP = getRequestString("OTP"); txtSQL = "INSERT INTO Login (User,Password,OTP Values(@0,@1,@2)"; db.Execute(txtSQL,txtUser,txtPass,txtOTP);

$stmt = $dbh->prepare("INSERT INTO Login (User,Password,OTP)  VALUES (:usr, :pass, :otp)"); $stmt->bindParam(':usr', $txtUser); $stmt->bindParam(':pass', $txtPass); $stmt->bindParam(':otp', $txtOtp); $stmt->execute();

2) Utiliser les déclarations préparées

Les déclarations préparées constituent l’autre option aux requêtes dynamiques. Il s’agit de déclarations qui sont préparées et analysées ultérieurement. Ainsi, la base de données stocke la déclaration sans l’exécuter. Elle en vérifie d’abord les paramètres. Ensuite, elle s’assure qu’une chaîne de caractères saisie n’est qu’une chaîne de caractères, et ainsi de suite. Cela permet de s’assurer que l’entrée n’est pas malveillante. Une fois que tous les paramètres sont vérifiés, elle exécute les déclarations. Ainsi, vous vous assurez qu’aucune attaque par faille SQL Magento n’est en cours. Vous trouverez ci-dessous une implémentation préparée des instructions dans My SQL et PHP.

Comme nous pouvons le voir ici, certaines valeurs sont remplacées par des ” ? Ainsi, un type de données spécifique remplacera la valeur ici. Il peut s’agir d’un nombre entier, d’une chaîne de caractères, d’un blob, etc. Magento utilise le framework Zend. Dans ce cas, les composants du framework Zend peuvent être utilisés. Liez les paramètres de la requête avec le bind de Zend_Db_Select plutôt que d’utiliser une instruction SQL complète. Comme ceci :

$query = $this->_connection->select()->from('eav_attribute')->where('attribute_id=?', $attributeId); $result = $this->_connection->fetchAll($query);

3) Limiter les privilèges

Assurez-vous que les colonnes sensibles sont cryptées. Ainsi, même si la base de données est compromise, l’attaquant doit forcer le mot de passe. Veillez également à ce que les mots de passe utilisés soient solides. De plus, limitez le rôle de la base de données. Interdisez les déclarations telles que Update, Drop, etc.

4) Utiliser un pare-feu d’application Web

L’inspection manuelle du code pour déterminer une attaque par faille SQL Magento est fastidieuse. Il faut donc engager des experts pour cela. Utilisez également un pare-feu afin qu’aucune commande de ce type ne puisse passer à travers ses filtres. Astra dispose d’un excellent pare-feu et d’une solution de sécurité conçue pour empêcher une attaque par faille SQL Magento. L’audit de sécurité de Magento peut vous faire gagner du temps et des ressources précieuses à l’avenir !

Share this...

Facebook

Pinterest

Twitter

Linkedin