# TP3 Tests de sécurité

Etudiant 1 |Etudiant 2 | Date | Sujet
------------ | ----------- |------------- | -------------
Houssainatou BAH | Louis ARACIL | 09/03/2021 | Tests de sécurité d'une application

## Introduction
Vous trouverez dans ce rapport les différentes leçons avec les différentes corrections comprénant à chaque fois une brève explication. Par la suite, les différentes ménaces et conséquences liées à chacune de ces leçon, puis une qualification des tests et enfin une conclusion.

## Access control flaws
### Using an Access Control Matrix

La faille à ce niveau vient du fait que l'utilisateur Larry n'est pas admin mais il peut avoir l'accès au ressources auxquelles seul un admin devrait acceder. Ce qui n'est pas normal puisqu'il n'a pas le status d'admin.
#### Problème dans le code

Dans le code, l'admin est exclu à l'aide de la condition suivante:

if (!getRoles(user).contains("Admin") && resource.equals("Account Manager")){
    makeSuccess(s);
}                 
s.setMessage("User " + user + " " + credentials + " was allowed to access resource " + resource);

## Code Quality
### Discover Clues in the HTML
En inspectant le code source de la page (HTML), on voit en commentaire les données de connexion suivantes:

<!-- FIXME admin:adminpw  --><!-- Use Admin to regenerate database  -->

En rentrant ces données on arrive bien à établir la connexion.

## Injection Flaws
### String SQL Injection

En ajoutant à Smith une condition sur un user id, on obtient les informations d'autres personnes en plus de Smith.

Si on passe 'Smith', on obtient:

SELECT * FROM user_data WHERE last_name = 'Smith'

Donc, si on ajoute ``` ' ``` (une quote), on peut injecter du SQL, il reste alors à séléctionner toute les entrées d'un champs et à ajouter une autre entrée nécéssitant un string où l'on place une quote en entrée.

#### Exemple pour obtenir tous les numéros de cartes:
Si on entre

Smith' OR userid IS NOT NULL  OR last_name = 'Smith

On obtient

SELECT * 
FROM user_data 
WHERE last_name = 'Smith' 
OR userid IS NOT NULL  
OR last_name = 'Smith'

### Database Backdoors: Stage 1

Pour cet exercice, il suffit d'utiliser un ``` ; ``` pour pouvoir écrire une nouvelle instructution. Il suffit donc d'entrer un userid valide, puis de faire un ```UPDATE```.

#### Exemple:
Si on entre cette commande:

0 or userid IS NOT NULL; UPDATE employee SET salary = 0

On obtient le résultat suivant:

select userid, password, ssn, salary, email from employee where userid=0 OR userid IS NOT NULL; 
UPDATE employee SET salary = 0

On peut alors constater que tous les salaires sont à 0.

User ID | Password | SSN | Salary | E-Mail
--------|--------------|------------|-----------------|--|
101 | larry | 386-09-5451 | 0 | [e-mail]
102 | moe | 936-18-4524 |0 |[e-mail]
103 |curly |961-08-0047 |0 |[e-mail]
104 |eric |445-66-5565 |0 |[e-mail]
105 |tom |792-14-6364 |0 |[e-mail]
106 |jerry |858-55-4452 |0 |[e-mail]
107 |david |439-20-9405 |0 |[e-mail]
108 |bruce |707-95-9482 |0 |[e-mail]
109 |sean |136-55-1046 |0 |[e-mail]
110 |joanne |789-54-2413 |0 |[e-mail]
111 |john |129-69-4572 |0 |[e-mail]
112 |socks |111-111-1111 |0 |[e-mail]

## Improper Error Handling
### Fail Open Authentication Scheme
En analysant le code correspondant à ce challenge, on peut voir ci-dessous dans le code qu'on a une condition qui fait qu'il n'est pas possible de se connecter avec un mot de passe vide mais l'exception est capturé pour le cas d'un succès ce qui n'est pas normal.

catch (Exception e)
 86              {
 87                  // The parameter was omitted. set fail open status complete
 88                  if (username.length() > 0 && e.getMessage().indexOf("not found") != -1)
 89                  {
 90                      if ((username != null) && (username.length() > 0))
 91                      {
 92                          makeSuccess(s);
 93                          return (makeUser(s, username, "Fail Open Error Handling"));
 94                      }
 95                  }
 96              }
 // Don't let the fail open pass with a blank password.
      if (password.length() == 0)
      {
         // We make sure the username was submitted to avoid telling the user an invalid
          // username/password was entered when they first enter the lesson via the side menu.
         // This also suppresses the error if they just hit the login and both fields are
         // empty.
        if (username.length() != 0)
             s.setMessage("Invalid username and password entered.");
         }

## Parameter Tampering
### Bypass HTML Field Restrictions

Pour ce cas, lorsque nous modifions toutes les valeurs de chaque fields en même temps en mettant des caractères speciaux. On soumet le formulaire avec toutes les modifications ensemble on arrive à soumettre avec des valeurs qui ne sont pas autorisées. Nous avons utilisé pour cela l'inspecteur de code firefox et avons donc modifié les valeurs à partir de laba.
Donc on peut à partir d'un navigateur soumettre des valeurs qui ne sont pas attendues.

## Cross-Site Scripting (XSS)
### Cross Site Request Forgery (CSRF)

Pour ce cas, après avoir recuperé le lien, si on ajoute dans la balise img le paramètre transferFunds=4000,cela permet d'envoyer donc un message contenant la balise img. On constate que dans le message reçu l'image n'apparait pas donc on reçoit un message "formaté". Voici le contenu de la balise img que nous avons rajouté au message:

<img src="http://localhost:8080/WebGoat-5.4/attack?Screen=33&menu=900&transferFunds=4000" width="1" weight="1"/>

## Session Management Flaws
### Spoof an Authentication Cookie
Pour ce cas, après authentification on obtient les cookies suivants:
* Avec webgoat/webgoat: AuthCookie :"65432ubphcfx".
* Avec aspect/aspect: AuthCookie :"65432udfqtb".

On remarque déjà que les deux commencent par les chiffres 65432 (qui representent ici les chiffres suivants de la suite 12345 en partant de la fin), la difference est donc sur les lettres. Cela peut d'ailleurs ce comprendre par cette partie du code:

   if (cookie != null)
 95          {
 96              if (cookie.equals(encode("webgoat12345"))) { return ("webgoat"); }
 97  
 98              if (cookie.equals(encode("aspect12345"))) { return ("aspect"); }
 99  
100              if (cookie.equals(encode("alice12345")))
101              {
102                  makeSuccess(s);
103                  return ("alice");
104              }
105              else
106              {
107                  s.setMessage(WebGoatI18N.get("InvalidCookie"));
108                  s.eatCookies();
109              }
110          }

Ce qui veut dire qu'il faut trouver l'équivalent de l'encodage des lettres pour alice aussi afin de pouvoir se connecter. En analysant les deux suites de lettres, on remarque aussi que comme pour les chiffres la suite est formée des lettres suivantes de la suite qui est donnée en partant de la fin c'est ce qui donne uwbphcfx pour webgoat. On fait la même chose pour aspect. En partant de ce principe pour le cas de alice on aura donc: alice12345 => 65432fdjmb. Finalement en ajoutant ce cookie à la liste des cookies on arrive à se connecter.

## Malicious Execution
### Malicious File Execution
On a pas reussi à résoudre ce problème.
# Les menaces
Dans cette partie, nous allons donner les menaces de sécurité correspondant à chacune des leçons.
* Leçon 1: Ménace liée à la confidentialité ou faille de contrôle d'accès, le risque à ce niveau est qu'un utilisateur peut par exemple acceder à des informations même s'il n'en a pas le droit.
* Leçon 2: Usurpation d'identité mais aussi vol de données, à ce niveau on voit qu'en ne faissant pas attention à ce qu'on affiche ou met en commentaire par exemple sur une page peut permettre de s'authentifier avec les informations que nous ne disposons pas de base. Ceci peut conduire à du vol d'identité, de données, des ransons, ... les conséquences peuvent être terribles.
* Leçon 3: Accès à des informations importantes. En faisant une injection, des informations sensiblent peuvent être divulgées.
* Leçon 4: Ce qui est en jeu ici c'est l'integrité des données, c'est à dire qu'on peut modifier des données sensibles sans en avoir le droit.
* Leçon 5: Menace liée à l'authentification.
* Leçon 6: Menace liée à l'autorisation, ici on peut soumettre des données en modifiant le html à partir d'un inspecteur par exemple.
* Leçon 7: Dans ce cas, un utilisateur peut détourner des sessions utilisateur, rediriger l’utilisateur vers des sites malveillants... Cela peut avoir de graves conséquences.
* Leçon 8: En exploitant des données comme des cookies, un utilisateur peut accéder à des données, s'authentifier, peut-être même rendre indisponible les services (DDOS).
* Leçon 9:
## Qualification des tests
Ces tests sont des tests manuels en boite blanche(nous avions accès aux codes sources), ce sont des tests de sécurité.
## Conclusion
On a compris à travers ce tp que des applications que l'on peut croire parfois sécurisées ne le sont pas réellement. Ce qui permet de prendre conscience des "dangers" aux quels on pourrait exposer nos applications, et plus de façon indirecte. Les ménaces liées à la sécurité applicatives conduisent à de très graves conséquences qui peuvent aller de l'usurpation d'identité, au vol de données mais aussi à dénis de services et tant d'autres.