- [OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) - Top 10 des failles impactant les applications Web
- [OWASP Code Review Guide](https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project) - Guide de la revue de code appliquée à la sécurité
- [OWASP ASVS](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) - Standard des vérifications de sécurité des applications Web
- [OWASP Webgoat](https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project) - Application(s) volontairement faillible(s) illustrant les principales failles de sécurité actuelles.
docker run -p 8080:8080 -it --rm webgoat/webgoat-8.0 /home/webgoat/start.sh
# Puis ouvrir l'URL http://localhost:8080/WebGoat/
# dans votre navigateur
```
---
## Injections SQL (SQLI)
### Pratique
> Epicfaild: Gate 3 et 4
> WebGoat: Injection Flaws (- XEE)
---
## Risques
- Vol de données
- Altération de données
- Prise de contrôle du serveur
---
## Mitigation
- Exécuter le moteur de base de données avec un utilisateur dédié.
- Valider TOUTES les entrées utilisateur.
- Utiliser des requêtes préparées.
- Installer un NIDS au niveau du serveur HTTP
---
## Contournement de la session
### Pratique
> Epicfaild: Gate 3
> WebGoat: Authentication Bypass
---
## Risques
- Vol de session
- Vol de données
- Prise de contrôle de l'application
---
## Mitigation
- Valider TOUTES les entrées utilisateurs
- Journaliser les origines des connexions
---
## Cross Site Scripting (XSS)
### Pratique
> Epicfaild: Gate 1
> WebGoat: Cross Site Scripting
---
## Risques
- Vol de sessions
- Hameçonnage
---
## Mitigation
- Valider TOUTES les entrées utilisateurs
- Assainir les données avant de faire leur rendu
---
## Mauvais contrôle des accès
### Pratique
> WebGoat: Access Control Flaws
---
## Risques
- Accès non autorisés à des fonctionnalités critiques
- Vol de données
- Prise de contrôle de l'application
---
## Mitigation
- Journaliser tous les accès à des ressources critiques (qui, quoi, quand, quel contexte ?)
- Utiliser une double authentification pour l'accès aux ressources critiques
> **Attention** L'obfuscation des accès n'est pas une méthode de sécurisation des points d'entrée.
---
## Fuite d'informations sensibles
### Pratique
```
Epicfaild: Gate 4/5
WebGoat: Insecure communication, Client Side/Client side filtering
```
---
## Risques
- Vol de données
---
## Mitigation
- Ne retourner à l'utilisateur que les données dont il a besoin (approche "frugale").
- Limiter la zone d'action de l'utilisateur à ses seuls besoins.
---
## Cross Site Request Forgery (CSRF)
### Pratique
> WebGoat: Request Forgeries
---
## Risques
- Hameçonnage
- Vol de session
- Vol d'identité
---
## Mitigation
- Utilisation de `nonce` (aussi appelé CSRF Token)
- Utilisation de requêtes `POST|PUT|DELETE` pour toutes les actions autres que la "consultation"
- S'assurer que les mécanismes de type "HTTP Method Override" ne sont pas activés en production ([Exemple pour Symfony3](http://symfony.com/doc/2.6/cookbook/routing/method_parameters.html#faking-the-method-with-method))
Prometheus stocke des échantillons (mesures) sous la forme de **séries temporelles**. Il créait une nouvelle série pour chaque association **(nom_métrique, label1=value, label2=value, ...)**.
Chaque couple **(label, valeur)** est appelée **dimension** de la métrique.
Un histogramme est une métrique répartissant les données dans des "seaux" (ou "buckets" en anglais) configurables et comptant le nombre total et par "paquet" d'échantillons ainsi que leur somme.
_[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/operators/)_
---
## Fonctions
### Quelques exemples
-`rate(range vector)` Retourne la fréquence moyenne d'augmentation par seconde de la série temporelle dans l'espace de temps donné. À utiliser uniquement avec les compteurs.
-`time()` Retourne le nombre de secondes depuis l'Epoch Unix.
-`increase(range vector)` Retourne l'augmentation de la série temporelle dans l'interval de temps donné. À utiliser uniquement avec les compteurs.
Et aussi [histogram_quantile()](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile), [predict_linear()](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()),...
_[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/functions/)_
1. Créer une nouvelle application Symfony3 et configure une authentification de type "Basic Auth" sur une route.
2. Implémenter une `Listener` pour l'évènement `security.authentication.failure` ([voir ce tutoriel](https://www.brainvire.com/create-authentication-listener-symfony2/))
3. Installer et configurer le bundle [tweedegolf/prometheus-bundle](https://github.com/tweedegolf/prometheus-bundle)
4. Mettre en place une sonde pour détecter les tentatives répétées d'authentification échouées pour une adresse IP donnée.
5. Mettre en place une alerte lorsque le nombre d'authentifications échouées dépasse un certain seuil dans un espace de temps donné.
-`/etc/fail2ban/fail2ban.conf` - Fichier de configuration général
-`/etc/fail2ban/jail.conf` - Définition des "jails" par défaut
-`/etc/fail2ban/jail.d` - Définitions de "jails" additionnelles
-`/etc/fail2ban/filter.d` - Filtres d'activation des "jails"
-`/etc/fail2ban/action.d` - Définition des actions potentielles à exécuter en cas d'activation d'une "jail".
_La personnalisation de la configuration se fait en créant des fichiers `<nom_fichier>.local`._
---
## Exercice
Configurer fail2ban pour bannir les IP à l'origine de tentatives de connexion échouées sur un site Wordpress.
1. Installer et configurer Wordpress sur votre serveur (voir page suivante)
2. Créer une `failregex` pour détecter les tentatives échouées de connexion à votre Wordpress. Quelle est la différence dans les logs entre un échec et un succès ?
3. Créer votre filtre `/etc/fail2ban/filter.d/wordpress.conf` avec votre expression régulière. Pour tester:
```
fail2ban-regex --print-all-match <logfile> \
/etc/fail2ban/filter.d/<filter>.conf
```
4. Créer votre propre section "wordpress" dans le fichier `/etc/fail2ban/jail.local` en vous inspirant des exemples déjà présents.
---
## Préparation
- Sur votre machine virtuelle, installer Wordpress et MySQL
- Créer un compte utilisateur dans la base de données MySQL
```bash
mysql -u root -p
mysql> CREATE DATABASE wordpress;
mysql> GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost'
IDENTIFIED BY '<password>';
mysql> quit
```
- Modifier la configuration pour que Wordpress utilise sa base de données (fichier `/etc/wordpress/config-<votre_ip>.php`)
---
## Supervision du système avec Prometheus
## Exercice
- Sur votre machine virtuelle, installer l'exporteur de métriques [`Node Exporter`](https://github.com/prometheus/node_exporter/) et créer un nouveau service [`systemd`](https://doc.ubuntu-fr.org/creer_un_service_avec_systemd) pour celui ci.
- Installer et configurer un serveur Apache2 avec un VirtualHost exposant via la directive `ProxyPass` du module [`mod_proxy`](https://httpd.apache.org/docs/current/mod/mod_proxy.html).
- Mettre en place une règle d'alerte sur votre instance Prometheus locale afin de prévenir le remplissage du disque de votre serveur via la fonction [`predict_linear()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()) (par exemple 4 heures ?)