# Test d'intrusion
## Thème
Nous allons nous concentrer sur la sécurité des champs sur le web. Notament avec les injections SQL.
Nous allons voir deux examples issuent de CTFLearn :
- Basic Injection : https://ctflearn.com/challenge/88
- Inj3ction Time : https://ctflearn.com/challenge/149

## Basic Injection

### Example
1. Se rendre sur le site de test : https://web.ctflearn.com/web4/

2. Nous devons récupérer l'ensemble de la table avec une injection SQL dans le input. Nous savons que la saisie est stocké dans une variable ```$input``` qui sert ensuite à filtrer les utilisateurs avec leurs noms.
La requête nous est donnée : ```SELECT * FROM webfour.webfour where name = '$input'```

3. Saisir ```test' or '1'='1``` dans le champ pour récupérer toutes les données de la table.
Le filtre va s'effectuer sur la première valeur donnée, ici ```test```. Et nous ajoutons un 'OU' sur une condition toujours vrai ```'1' = '1'```. Nous pouvons récupérer toutes les données de la table

### ✅ Actions défensives
Pour prévenir les injections SQL nous pouvons faire appel aux requête préparée. Les paramètres seront interprété indépendament de la requête. Nous utiliserons la méthode ```prepare()``` ou PDO en PHP.
**Documentation** : https://www.php.net/manual/fr/pdo.prepare.php

Pour prévenir les injections de code malvaillant nous pouvons utiliser des méthodes comme ```htmlspecialchars()```qui ne vont pas interprété les caractères spéciaux.
**Documentation** : https://www.php.net/manual/fr/function.htmlspecialchars.php

Pour mieux sécuriser nos champs, nous pouvons vérifier les données saisis. Notament avec les Regex et la methode ```preg_match()``` sur PHP. Cette vérification doit se faire côté client (avec JavaScript notamment) et aussi côté serveur. On sera assuré que notre donnée est valide et au bon format.
**Documentation** : https://www.php.net/manual/fr/function.preg-match.php

## Inj3ction Time

### Example
1. Se rendre sur https://web.ctflearn.com/web8/

2. Si on saisie ```1``` on s'appeçois que la saisie et envoyé avec ```GET``` et non pas avec un ```POST```. On peut donc savoir que saisie est réutilisé tel quel dans la rêquete.


3. Réutilisons ce que nous avons vu dans le premier exercice. J'écris ```1 OR 1=1``` et je récupère toutes les données de la table.


4. Allons plus loin en essayant de déterminer le nombre de colonnes de la table. Je teste avec ```1 order by 4```, le résultat s'affiche correctement. Avec ```1 order by 5```, on me retourne 0 résultats. Cela signifit que la table a 4 colonnes. Le chiffre passé en paramètre du ```order by``` permet de trier un certains nombre de colonnes. Si le chiffre est trop grand, SQL renvoi une erreur car il n'y a pas assez de colonnes.

 → 

5. On peut ensuite trouver des informations de la base de données avec ```1 union select table_name,2,3,4 from information_schema.tables```. On en déduit notament le nom de deux tables : ```w0w_y0u_f0und_m3``` et ```webeight```. Le flag du challenge se trouve dans la table ```w0w_y0u_f0und_m3```.


Ce n'est qu'une infime partie des possibilités. Sur un blog Wordpress et en poussant le chalenge plus loins. Nous aurions pus récupérer un hash du mot de passe de connexion du backoffice.

### ✅ Actions défensives
Créer un utilisateur de base de donnée dédié à l'application. Cela permet de lui donner des droits adapté à son utilisation. Par example, l'application n'a pas besoins de modfier la structure de la base de donnée avec les commandes ```DROP``` et ```CREATE```. Utiliser le même utilisateur admin de la base donnerais la possibilité à l'attaquant de supprimer des tables etc...

Favoriser les requêtes POST plutot que les requêtes GET. Les requêtes GET sont visible et modifiable dans la barre url du navigateur.

Désactiver les messages d'erreurs SQL en production. En cas d'erreur, ils peuvent donner des indications sur la base de donnée.