{{Modèle:Testing Guide}} # Résumé # La plupart des applications nécessitent une authentification pour accéder à des informations confidentielles ou pour exécuter des tâches, mais toutes les méthode d'authentification ne sont en mesure d'assurer une sécurité adéquate. La négligence, l'ignorance ou le simple fait de minimiser les menaces à la sécurité donnent souvent lieu à des schémas d'authentification qui peuvent être contournées par la simple fait de sauter la page de connexion et d'appeler directement une page interne qui est censé être accessible uniquement après authentification. En plus de cela, il est souvent possible de contourner les mesures d'authentification par des manipulations de requêtes et tromper l'application en faisant croire que nous sommes déjà authentifié. Ceci peut être accompli soit en modifiant données des paramètres URL ou en manipulant la forme ou contrefaisant des sessions. # Description # Des problèmes liés au schéma d'authentification peuvent survenir à différents stades du cycle de vie du développement logiciel (SDLC), comme la phase de conception, de développement et de déploiement. Les problèmes de conception recouvrent la définition erronée des parties de l'application à protéger, le choix de ne pas appliquer les protocoles de chiffrement fort pour sécuriser l'échange de données d'authentification, et beaucoup plus. Les problèmes dans la phase de développement recouvrent, par exemple, la mise en œuvre incorrecte des fonctionnalités de validation d'entrée, ou de ne pas suivre les meilleures pratiques de sécurité pour la langue spécifique. En outre, il peut y avoir des problèmes pendant l'installation de l'application (lors de l'installation et de la configuration), en raison d'un manque de compétences techniques nécessaires, ou en raison de la piètre documentation disponible. # Test boîte noire # Il existe plusieurs méthodes pour contourner le schéma d'authentification utilisé par une application web: * Demande directe des pages (navigation forcée) * Modification des paramètres * Prédiction ID de Session * Injection SQL ## Demande directe des pages ## Si une application web met en œuvre un contrôle d'accès uniquement sur la page de connexion, le schéma d'authentification peut être contourné. Par exemple, si un utilisateur demande directement une autre page via la navigation forcée, cette page peut ne pas vérifier les informations d'identification de l'utilisateur avant d'autoriser l'accès. Tentez d'accéder directement à une page protégée par la barre d'adresse de votre navigateur pour tester cette méthode. ## Modification des paramètres ## Un autre problème lié à la conception d'authentification survient lorsque l'application vérifie une connexion réussie sur la base de quelques paramètres à valeur fixe. Un utilisateur peut modifier ces paramètres pour accéder aux zones protégées sans fournir les informations d'identification valides. Dans l'exemple ci-dessous, le paramètre "authenticated" est modifié à une valeur de «yes», ce qui permet à l'utilisateur d'y accéder. Dans cet exemple, le paramètre est dans l'URL, mais un proxy peut aussi être utilisé pour modifier le paramètre, surtout lorsque les paramètres sont envoyés comme éléments de formulaire dans une requête POST.

http://www.site.com/page.asp?authenticated=no 
...
raven@blackbox /home $nc www.site.com 80                    
GET /page.asp?authenticated=yes HTTP/1.0                    
...                                                           
HTTP/1.1 200 OK                                             
Date: Sat, 11 Nov 2006 10:22:44 GMT                         
Server: Apache                                              
Connection: close                                           
Content-Type: text/html; charset=iso-8859-1                 
... 
          
                                                 
                                                
 You Are Auhtenticated

## Prédiction d'ID de Session ## Beaucoup d'applications web utilisent pour gérer l'authentification les valeurs de l'identification de session (Session ID). Par conséquent, si la génération d'ID de session est prévisible, un utilisateur malveillant pourrait être en mesure de trouver un ID de session valide et accéder à l'application, en usurpant l'identité d'un utilisateur authentifié au préalable. Dans la figure suivante, les valeurs à l'intérieur des cookies augmentent de façon linéaire, de sorte qu'il pourrait être facile pour un attaquant de deviner un ID de session valide . Dans la figure suivante, les valeurs à l'intérieur des cookies ne changent que partiellement, il est donc possible de restreindre une attaque en force brute pour les champs définis-dessous. ## Injection SQL (authentification par formulaire HTML) ## L'injection SQL est une technique d'attaque connues. Nous n'allons pas décrire cette technique en détail dans cette section, il y a plusieurs sections de ce guide qui expliquent les techniques d'injection au-delà de la portée de cet article. La figure suivante montre qu'avec une attaque par injection SQL simple, il est parfois possible de contourner le formulaire d'authentification. # Test Boîte Grise # Si un attaquant a pu récupérer le code source de l'application en exploitant une vulnérabilité précédemment découverte (par exemple, traversée de répertoire), ou à partir d'un référentiel Web (applications Open Source), il pourrait être possible d'effectuer des attaques plus raffinées contre le processus d'authentification. Dans l'exemple suivant (PHPBB 2.0.13 - Vulnérabilité de contournement de l'authentification), à la ligne 5, la fonction unserialize() analyse un cookie fourni et définit des valeurs dans le tableau $row. À la ligne 10, le mot de passe utilisateur est haché en md5 et stocké à l'intérieur de la base de données principale est comparé à celui qui est fourni.

1.  if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
2.  {
3.  $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4. 
5.  unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
6. 
7.  $sessionmethod = SESSION_METHOD_COOKIE;
8.  }
9. 
10. if( md5($password) == $row['user_password'] && $row['user_active'] )
11. 
12. { 
13. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;
14. }

En PHP, une comparaison entre une valeur de chaîne et une valeur booléenne (1 - "TRUE") est toujours "TRUE", aussi en fournissant la chaîne suivante (la partie importante est "b: ") à la fonction unserialize (), il est possible de court-circuiter la commande d'authentification:

a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}

# Références # ## Livres blancs ## * **Mark Roxberry:** "PHPBB 2.0.13 vulnerability" * **David Endler:** "Session ID Brute Force Exploitation and Prediction" - http://www.cgisecurity.com/lib/SessionIDs.pdf ## Outils ## * WebScarab * WebGoat