Protéger Innocent MySQL à partir Injection SQL
Auteur:
Ashfaq Ansari

Commenté par:
Classement:
5
Sur Octobre 19, 2012
Dernière mise à jour:Janvier 18, 2013

Résumé:

Guide détaillé sur la façon de prévenir toute injection MySQL en PHP. Sécurisés règles et fonctions pour prévenir injection SQL codage.

Présentation

 

Ceci est un bref guide sur la façon de protéger votre innocent MySQL base de données à partir de Injection SQL attaques.
 

Quel est Injection SQL?

 

Comme son nom l'indique, SQL Injection se produit lorsque l'utilisateur injecte des instructions SQL dans votre application.
 
Comment cela se fait?
 
Disons que nous avons un formulaire de connexion simple qui prend un nom d'utilisateur et mot de passe, et valide contre la base de données. Si le nom d'utilisateur et mot de passe sont validés, l'utilisateur est connecté au système.
 

Le code de ce qui pourrait ressembler à ceci:
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
// obtenir l'utilisateur et mot de passe à partir de la requête POST
$nom_utilisateur = $_POST[ 'Username' ];
$mot de passe  = $_POST[ 'Password' ];

$requête = "SELECT prenom, nom_famille, account_number DE users_table WHERE username = '$nom_utilisateur'AND password ='$mot de passe» ";

$entraîner = mysql_query( $requête );

// vérifier si mysql rien trouvé, et voir la fiche si elle a réussi
si ( mysql_num_rows( $entraîner ) > 0 ) {
    $données = mysql_fetch_assoc( $entraîner );
    echo "Bienvenue" . $utilisateur . »!»;
    echo «Votre numéro de compte est: » . $données[ «Account_number ' ] . '';
} //Imprimez le message d'errorr
autre {
    echo «Nom d'utilisateur ou mot de passe non valide! S'il vous plaît essayer à nouveau!»;
}
?>

 

Le script ci-dessus fonctionne très bien et il permettra aux utilisateurs d'entrer leur véritable nom d'utilisateur et mot de passe pour voir leur numéro de compte bancaire.
 

Supposons que j'entre “démo” que mon nom d'utilisateur, et “demopass” comme mon mot de passe, alors la requête SQL qui est passé à l'MySQL va ressembler à ceci:
 

1
SELECT prenom, nom_famille, account_number D' users_table Nom d'utilisateur = 'Demo' ET mot de passe = «Demopass ' ;

 

Si les données d'entrée sont validées avec succès dans la base de données, alors nous serons connectés au système et nous sera présenté avec le numéro de compte d'autre que nous n'obtiendrons pas l'accès au système et nous sera présenté avec un message d'erreur “Nom d'utilisateur ou mot de passe non valide! S'il vous plaît essayer à nouveau!
 

Le problème quand un utilisateur malveillant pénètre autres personnages qui sont destinés à mettre fin à l'instruction SQL.
 

Supposons qu'un utilisateur tente de se connecter en tant que nom d'utilisateur dem'o et mot de passe demopass.
 

Maintenant, nous allons voir comment l'instruction SQL ressemble.
 

1
SELECT prenom, nom_famille, account_number D' users_table Nom d'utilisateur = 'Le'le'AND password ='demopass» ;

 

Lorsque MySQL exécute la déclaration, il traitera seulement “le” comme le nom d'utilisateur et quand il rencontre un autre ‘le», puis il traite ‘le‘ comme une commande SQL et il va jeter et le message d'erreur car il ne reconnaît pas ‘le‘ comme une commande valide SQL.
 
ERREUR 1064 (42000): Vous avez une erreur dans votre syntaxe SQL; consultez le manuel qui correspond à votre version du serveur MySQL pour la bonne syntaxe à utiliser près de 'o’ et mot de passe =”demopass”; ” à la ligne 1
 

Impressionnant. Le message d'erreur ci-dessus indique qu'il ya une erreur dans la syntaxe SQL. Si Les guillemets magiques? ont permis, alors nous ne aurions pas eu ce message d'erreur ci-dessus.
 

Maintenant, Voyons ce qui se passe si l'utilisateur malveillant pénètre nom d'utilisateur que (‘ Ou '1' = '1) et mot de passe “demopass“.

La requête SQL ressemblera à ceci:

1
SELECT prenom, nom_famille, account_number D' users_table Nom d'utilisateur = '' OU '1'='1' ET mot de passe = «Demopass ' ;

 

Qu'est-ce que la requête SQL ci-dessus signifie? Il indique à MySQL de trouver toutes les lignes avec un nom d'utilisateur égale à “” (vide) ou (1= 1) et un mot de passe égale à “demopass“.
 

Disons représentent la requête SQL ci-dessus plus logiquement de comprendre ce qui est en fait mal à l'instruction SQL:
 

username = “” OU “1= 1” AND password = “demopass”
 

Maintenant, nous savons déjà que 1 = 1 est toujours d'être TRUE. Par conséquent, l'utilisateur sera en mesure de se connecter au système si le mot de passe est correct et le nom d'utilisateur est erroné.
 

Analysons scénario plus mauvais avec une chaîne d'attaque différente.
 

Attaque cordes: ‘ OR 1 = 1–
 

Se il vous plaît noter que ( et #) sont utilisés pour fin instruction SQL. Mettons la chaîne d'attaque dans une requête SQL et voir comment l'instruction SQL final ressemblera.
 

Maintenant, nous supposerons que l'attaquant ne sait même pas le mot de passe.
 

1
SELECT prenom, nom_famille, account_number D' users_table Nom d'utilisateur = '' OU 1=1--'AND password =' ​​idonotknow ' ;

 

Voyez comment l'instruction SQL est interprété par MySQL.
 

username = “” OR 1 = 1– AND password = “je ne sais pas”
 

Notez se il vous plaît dans la déclaration ci-dessus. Comme nous savons que est une déclaration de terminaison dans SQL et 1= 1 est toujours vrai, après la déclaration de terminaison reste de la requête SQL ne sera pas exécuté.
 

Par conséquent, TOUS les enregistrements de la table vont se retourner et l'utilisateur sera connecté au système. L'attaquant sera capable de voir le numéro de compte du premier enregistrement dans la base de données.
 

Aidons innocent MySQL
 

Les guillemets magiques?

 

Les guillemets magiques? est une fonctionnalité controversée du langage de script PHP, dans laquelle les caractères spéciaux sont prep-clos avec une barre oblique inverse avant d'être transmis.
 

Les guillemets magiques? étaient activés par défaut dans les nouvelles installations de PHP3 et PHP4, et depuis leur fonctionnement est dans les coulisses et non pas immédiatement évident, Les développeurs peuvent ignorer leur existence et les problèmes potentiels qu'ils peuvent introduire.
 

Nous allons devoir allumer l' Les guillemets magiques? à php.ini fichier dans la bande-racine du site.
 

Comment les guillemets magiques aide?

 

Nous devons être échapper à ces caractères de citation ( citations à la fois simples et doubles, ainsi que des barres obliques inversées).
Ceci est fait en mettant une barre oblique devant eux.
 

So usename = dem'o devient dem 'o , et MySQL peut fonctionner avec cette marque de cotation que ce est “protégé” par la barre oblique.
 

Voyons ce qui arrive quand Les guillemets magiques? est activée. Voyons comment l'attaquant est touché avec les guillemets magiques?.
 

1
SELECT prenom, nom_famille, account_number D' users_table Nom d'utilisateur = » OU 1 = 1-- ' ET mot de passe = 'Je Ne Sais Pas' ;

 

Le nom d'utilisateur est interprétée comme: \’ OR 1 = 1–

Ce est une parfaite requête SQL échappé, rien ne peut se injecté. magic_quotes_gpc échappe à la apostrophe dangereux pour nous. Par conséquent, l'attaquant ne sera pas en mesure de se connecter au système.

Problèmes avec les guillemets magiques?

 

Magic quotes seulement insérer une barre oblique inverse avant quelques caractères, sans plus. Cela nous protège de l'injection SQL seulement dans certains cas particuliers, comme ci-dessus et que par coïncidence. Si nous avons display_errors ON, nous venons de faire l'attaquant très heureux avec les détails de votre base de données émis sous ses yeux. Même si vous n'avez pas, il ya toujours une possibilité d'injection SQL aveugle et en utilisant avance méthodes d'injection SQL, il est possible de contourner magic_quotes_gpc fonction.
 
Alors, nous devons trouver un moyen d'échapper à des données qui ne sont pas de merde, n'est pas aussi sujette à des problèmes de jeux de caractères, et n'est pas sujette à l'élevage citations tailladées magiques.
 
En Novembre 2005 les développeurs du noyau PHP décidé en raison de ces problèmes que l' magic quotes fonctionnalité serait retirée de PHP 6.
Une fois que la Magic quotes caractéristiques est retirée, alors il va y avoir quelques problèmes majeurs surgissent.
 

SQL Injection atténuation
 

Il ya un certain nombre de façons de prévenir MySQL injections dans PHP. Les façons les plus courantes utilisent des fonctions telles que addslashes() et mysql_real_escape_string().
 

addslashes()

 

addslashes() retourne une chaîne avec une barre oblique inverse avant de caractères qui doivent être désinfectés dans les requêtes de base de données. Ces personnages sont des apostrophes (‘ = ’) guillemets (” = ”) et la Nullbyte (%00 = \0).
 

addslashes() ne fonctionnera que si la chaîne de requête est enveloppé dans citations. Une chaîne comme celle-ci serait encore vulnérable à une injection SQL:
 

1
2
3
$nom_utilisateur = addslashes( $_POST[ 'Username' ] );
$mot de passe  = addslashes( $_POST[ 'Password' ] );
$requête = "SELECT prenom, nom_famille, account_number DE users_table WHERE username = '$nom_utilisateur'AND password ='$mot de passe» ";

mysql_real_escape_string()

 

mysql_real_escape_string() est un peu plus puissant que addslashes() comme il appelle la fonction de bibliothèque de MySQL mysql_real_escape_string, qui est précédée d'un antislash pour les caractères suivants: \x00, \n, \r, \, », ” et x1a.
 

Comme avec addslashes(), mysql_real_escape_string() ne fonctionnera que si la chaîne de requête est enveloppé dans citations. Une chaîne comme celle-ci serait encore vulnérable à une injection SQL:
 

1
2
3
$nom_utilisateur = mysql_real_escape_string( $_POST[ 'Username' ] );
$mot de passe  = mysql_real_escape_string( $_POST[ 'Password' ] );
$requête = "SELECT prenom, nom_famille, account_number DE users_table WHERE username = '$nom_utilisateur'AND password ='$mot de passe» ";

 

sprintf()

 

sprintf() peut être utilisé avec des spécifications de conversion afin d'assurer que l'argument dynamique est traité de la façon dont il est censé être traités. Par exemple, si un appel pour le numéro d'identification de l'utilisateur sont dans la chaîne, %s seraient utilisés pour assurer l'argument est traité comme une chaîne. Un exemple de cela est la suivante:
 

1
2
3
$nom_utilisateur = $_POST[ 'Username' ];
$mot de passe  = $_POST[ 'Password' ];
$requête = sprintf("SELECT prenom, nom_famille, account_number DE users_table WHERE username = '%s'AND password ='%s» ", $nom_utilisateur, $mot de passe);

 

htmlentities($était, ENT_QUOTES)

 

htmlentities() en liaison avec le deuxième paramètre d'option quote_style, permet l'utilisation de ENT_QUOTES, qui vous permet de convertir des citations à la fois simples et doubles. Cela fonctionnera dans le même sens que addslashes() et mysql_real_escape_string() en ce qui concerne les guillemets, cependant, au lieu de précéder une barre oblique inverse, il utilisera l'entité HTML du guillemet.
 

En plus de l'aide ENT_QUOTES à l'intérieur htmlentities(), un troisième paramètre peut être réglée qui force l'utilisation d'un jeu de caractères à l'intérieur de conversion. Cela aidera à arrêter résultats imprévus de l'aide multibyte personnages dans les jeux de caractères comme BIG5 et GPK.
 

Ce qui suit est un exemple de code qui aiderait à prévenir Injection SQL en PHP.
 

1
2
3
4
5
$nom_utilisateur = $_POST[ 'Username' ];
$nom_utilisateur = htmlentities( $nom_utilisateur, ENT_QUOTES, 'UTF-8' );
$mot de passe  = $_POST[ 'Password' ];
$mot de passe  = htmlentities( $mot de passe, ENT_QUOTES, 'UTF-8' );
$requête = "SELECT prenom, nom_famille, account_number DE users_table WHERE username = '$nom_utilisateur'AND password ='$mot de passe» ";

 

Optimiser le code SQL

 

serveurs de base de données sont bêtes complexes et ils ont beaucoup plus de fonctionnalités que vous avez besoin. En ce qui concerne la sécurité, plus ne est jamais mieux. Par exemple, le xp_cmdshell procédure stockée étendue en MS SQL donne accès au shell et ce est exactement ce que un pirate de rêves. Ce est pourquoi vous devez désactiver cette procédure et toute autre fonctionnalité, qui peut facilement être mal utilisés. Il suffit de retirer ou au moins désactiver toutes les fonctionnalités que vous pouvez faire sans.
 

Désactiver par défaut message d'erreur SQL

 

Les messages d'erreur sont utiles pour un attaquant car ils donnent des informations supplémentaires sur les requêtes de base de données et SQL. Et toutes les attaques SQL sont généralement basés sur le type d'erreur émis par SQL, cela signifie que ce type d'erreur décide l'approche des pirates pour le piratage du site ou de l'application. Une meilleure solution qui ne compromette pas la sécurité serait d'afficher un un message d'erreur générique qui indique simplement qu'une erreur s'est produite.
 

Stocker les informations de base de données en toute sécurité

 

Afin de minimiser les dégâts en cas d' Attaque par injection SQL, toujours stocker les informations de base de données dans un fichier crypté séparé. Maintenant, même si un pirate parvient à briser dans, il ou elle ne profitera pas autant qu'il ne peut pas faire grand-chose dans votre base de données.
 

Utilisez moins Principe Privilège

 

Le principe du moindre privilège est très bénéfique et elle s'applique à Injections SQL aussi. Toujours penser ou vérifier deux fois à ce privilèges vous fournissez à utilisateur ou objet. Supposons que vous WAN pour fournir un accès modérateur pour certains utilisateurs, si seulement lui fournir l'accès de ces tableaux dont il / elle a besoin, plutôt que de lui prouver l'accès de l'ensemble de base de données. Si vous devez fournir un accès à un système, de son mieux pour créer des espaces de table partitionnée intérieur de base de données et fournir un accès uniquement à l'espace de table spécifique. Cette technique réduire considérablement la surface d'attaque.
 

Coquilles Désactiver

 

De nombreuses bases de données offrent un accès shell à la base de données qui est essentiellement ce qu'un attaquant ou un pirate besoins. En raison de cela, vous devez fermer cette échappatoire. Chaque fournisseur de services a méthode différente pour désactiver l'exécution des coquilles à leur base de données. Alors consultez la documentation de votre base de données sur la façon de désactiver l'accès au shell pour votre espace de base de données ou une table particulière ou une table particulière.
 

Utilisation des outils SQL Injection Pour vérifier Vulnérabilités

 

Dernier point mais non le moins, penser comme pirate. Comment un pirate peut pirater ma base de données via Injection SQL, Quels sont les outils et les techniques qu'il peut utiliser pour trouver les failles. Vous devriez toujours avoir une répétition des outils de piratage SQL injection comme SQLi, Haviz, SQL injectme etc. Plus si vous pouvez vous permettre un scanner de vulnérabilité de la rétine puis c'est trop beau. Comme il se compose de toutes les vulnérabilités exposées dernières.

Merci beaucoup. J'espère que vous devez tous avoir apprécié. S'il vous plaît donner des commentaires afin que nous puissions faire plus mieux.

 
 

28,912 vues au total, 11 vues aujourd'hui

Les deux onglets suivants changent contenu ci-dessous.

Ashfaq Ansari

chercheur en sécurité
Ashfaq Ansari est le fondateur de HackSys équipe nom de code "Panthera". Il est un chercheur en sécurité avec une expérience dans divers aspects de la sécurité de l'information. Il est l'auteur "HackSys Extreme pilote Vulnérable" et "Shellcode de la mort". Il a également écrit et publié plusieurs livres blancs sur l'exploitation du logiciel de bas niveau. Son intérêt de base réside dans "Low Level exploitation", "Reverse Engineering", "Analyse du programme" et "Hybrid fuzzing". Il est un fanboy de l'intelligence artificielle et l'apprentissage automatique. Il est le chef de file pour le chapitre null Pune.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont marqués *