Est-il possible d'injecter du code SQL même si le caractère 'est supprimé?

Question

Si, à partir d'une requête SQL, je supprime tous les caractères, existe-t-il un autre moyen d'effectuer une attaque par injection SQL sur la base de données?

Comment cela peut-il être fait? Quelqu'un peut-il me donner des exemples?

Answer 1

Oui, il y en a. Un extrait de Wikipedia

"SELECT * FROM data WHERE id = " + a_variable + " ;;

Il ressort clairement de cette affirmation que l'auteur avait l'intention de définir une variable comme un nombre en corrélation avec le "id". champ. Cependant, s'il s'agit en fait d'une chaîne, l'utilisateur final peut manipuler l'instruction à sa guise, évitant ainsi le recours à des caractères d'échappement. Par exemple, définir a_variable sur

1; utilisateurs de DROP TABLE

supprime (supprime) les " utilisateurs " table de la base de données, car le code SQL serait rendu comme suit:

SELECT * FROM DATA WHERE id = 1; utilisateurs de DROP TABLE;

L'injection SQL n'est pas une attaque simple à combattre. Je ferais des recherches très minutieuses si j'étais vous.

Answer 2

Oui, selon l’énoncé que vous utilisez. Vous feriez mieux de vous protéger en utilisant des procédures stockées ou au moins des requêtes paramétrées.

Voir WikiPedia pour des exemples de prévention.

Answer 3

Oui, c'est définitivement possible.

Si vous avez un formulaire où vous vous attendez à ce qu'un entier fasse votre prochaine instruction SELECT, vous pouvez entrer quelque chose de similaire:

SELECT * FROM objet WHERE attributID =

• 5 (bonne réponse, pas de problème)
• 5; DROP table utilisateurs ; (mauvais, mauvais, mauvais ...)

Le site Web suivant répertorie d'autres techniques d'injection SQL classiques: aide-mémoire sur l'injection SQL .

L’utilisation de requêtes paramétrées ou de procédures stockées n’est pas meilleure. Ce ne sont que des requêtes prédéfinies utilisant les paramètres passés, qui peuvent tout aussi bien être une source d’injection. Il est également décrit sur cette page: Attaque de procédures stockées dans SQL .

Maintenant, si vous supprimez la citation simple, vous empêchez uniquement un ensemble d'attaques donné. Mais pas tous.

Comme toujours, ne faites pas confiance aux données provenant de l’extérieur. Filtrez-les à ces 3 niveaux:

• Niveau d'interface pour les choses évidentes (une liste de sélection déroulante est préférable à un champ de texte libre)
• Niveau logique pour les contrôles liés à la nature des données (int, chaîne, longueur), autorisations (ce type de données peut-il être utilisé par cet utilisateur sur cette page) ...
• Niveau d'accès à la base de données (guillemet simple d'échappement ...).

Amusez-vous et n'oubliez pas de consulter les WikiPedia

/ Vey

Answer 4

Je vous suggère de passer les variables en tant que paramètres et de ne pas créer votre propre code SQL. Sinon, il y aura toujours un moyen de faire une injection SQL, d'une manière que nous ignorons actuellement.

Le code que vous créez est alors quelque chose comme:

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

Si vous avez un nom comme le mien avec un '. Il est très gênant que tous les caractères soient supprimés ou marqués comme non valides.

Vous pouvez également consulter cette question de Stackoverflow sur les injections SQL .

Answer 5

Le SQL intégré ou les procédures stockées paramétrées constituent le meilleur moyen de vous protéger. Comme d'autres l'ont souligné, il ne suffit pas de supprimer / échapper le caractère guillemet simple.

Vous remarquerez que je parle spécifiquement de " paramétrée " procédures stockées. Le simple fait d'utiliser une procédure stockée ne suffit pas non plus si vous rétablissez la concaténation des paramètres transmis de la procédure. En d'autres termes, encapsuler exactement la même instruction SQL vulnérable dans une procédure stockée ne la rend pas plus sûre. Vous devez utiliser des paramètres dans votre procédure stockée, comme vous le feriez avec du SQL intégré.

Answer 6

Aussi, même si vous ne cherchez que l'apostrophe, vous ne voulez pas l'enlever. Vous voulez y échapper . Vous faites cela en remplaçant chaque apostrophe par deux apostrophes.

Mais les requêtes paramétrées / procédures stockées sont tellement meilleures.

Answer 7

Étant donné que cette question est relativement ancienne, je ne me ferai pas la peine de rédiger une réponse complète et exhaustive, car la plupart des aspects de cette réponse ont été mentionnés ici par un poster ou un autre.
Cependant, j'estime qu'il est nécessaire de soulever un autre problème qui n'a pas été abordé ici par personne, SQL Smuggling. Dans certaines situations, il est possible de "contrebande" le caractère de citation 'dans votre requête même si vous avez essayé de le supprimer . En fait, cela peut être possible même si vous avez utilisé les commandes, paramètres, procédures stockées, etc. appropriés.

Consultez le document de recherche complet à l'adresse http://www.comsecglobal.com/. FrameWork / Upload / SQL_Smuggling.pdf (divulgation, j’étais le chercheur principal à ce sujet) ou tout simplement Google "Smuggling SQL".

Answer 8

. . . euh environ 50000000 d'autres moyens

peut-être quelque chose comme 5; employés de la table de dépôt; -

SQL résultant peut être quelque chose comme: sélectionnez * à partir de quelque part où nombre = 5; employés de la table de dépôt; - et sadfsf

( - commence un commentaire)

Answer 9

Oui, absolument: en fonction de votre dialecte SQL, il existe de nombreuses façons de réaliser l'injection sans utiliser l'apostrophe.

La seule défense fiable contre les attaques par injection SQL consiste à utiliser le support des instructions SQL paramétré offert par votre interface de base de données.

Answer 10

Plutôt que d'essayer de déterminer les caractères à filtrer, je me contenterais plutôt de requêtes paramétrées et supprimerais totalement le problème.

Answer 11

Cela dépend de la façon dont vous avez créé la requête, mais essentiellement oui.

Par exemple, si vous deviez le faire en Java (exemple délibérément flagrant):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

alors il y a de bonnes chances que vous vous ouvriez à une attaque par injection.

Java dispose d’outils utiles, tels que PreparedStatements (où vous transmettez une chaîne du type "SELECT name_ de Client WHERE ID =?" et où la couche JDBC gère les échappements tout en remplaçant les jetons?). , mais certaines autres langues ne sont pas très utiles pour cela.

Answer 12

Il s’agit peut-être d’une véritable entrée d’apostrophe et vous devez les échapper en les doublant lorsque vous utilisez du SQL incorporé dans votre code. Ce que vous recherchez est un motif regex du type:

\;.*--\

Un point-virgule utilisé pour mettre fin prématurément à la déclaration authentique. Certains injectaient du code SQL suivi d'un double trait d'union pour commenter le code SQL de fin de la déclaration originale. Les traits d'union peuvent être omis lors de l'attaque.

La réponse est donc: Non, le simple retrait des apostrophes ne garantit pas la sécurité de l'injection SQL.

Answer 13

Je ne peux que répéter ce que d’autres ont dit. SQL paramétré est la voie à suivre. Bien sûr, il est un peu pénible de le coder - mais une fois que vous l’avez fait une fois, il n’est alors pas difficile de couper et coller ce code et d’apporter les modifications dont vous avez besoin. De nombreuses applications .Net permettent aux visiteurs de sites Web de spécifier toute une gamme de critères de recherche, et le code construit l'instruction SQL Select à la volée - mais tout ce qui aurait pu être entré par un utilisateur est défini dans un paramètre.

Answer 14

Lorsque vous attendez un paramètre numérique, vous devez toujours valider l'entrée pour vous assurer qu'elle est numérique. Au-delà de la protection contre l'injection, l'étape de validation rendra l'application plus conviviale.

Si vous recevez un jour id = " hello " lorsque vous attendez id = 1044, il est toujours préférable de renvoyer une erreur utile à l'utilisateur plutôt que de laisser la base de données renvoyer une erreur.