L'utilisation de bases de données non SQL évite-t-elle la nécessité de se prémunir contre «l'injection SQL»?

Question

Cela peut sembler une question évidente (ou pas si évidente), mais laissez-moi vous expliquer. Je suis en train de coder un site Google App Engine en utilisant la technologie de base de données de Google, BigTable. Les développeurs de App Engine sauront que Google a son propre langage de requête limité appelé GQL. En conséquence, je suis tenté de ne pas vérifier l'injection SQL (ou GQL) dans mon application, car je suppose que Google n'utilise pas de requête de chaîne brute sur ses méthodes d'arrière-plan pour extraire des données.

En outre, les bibliothèques pour les technologies de base de données telles que CouchDB, MongoDB et d'autres bases de données d'objet ou de document (NoSQL) semblent éviter la nécessité de vérifier si un utilisateur malveillant injecte des commandes de manipulation de base de données. Ils ont souvent des bibliothèques qui mappent directement les objets de la base de données à l’objet dans la langue de votre choix. Je sais que de nombreuses bibliothèques SQL le font également, mais je suppose qu’à un certain niveau, elles combinent des paramètres pour exécuter une requête sur une chaîne. C’est pourquoi je dois toujours utiliser la protection par injection SQL même avec ces frameworks.

Suis-je myope? Ou est-ce seulement une question de temps avant que le prochain grand système de base de données ne prenne forme et que je voie l'injection dans ces systèmes?

Answer 1

Les trous «d’injection» ont trait à des discordances de contexte de texte. Chaque fois que vous placez une chaîne de texte dans un autre contexte de chaîne, vous devez encoder pour s'adapter au contexte modifié. Il semble très simple de farcir aveuglément des chaînes ensemble, mais la difficulté de leur traitement est trompeuse.

Les bases de données avec une interface purement objet sont insensibles aux vulnérabilités d'injection, tout comme les requêtes paramétrées sont en SQL. Un attaquant ne peut rien mettre dans sa chaîne pour sortir du contexte littéral de chaîne dans lequel vous l'avez placé.

Mais GQL n’est pas l’un d’entre eux. C'est un langage de requête de chaîne, et si vous allez concaténer du matériel non fiable non échappé dans une requête comme "WHERE title = '% s'". % title , vous êtes tout aussi vulnérable qu'avec le SQL complet. Peut-être que les capacités limitées de GQL rendent plus difficile l’exploitation de celle-ci pour compromettre complètement l’application, mais ce n’est certainement pas impossible en général, et dans le meilleur des cas, votre application est toujours fausse et tombera lorsque les utilisateurs essaieront légitimement d’utiliser des apostrophes.

GQL a une interface de liaison de paramètres. Utilise le. Résistez à l'attrait du piratage de chaînes.

Answer 2

Les sous-ensembles SQL tels que GQL s'y intéressent évidemment toujours, mais les bases de données non-SQL pures telles que CouchDB, Voldemort, etc. devraient mettre & amp; obtenir des données sans se soucier des attaques de type injection SQL.

Cela ne vous dispense toutefois pas de la validation du contenu, car même si cela ne casse pas la base de données, votre application peut être cassée et permettre des choses comme XSS (s'il s'agit d'une application Web).

Answer 3

Chaque fois que des données provenant ou manipulées par une entrée utilisateur sont utilisées pour contrôler l'exécution du code, une désinfection est nécessaire. J'ai vu des cas où le code utilisait une entrée utilisateur pour exécuter une commande sans nettoyer l'entrée. Il n’a pas été exploité, mais s’il l’avait été, c’était un horrible vecteur d’attaque.

Answer 4

L'injection SQl n'est qu'un sous-ensemble d'un type de faille de sécurité dans laquelle toute entrée non contrôlée est évaluée.

sur le plan technique, vous pouvez "injecter". javascript, entre autres.