12
votes

Comment prévenir l'injection SQL dans l'interface Shell de la ligne de commande de MySQL?

J'utilise le script shell pour communiquer dans une base de données MySQL. MySQL prend en charge la spécification de la requête en tant qu'argument de shell, comme ceci: xxx

Cependant, si j'ai un paramètre, que je voudrais utiliser dans une requête, comment puis-je obtenir une protection contre les attaques d'injection ?

Une manière naïve consiste à simplement coller une valeur variable à la demande, mais ce n'est pas très sécurisé: xxx

y a-t-il des astuces ou des interfaces documentées à faire des requêtes par injection-sécurité de la ligne de commande?


1 commentaires

Est une application Web qui passe ces paramètres sur le script shell? Je suggère de regarder le nettoyage des données de l'application Web.


4 Réponses :


0
votes

Votre application est réceptible à une attaque d'injection SQL à tout moment, vous construisez SQL par des paramètres de concaténation (comme dans votre exemple). Il y a une écriture à ce sujet sur Wikipedia à ce lien: http://en.wikipedia.org/wiki/sql_injection

Je soupçonne que vous voudriez écrire un filtre UNIX pour construire votre requête SQL à l'aide de la fonction mysql_real_escape_string mentionnée dans l'article.

envisager de passer le SQL comme premier paramètre et la ou les variables (s) que les paramètres suivants l'ont alors renvoyer le SQL construit. Si vous nommez votre filtre "blobbo", la commande comme pour votre exemple pourrait ressembler à ceci:

blobbo "Sélectionnez ID de la table où nom =% s" $ param


0 commentaires

0
votes

Vous devez non seulement vous protéger contre l'injection SQL, mais contre l'injection de shell. Vous voudrez peut-être écrire la requête (après avoir assainir toutes les pièces dynamiques) dans un fichier, puis rediriger ce fichier dans MySQL, plutôt que d'espérer que la requête ne casse pas la coquille. Envisagez: xxx

devenir xxx

ou: xxx

plutôt

Comme: xxx

Cela empêcherait toutes les données spécifiées par l'utilisateur de comparaître dans la commande shell elle-même, empêchez au moins un niveau de vulnérabilité d'injection. Mais alors, vous devez toujours gérer le problème d'injection SQL.


1 commentaires

Merci d'avoir mentionné ce type de problème. Cependant, le code posté dans la question est protégé de l'injection de shell - s'il est exécuté par Shell lui-même. Seulement si j'invoque la commande d'un autre script (que je ne le fait pas), comme ceci: Système ("MySQL -E '$ param"); ​​ Il a ce type de vulnérabilité.



8
votes

Vous pouvez baser64 encoder la valeur, puis la base64 décode une fois qu'il est dans MySQL. Il existe des UDFS dans MySQL pour convertir les données de base64 sur des données communes. De plus, la plupart des systèmes ont une commande uuenCode ou la commande «base64» pour les données de codage de base64.


3 commentaires

Une bonne réponse, l'exemple aiderait aussi: codé = $ (écho 1 $ | base64); echo "Sélectionnez * de t Où v = de_base64 (" $ codé ");" | mysql


Je me demandais pourquoi cela fonctionne? de_base64 échappe à la sortie? Est-ce parce que le résultat de de_base64 est une chaîne binaire? Est-ce parce que la fonction est invoquée dans une phase de MySQL qui n'est plus vulnérable à l'injection SQL?


@Stefanvandenakker par base64-codant sur la chaîne, vous avez remplacé son ensemble de caractères avec le jeu de caractères de base64, qui est toutes des lettres majuscules et minuscules, chiffres, +, / et =. Étant donné que la plupart des attaques d'injection SQL s'appuient sur une mauvaise gestion de l'entrée lors de la création d'une instruction SQL, vous avez créé un moyen sûr de transmettre toute entrée dans MySQL, qui est ensuite capable d'obtenir le texte d'origine à partir de_base64, éliminant ainsi essentiellement la surface d'attaque d'injection SQL. .



0
votes

La réponse de Sargun Dhillon m'a pointé vers la bonne direction. Malheureusement, de_base64 n'est pas disponible avant MySQL 5.6, donc je suis allé avec Unfalex.

Le script ci-dessous est un exemple pour interroger les détails d'un utilisateur redmine à partir d'une coquille. Je ne dormirais toujours pas bien si les utilisateurs non approuvés avaient accès à ce script, mais il est suffisamment sûr dans mon cas. (Il est également limité aux valeurs de chaîne et vous ne devriez pas avoir de point d'interrogation dans votre requête, mais ces limitations sont bien avec moi.) xxx

Si vous découvrez n'importe quel SQL ou Injection de Shell j'ai manqué, veuillez commenter.


0 commentaires