INJECTION SQL TEST ET PREVENTION
Une injection SQL se compose d' une insertion ou d'une "injection" soit d'une requête partielle ou
totale par l'entrée de données SQL ou transmis par le client ( le navigateur) pour l'application web.
Une SQL attaque par injection réussie peut lire les données sensibles de la base de données,
modifier les données de base de données (insertion / mise à jour / supprimer), exécuter des
opérations d'administration sur la base de données (comme l'arrêt du SGBD), récupérer le contenu
d'un fichier donné existant sur le fichier de SGBD système ou écrire des fichiers dans le système de
fichiers, et, dans certains cas, émettre des commandes au système d'exploitation. Les attaques par
injection SQL sont un type d' attaque par injection , dans lequel les commandes SQL sont injectées
dans des données d' entrée-plan afin d'affecter l'exécution de commandes SQL prédéfinies.
En général, les applications Web veillent de façon à construire des instructions SQL impliquant la
syntaxe SQL écrit par les programmeurs
Exemple:
select title, text news where id = $id
Dans l'exemple ci-dessus la variable $id contient des données fournies par l'utilisateur, tandis que
le reste est la partie statique de SQL fourni par le programmeur; rendant l'instruction SQL
dynamique.
Parce que la façon dont il a été construit, l'utilisateur peut fournir une entrée conçu en essayant de
faire de l'instruction SQL originale exécuter d'autres actions au choix de l'utilisateur. L'exemple ci-
dessous illustre les données fournies par l'utilisateur "10 ou 1 = 1", en changeant la logique de
l'instruction SQL, la modification de la clause WHERE ajoutant une condition "ou 1 = 1".
select title, text news where id = 10 or 1 = 1
Les attaques par injection SQL peuvent être divisés en trois classes suivantes:
Intrabande: les données sont extraites en utilisant le même canal qui est utilisé pour injecter le code
SQL. Ceci est le type le plus simple d'attaque, dans lequel les données extraites sont présentées
directement dans la page application web.
Out-of-band: les données sont récupérées en utilisant un canal différent (par exemple, un e-mail
avec les résultats de la requête est généré et envoyé au testeur).
Déductive ou aveugles: il n'y a pas de transfert réel de données, mais le testeur est en mesure de
reconstituer les informations en envoyant des demandes particulières et en observant le
comportement résultant du serveur DB.
Une attaque par injection SQL réussie nécessite à l'attaquant de concevoir une requête SQL
syntaxiquement correcte. Si l'application renvoie un message d'erreur généré par une requête
incorrecte, il peut être plus facile pour un attaquant de reconstituer la logique de la requête initiale
et, par conséquent, de comprendre comment effectuer l'injection correctement. Toutefois, si
l'application cache les détails de l'erreur, le testeur doit être capable de désosser la logique de la
requête initiale.
A propos des techniques pour exploiter des failles d'injection de SQL, il y a cinq techniques
commons. Aussi ces techniques peuvent parfois être utilisés de manière combinée (opérateur, par
exemple de l'union et out-of-band):
Union Operator: peut être utilisé lorsque la faille d'injection SQL se produit dans une instruction
SELECT, qui permet de combiner deux requêtes en un seul résultat ou un résultat défini.
Boolean: utiliser la condition (s) booléenne pour vérifier si certaines conditions sont vraies ou
fausses.
Erreur sur la base: cette technique oblige la base de données pour générer une erreur, ce qui donne
à l'attaquant des informations sur lequel il peut affiner leur injection.
Out-of-band: technique utilisée pour récupérer les données en utilisant un canal différent (par
exemple, établir une connexion HTTP pour envoyer les résultats à un serveur Web).
Temps de retard: les commandes de base de données d'utilisation (par exemple le sommeil) pour
retarder les réponses dans les requêtes conditionnelles. Il est utile lorsque l'attaquant n'a pas une
sorte de réponse (résultat, sortie ou erreur) de l'application.
Comment tester
Techniques de détection
La première étape de ce test est de comprendre lorsque l'application interagit avec un serveur DB
afin d'accéder à certaines données. Des exemples typiques de cas où une application a besoin de
parler à un DB comprennent:
formes d'authentification: lorsque l'authentification est effectuée en utilisant un formulaire web, les
chances sont que les informations d'identification de utilisateur sont vérifiées par rapport à une
base de données qui contient tous les noms d'utilisateur et mots de passe (ou, mieux, mot de passe
hashes).
Les moteurs de recherche: la chaîne présentée par l'utilisateur peuvent être utilisées dans une
requête SQL qui extrait tous les documents pertinents à partir d'une base de données.
les sites E-Commerce: les produits et leurs caractéristiques (prix, description, disponibilité, etc.)
sont très susceptibles d'être stockées dans une base de données.
Le testeur doit faire une liste de tous les champs d'entrée dont les valeurs pourraient être utilisées
dans l'élaboration d'une requête SQL, y compris les champs cachés de requêtes POST, puis les tester
séparément, en essayant d'interférer avec la requête et de générer une erreur. Considérez aussi en-
têtes HTTP et les cookies.
Le premier test consiste habituellement en ajoutant une seule apostrophe ( ') ou un point-virgule (;)
au champ ou un paramètre en cours de test. La première est utilisée dans SQL comme un
terminateur de chaîne et, si non filtrée par l'application, cela conduirait à une requête incorrecte. La
seconde est utilisée pour mettre fin à une instruction SQL et, si elle n'a pas été filtré, il est également
susceptible de générer une erreur. La sortie d'un champ vulnérable pourrait ressembler à ce qui
suit (sur un Microsoft SQL Server, dans ce cas):
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113
commenter également délimiteurs (- ou / * * /, etc.) d'autres mots-clés SQL comme «ET» et «OU»
peut être utilisé pour essayer de modifier la requête et. Une technique très simple mais parfois
encore efficace consiste simplement à insérer une chaîne où il est prévu un certain nombre, comme
une erreur comme celle-ci peut être générée:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113
Surveiller toutes les réponses du serveur Web et jeter un oeil à la / code source javascript HTML.
Parfois, l'erreur est présente en eux, mais pour une raison quelconque (par exemple une erreur
javascript, les commentaires HTML, etc) ne sont pas présentées à l'utilisateur. Un message d'erreur
complet, comme ceux dans les exemples, fournit une mine d'informations sur le testeur afin de
monter une attaque par injection réussie. Toutefois, les applications ne fournissent pas autant de
détails: un simple «500 Server Error» ou une page d'erreur personnalisée peut être émis, ce qui
signifie que nous avons besoin d'utiliser des techniques d'injection aveugles. Dans tous les cas, il est
très important de tester chaque champ séparément: une seule variable doit varier alors que tous les
autres restent constants, afin de comprendre précisément quels paramètres sont vulnérables et qui
ne sont pas.
SQL standard Injection Test
Exemple 1 (Injection SQL classique):
Considérons la requête SQL suivante:
SELECT * FROM Users WHERE Username='$username' AND Password='$password'
Une requête similaire est généralement utilisé à partir de l'application Web afin d'authentifier un
utilisateur. Si la requête renvoie une valeur, cela signifie que l'intérieur de la base de données d'un
utilisateur avec ce jeu d'informations existe, l'utilisateur est autorisé à se connecter au système,
sinon l'accès est refusé. Les valeurs des champs d'entrée sont généralement obtenus à partir de
l'utilisateur par le biais d'un formulaire Web. Supposons que nous insérons les valeurs Nom
d'utilisateur et Mot de passe suivants:
$username = 1' or '1' = '1
$password = 1' or '1' = '1
1 / 12 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !