Sécurité webL’Injection SQL:
De Quoi S'AGIT-il?

L’injection SQL est l'un des nombreux mécanismes d'attaque des sites Web utilisé par les pirates pour voler des données provenant d'organisations privées ou gouvernementales.
C'est sans aucun doute, une attaque des plus couramment utilisée aujourd'hui. C'est le type d'attaque qui tire parti du codage inapproprié de vos applications web et permet à un pirate d'injecter des commandes SQL depuis un formulaire de connexion pour accéder aux données contenues dans votre base de données.

En substance, l'injection SQL se produit parce que certains champs restent accessibles pour permettre à un intrus d'entrer des instructions SQL pour interroger directement la base de données.

 

L'injection SQL : explication.

Les applications Web permettent aux visiteurs de site Web légitime de soumettre et de récupérer des données vers / depuis une base de données sur Internet en utilisant leur navigateur préféré.
Les bases de données sont au cœur de sites Web modernes - ils stockent les données nécessaires pour les sites et fournissent un contenu spécifique pour les visiteurs et l'information aux clients, fournisseurs, employés et une foule d'intervenants, l’identification de l'utilisateur, informations financières et les informations de paiement, des statistiques sur l’entreprise peuvent tous être présents dans une base de données et accessibles par les utilisateurs légitimes via des applications Web propriétaires.
Les applications Web de bases de données vous permettent de gérer votre entreprise au jour le jour.

SQL Injection est la technique de piratage qui tente de passer des commandes SQL (déclarations) à travers une application web pour l'exécution par la base de données back-end. Si ce n'est pas aseptisé correctement, les applications web peuvent entraîner des attaques par injection SQL qui permettent aux pirates d'afficher des informations de la base de données et / ou même l'effacer.

Des dispositifs tels que des pages de connexion, le support et les formulaires de demande de produits, formulaires dynamiques, les pages de recherche, des caddies et la livraison de contenu dynamique, façonnent les sites web modernes et offrent aux entreprises les moyens nécessaires pour communiquer avec les prospects et les clients. Ces fonctionnalités du site Web sont des exemples d'applications Web qui peuvent être soit préconçues (parfois en open source) ou développées dans des programmes faits sur mesure.

 

 

Injection SQL: Un exemple simple.

Prenez une page de connexion simple où un utilisateur légitime doit entrer son nom d'utilisateur et mot de passe pour entrer sur une zone sécurisée pour voir ses coordonnées personnelles ou de télécharger ses commentaires depuis un forum.

Lorsque l'utilisateur légitime soumet ses informations personnelles d’authetification, une requête SQL est générée à partir de ces données et soumis à la base de données pour la vérification. Si elle est valide, l'utilisateur est autorisé à accéder. En d'autres termes, l'application web qui contrôle la page de connexion afin de communiquer avec la base de données à travers une série de commandes planifiées pour vérifier le nom d'utilisateur et mot de passe associé. Après vérification, l'utilisateur légitime est autorisé à accéder au contenu approprié.

Grâce à l'injection SQL, le pirate peut spécifiquement concevoir des entrées de commandes SQL dans le but de contourner la barrière d’authentification et de connexion et de voir ce qu'il y a derrière. Cela n'est possible que si les entrées ne sont pas correctement filtrées (c.-à-dire invulnérable) et envoyées directement avec la requête SQL à la base de données. Les vulnérabilités d'injection SQL donnent les moyens à un pirate de communiquer directement avec la base de données.

Les technologies vulnérables à cette attaque sont les langages de scripts dynamiques, y compris ASP, ASP.NET, PHP, JSP, CGI. Tout attaquant doit effectuer une attaque par injection SQL se sert d’un navigateur web, et nécessite une bonne connaissance de la formation des requêtes SQL et de son langage.
La simplicité même de l'injection SQL fait toute sa popularité.

 

Autres questions à se poser :

Pourquoi est-il possible de passer des requêtes SQL à la base de données même si elle semble être dissimulée derrière notre pare-feu?

Est-ce que ma base de données risque l'injection SQL?
Quel est l'impact de l'injection SQL?

Comment puis-je empêcher les attaques par injection SQL?

Pourquoi est-il possible de passer des requêtes SQL directement à une base de données qui est caché derrière un pare-feu et tout autre mécanisme de sécurité?

 

Les pare-feux et autres mécanismes de détection d'intrusion (IDS) fournissent une défense peu ou minime selon les cas, contre les attaques de type SQL injection.

Étant donné que votre site doit être public, les mécanismes de sécurité permettant le trafic web public de communiquer avec votre application web (généralement sur le port 80/443).
L'application Web a libre accès à la base de données afin de revenir (mise à jour) de la demande (modifié) de l'information.

Lors de l’Injection SQL, le pirate utilise des requêtes SQL et sa créativité afin d’accéder à la base de données des entreprises sensibles par le biais de l'application Web.

SQL ou Structured Query Language est le langage informatique qui vous permet de stocker, manipuler et récupérer les données stockées dans une base de données relationnelle (ou une collection de tableaux qui organisent et structurer les données). Le SQL est, en fait, la seule façon qu’a une application Web (et les utilisateurs) pour interagir avec la base de données. Des exemples de bases de données relationnelles comprennent Oracle, Microsoft Access, MS SQL Server, MySQL, et Filemaker Pro, qui utilisent chacun leurs propre SQL en tant que blocs de construction de base.

Les commandes SQL SELECT comprennent les fonctions INSERT, DELETE et DROP TABLE. DROP TABLE sont aussi inquiétantes qu'il n'y paraît et, en fait, éliminent immédiatement la table portant un nom donné.

Dans le scénario légitime de l'exemple page de connexion ci-dessus, les commandes SQL prévues pour l'application Web peut ressembler à ce qui suit:

SELECT COUNT (*)
DE users_list_table
WHERE username = 'FIELD_username'
AND password = 'FIELD_PASSWORD "

En clair, cette commande SQL (à partir de l'application Web) indique la base de données pour correspondre à l'identifiant et le mot de passe entré par l'utilisateur légitime de la combinaison qu'il a déjà stockés.

Chaque type d'application Web est codé en dur avec des requêtes SQL spécifiques qu'il va exécuter pour des fonctions légitimes et pour communiquer avec la base de données. Si un champ de saisie de l'application web n'est pas correctement filtrée, un pirate peut injecter des commandes SQL supplémentaires qui élargissent la gamme de commandes SQL de l'application web va exécuter, allant ainsi au-delà de la conception initiale et la fonction prévues.

Un pirate aura donc un canal de communication en clair (ou, en termes simples, un tunnel) ouvert sur la base de données indépendamment de tous les systèmes de détection d'intrusion et des équipements de sécurité réseau installés avant que le serveur de base de données physique.

 

Est-ce que ma base de données a des risques face à l'injection SQL?

L’injection SQL est l'une des attaques les plus courantes de la couche application en cours d'utilisation sur l'Internet. Malgré le fait qu'il est relativement facile de se protéger contre les injections SQL, il existe un grand nombre d'applications web qui demeurent vulnérables.

Selon l'application Web Security Consortium (WASC) 9% du total des affaires de piratages rapportés dans les médias jusqu'au 27 Juillet 2006 étaient dues à l'injection SQL. Des données plus récentes de notre propre recherche montre qu'environ 50% des sites que nous avons analysés cette année sont susceptibles de vulnérabilités d'injection SQL.

Il peut être difficile de répondre à la question de savoir si les applications de votre site web et sont vulnérables à l'injection SQL, surtout si vous n'êtes pas un programmeur ou vous n'êtes pas la personne qui a codé vos applications web.

Notre propre expérience nous porte à croire qu'il y a de fortes chances que vos données soient déjà à risque face à une attaque d’injection SQL.

Savoir si un attaquant est capable de voir les données stockées sur la base de données, dépend vraiment de la façon dont votre site est codé afin d’afficher les résultats des requêtes envoyées. Ce qui est certain, c'est que l'attaquant sera en mesure d'exécuter des commandes SQL arbitraires sur le système vulnérable, voire de le compromettre ou encore de récupérer tout ou partie des informations.

Si votre site web est mal codé, vous courez le risque d'avoir votre base de donnée de clients de votre entreprise compromise.

Ce qui est à disposition de l’attaquant dépend aussi du niveau et de l'ensemble de la sécurité de la base de données mise en place. La base de données peut être configurée pour restreindre certaines commandes uniquement. Un accès en lecture est normalement activé pour une utilisation par une application web en back office.

Même si un attaquant n'est pas en mesure de modifier le système, il serait encore capable de lire des informations précieuses.

 

Quel est l'impact direct de l'injection SQL?

Une fois qu'un attaquant se rend compte que le système est vulnérable à l'injection SQL, il est capable d'injecter de requêtes SQL / via un champ de formulaire de saisie. Cela équivaut à offrir en cadeau à l'attaquant votre base de données en lui permettant d'exécuter n'importe quelle commande SQL DROP TABLE, sur la base de données!

Un attaquant peut exécuter des instructions SQL arbitraires sur le système vulnérable. Cela peut compromettre l'intégrité de votre base de données et / ou de compromettre des informations sensibles. Selon la base de données d'utilisation, les vulnérabilités d'injection SQL conduisent à des niveaux variables d'accès au systéme pour l'attaquant. Il peut être possible de manipuler les requêtes existantes, UNION (utilisé pour sélectionner les informations liées à partir de deux tables) avec des données arbitraires, l'usage sous-requêtes, ou ajouter des requêtes supplémentaires.

Dans certains cas, il peut être possible de lire ou d'écrire dans des fichiers ou d'exécuter des commandes systèmes sur le système d'exploitation sous-jacent. Certains serveurs SQL telles que Microsoft SQL Server incorporent des procédures (fonctions de serveur de base de données). Si un attaquant peut obtenir l'accès à ces procédures, cela pourrait être catastrophique.

Malheureusement, l'impact de l'injection SQL est seulement découvert lorsque le vol a déjà eu lieu. Les données sont involontairement volé par bidouille et diverses attaques se produisent tout le temps. Le plus expert des pirates peut rarement se faire prendre.

Exemple d'une attaque SQLInjection

Voici un exemple de formulaire HTML de base avec deux entrées, login et mot de passe.

<form method="post" action="http://testasp.vulnweb.com/login.asp">

<input type="text" name="tfUName" id="tfUName">

<input name="tfUPass" type="password" id="tfUPass">

</ Form>

Le moyen le plus facile pour le login.asp de travailler est de construire une requête de base de données qui ressemble à ceci:

SELECT id
DE connexions
WHERE username = '$ username'
AND password = '$ password'

Si les variables $ nom d'utilisateur et mot de passe $ est demandé directement lors de l'entrée de l'utilisateur, cela peut facilement être compromis. Supposons que nous avons donné "Joe" comme nom d'utilisateur et que la chaîne suivante a été fournie comme mot de passe: nul 'ou' x '=' x

SELECT id
DE connexions
WHERE username = 'Joe'
AND password = 'rien' ou 'x' = 'x'

Comme les entrées de l'application web ne sont pas correctement filtrées, l'utilisation des guillemets simples a détourné la commande SQL WHERE dans une clause bi-composant.

Le 'x' = 'x' partie garant pour être vraiment indépendamment de ce que la première partie du code.

Cela permettra à l'attaquant de contourner le formulaire de connexion sans connaître vraiment un nom d'utilisateur valide / mot de passe!

 

Comment puis-je empêcher les attaques par injection SQL?

Les pare-feu et les mécanismes similaires de détection d'intrusion fournissent une défense minime contre les attaques web à grande échelle. Étant donné que votre site doit être public, les mécanismes de sécurité permettant le trafic web public de communiquer avec vos serveurs de bases de données par le biais des applications Web. N'est-ce pas ce qu'ils ont été conçus pour faire?

Patcher les serveurs, les CMS, les bases de données, les langages de programmation et les systèmes d'exploitation reste une tâche urgente et essentielle, mais ne servira en aucun cas comme moyen de prévenir les attaques par injection SQL.