Comment faire l'injection SQL sur Oracle

Question

Je fais un audit d'un système, que les développeurs insistent sur la preuve d'injection SQL. Ce qu'ils réalisent en supprimant les guillemets simples dans le formulaire de connexion - mais le code derrière n'est pas paramétré; il utilise toujours le langage littéral SQL comme suit:

username = username.Replace("'", ""); 
var sql = "select * from user where username = '" + username + "'"; 

Est-ce vraiment sécurisé? Y a-t-il une autre façon d'insérer une seule citation, peut-être en utilisant un caractère d'échappement? La base de données utilisée est Oracle 10g.

Answer 1

Jetez un oeil au guide de test ici: http://www.owasp.org/index.php/Main_Page Cela devrait vous donner des scénarios de test plus sournoises, peut-être assez pour demander une réévaluation de la stratégie de codage SQL :-)

Answer 2

Donc, personne ne peut avoir un nom comme O'Brian dans leur système?

Le chèque de devis unique ne sera pas utile si le paramètre est numérique - alors 1; DROP TABLE user;-- causerait des ennuis =)

Je me demande comment ils traitent les dates ...

Si le mécanisme d'exécution des requêtes a intelligent comme PHP, et les requêtes limitées à seulement jamais exécuter une requête, alors il ne devrait pas y avoir de problème avec les attaques par injection ...

Answer 3

Peut-être que vous pouvez aussi échouer parce que ne pas utiliser les variables de liaison aura un impact très négatif sur performance.

Answer 4

Quelques conseils:
1- Il n'est pas nécessairement le caractère qui peut être utilisé comme une citation. Essayez ceci:

select q'#Oracle's quote operator#' from dual; 

2- Une autre astuce du « Code Innocent » livre dit: Ne massez pas entrée non valide pour la rendre valide (en échappant ou la suppression). Lisez la section pertinente du livre pour des exemples très intéressants. Résumé des règles sont here.

Answer 5

Non, ce n'est pas sécurisé. L'injection SQL ne nécessite pas de caractère guillemet simple pour réussir. Vous pouvez utiliser AND, OR, JOIN, etc pour y arriver. Par exemple, supposons qu'une application Web possède une URL comme celle-ci: http://www.example.com/news.php?id=100.

Vous pouvez faire beaucoup de choses si le paramètre ID n'est pas correctement validé. Par exemple, si son type n'est pas coché, vous pouvez simplement utiliser ceci: ?id=100 AND INSERT INTO NEWS (id, ...) VALUES (...). La même chose est valable pour JOIN, etc. Je n'enseignerai pas comment l'explorer parce que tous les lecteurs n'ont pas de bonnes intentions comme vous semblez l'avoir. Donc, pour ceux qui prévoient d'utiliser un simple REPLACE, sachez que cela NE préviendra PAS une attaque.

Answer 6

Quelle est la langue du client? Autrement dit, nous devons nous assurer exactement du type de données du nom d'utilisateur et de la méthode Replace en ce qui concerne ce type de données. Aussi comment la concaténation fonctionne pour ce type de données. Il peut y avoir une traduction de jeu de caractères qui traduirait un caractère semblable à un guillemet en UTF-8 en une citation "régulière".

Pour l'exemple très simple, vous montrez que cela devrait marcher, mais les performances seront terribles (selon le commentaire de Thilo). Vous auriez besoin de regarder les options pour CURSOR_SHARING

Pour ce SQL

select * from user where username = '[blah]' 

Tant que [bla] ne comprend pas une seule citation, il doit être interprété comme valeur unique CHAR.Si la chaîne contenait plus de 4000 octets, cela provoquerait une erreur et je serais intéressé de voir comment cela a été géré. De même une chaîne vide ou une chaîne composée uniquement de guillemets simples. Les caractères de contrôle (fin de fichier, par exemple) peuvent également poser des problèmes, mais cela peut dépendre de la possibilité de les saisir au début.

Pour un nom d'utilisateur, il serait légitime de limiter le jeu de caractères aux caractères alphanumériques, et éventuellement à un ensemble limité de ponctuation (point et soulignement peut-être). Donc, si vous adoptez une approche de filtrage de caractères, je préférerais une liste blanche de caractères acceptables plutôt que la mise en liste noire de guillemets simples, de caractères de contrôle, etc.

En résumé, en général, la sécurité est faible et les impacts sont négatifs. performance. Dans des cas particuliers, cela pourrait (probablement?) Ne pas exposer de vulnérabilités. Mais vous voudrez faire beaucoup de tests pour être sûr que ce n'est pas le cas.