Archive pour la catégorie 'Base de données'

08-24-2008

Attaque web par injection SQL

L’attaque web par injection SQL est réalisée par des experts mettant en relation, d’une manière astucieuse, les entrées utilisateurs et le langage qui parle à la base de données.
Grossièrement, ce qui se produit est soit (1) l’insertion de commandes pour la base de données ou encore (2) la transformation des paramètres de manière à faire appliquer des commandes sur des données non-autorisées.

L’insertion arbitraire de commandes

Ce type d’injection SQL implique qu’il existe des caractères spéciaux capables d’interrompre une commande SQL existante et d’en débuter une nouvelle dictée par l’attaquant. Cette attaque est de loin la pls dangereuse car elle s’exécutera avec les privilèges de l’usager de la base de données et non avec les privilèges de l’usager du site.
La plupart des applications web ne déclinent pas leurs base d’usagers en différentes connections à la base avec différents privilèges. NON. C’est l’application qui gèrent les droits des utilisateurs et l’application se connecte ensuite à la base de données avec un super-utilisateurs qui a tous les droits, et gare à la requête qui serait vicieusement et secrètement transformée par un attaquant.

Le type de caractère spécial capable de provoquer un arrêt de la requête SQL est le ‘;’. Heureusement, la plupart des bases sont prémunies contre cela puisqu’elles n’autorisent qu’une seule commande à la fois et c’est la première qui prévaut. Enfin, certaines applications exécutent des prétraitement sur les variables afin de les filtrer de tout caractères spéciaux ou encore afin de les encoder.

Ce type d’attaque devient de plus en plus difficile à réaliser mais quelques perches subsistent en la nature de transformations mal aiguillées par l’application, qui pourrait par exemple faire l’erreur de laisser passer la requête injectée plutôt que la requête initiale. À cet effet, les requêtes préparées à l’avance (prepared statement) apportent un niveau de sécurité supplémentaire en plus de l’optimisation apportée. Celles-ci, couplées à un engin de traitement automatique des variables injectées dans les requêtes permet d’apporter une sécurisation indépendantes des opérations de programmation opérées lors de la réception des variables.

Cependant, une grande communauté de programmeurs préfèrent opérer la filtration dès la réception des variables afin d’éviter les autres inconvénients possibles de l’injection de données.

Un bon programme de test de l’application devrait donc contenir non-seulement des injections aléatoires de données mais aussi des injections systématiques des caractères dangereux pour en vérifier l’effet réel.

Le détournement de requête par transformation des paramètres

Imaginons des données privilégiées qui sont mélangées à des données publiques dans la base de données ou encore les données personnelles de chacun qui sont contenues dans la même table.

Comme dans un appel de page web dynamique, dans la base de données il ne suffit que d’un paramètre pour modifier l’essence d’une requête. Par exemple:

On désire obtenir toutes les information concernant Louise. Mais que se passe-t-il si on envoie le numéro de Jean même si on est authentifiée en tant que Louise ?
On désire faire afficher une sélection de données selon des paramètres. Mais que se passe-t-il si on envoie le symbole de sélection universelle du SQL qui n’est pas l’étoile ‘*’ mais le pourcentage ‘%’
On désire effacer une de nos fiches d’informations, mais que se passe-t-il si on modifie le formulaire et que l’on inscrit le paramètre universel à la place du numéro d’identification de notre fiche d’information ? Effacera-t-on toutes les fiches ?

La réponse à ces questions dépend de l’action coordonnées de l’architecture, de la programmation et de la formulation des requêtes SQL. Une vision d’ensemble est nécessaire et c’est pourquoi la construction des applications web doit être coordonnées et dirigées par un spécialiste du métier. Des connaissances en gestion sont bien insuffisantes car la construction d’applications web n’est pas symétrique à la construction de maisons.

Voici quelques trucs qui permettent dans certaines situations d’éviter les détournements de requêtes

Afin de rendre impossible la généralisation d’une opération d’effacement ou de mise à jour, il est pertinent dans le SQL d’utiliser la condition = plutôt que la condition LIKE.
Il faut réserver la condition LIKE à des recherches s’opérant dans des données déjà toutes restreintes publiques
Afin d’éviter le détournement d’une opération de sélection, mise à jour ou effacement de données individuelles, il faut que le compte restreint génère les paramètres de conditions à partir de l’authentification revalidée.
L’empêchement de la généralisation des opérations de recherches publiques paramétrées paraît ici moins critique en regard de la protection de l’information. Cependant, pour qui est intéressé a en limiter l’usage, il suffit d’encapsuler le caractère spécial % afin de le transformer en donnée normale (par une ‘escape’). Comme les utilisateurs désireux d’utiliser le wildcard prendront sans hésiter le symbole *, il suffit de travailler sur celui afin de le rendre disponible en complément des données existantes et d’empêcher son utilisation seule.

Dans un prochain article, je ferai un essai de procédure systématique et de tableau résumé afin d’obtenir les résultats escomptés sans limiter indûment le pouvoir de l’utilisateur.

Voici un lien complémentaire en attendant ce tableau, qui résume les attaques possibles sous forme d’une “cheat sheet”

Posté par Nadine St-Amand pour Les formations Accent Net dans Sécurité, Base de données | Comments Off

Journal du web

La transition web… sémantique, accessible & ergonomique

Archive pour la catégorie 'Base de données'

08-24-2008

Attaque web par injection SQL

L’insertion arbitraire de commandes

Le détournement de requête par transformation des paramètres

Pages

Archives

Catégories

Liens

Meta