L’attaque par injection SQL

En particulier, la sécurité objet (au niveau des possibilités) de l’ IBM i et le stockage à un seul niveau vous offrent un excellente maîtrise des ressources permettant de contrôler strictement l’accès à l’intérieur de la machine.

Les contrôles des ressources au niveau objet, comme l’adoption d’autorité, les profils de groupes, l’autorité privée, et les contrôles au niveau schéma, assurent tous une excellente protection des données. Mais tout cet arsenal ne peut rien contre la faille la plus courante : la référence utilisateur compromise.

L’intrusion constatée le plus fréquemment ne provient pas d’une attaque contre le système d’exploitation sous-jacent, mais plutôt d’un usurpateur qui s’empare des références d’un utilisateur autorisé puis s’en sert pour piocher dans la base de données par des moyens classiques tels que des requêtes SQL. Le plus réputé de ces « exploits », l’attaque par injection SQL, se fonde sur des applications web qui fournissent une interface graphique pour la saisie utilisateur puis génèrent des instructions SQL destinées à interroger ou à mettre à jour la base de données.

Une application mal codée suffit à un usurpateur pour insérer des instructions SQL dans des variables d’entrée non-SQL, comme un champ nom ou adresse sur un formulaire. En combinant des attaques par injection SQL avec du script multisite, un usurpateur peut s’introduire dans la session web authentifiée d’un utilisateur, via un site web tiers. Des montagnes de données précieuses sont ainsi à la disposition des pirates.

Seule la sécurité au niveau table peut protéger contre ce genre de méfait. Sans elle, un usurpateur peut effectuer toute opération sur une base de données, comme extraire tous les enregistrements avec une instruction SELECT, ou plus grave encore, supprimer ou mettre à jour des enregistrements. Les attaques par injection SQL ne laissent pratiquement aucune preuve, sauf si l’assaillant modifie ou détruit de données. Il se peut même que l’application compromise ne tourne pas sur le système contenant la base de données. Il est fréquent d’héberger des applications web sur de multiples serveurs qui accèdent à une base de données centrale via ODBC ou quelque autre protocole de requêtes de base de données à distance. Sans la sécurité au niveau table, un intrus peut rapidement faire main basse sur des enregistrements de grande valeur, sans laisser de trace.

La protection au niveau table présente deux variantes : des restrictions au niveau colonne et au niveau ligne qui limitent les champs de base de données auxquels un certain utilisateur peut accéder en toute circonstance, et un cryptage en colonne garantissant que seuls les utilisateurs autorisés effectuant des opérations autorisées peuvent accéder aux données. Le premier contrôle est simple à mettre en oeuvre et s’adapte facilement aux applications existantes, y compris l’accès aux applications natives non-SQL. Le second demande beaucoup d’attention dans les détails et n’est pas facile à appliquer à des applications existantes, mais il offre la meilleure protection de données extrêmement sensibles : numéros de sécurité sociale, de cartes de crédit, etc.