[STANDARD] OWASP - Episode 4

Nous abordons ici la troisième phase des tests actifs. Ils concernent la gestion des sessions à travers les cookies. De nombreux paramètres peuvent être testés. Etant donné qu'une mauvaise implémentation peut permettre l'obtention d'une session à un attaquant, nous voyons de suite l'intérêt de ce sujet.

1 - Avant-propos

Ce post est le quatrième d'une série de dix. Chaque "épisode" aborde un chapitre de la norme OWASP, version 3. Le but est de mener le test d'intrusion d'une application WEB méthodologiquement. Le post présent fait référence au chapitre 4.5 de la norme, nommé "Session Management". Pour la partie théorique, voir l'article sur Wikipedia en anglais très intéressant. Pour le côté pratique, il est recommandé d'effectuer tous ces tests à l'aide d'un proxy local pour intercepter et rejouer les requêtes HTTP.

2 - Phase de tests actifs 3 : tests sur la gestion des sessions à travers les cookies

2.1 - SM-001 : Structure des cookies

Ce premier point est en fait une prise d'information sur la façon dont sont créés et utilisés les cookies. Mieux comprendre le fonctionnement permet au moins de mieux préparer les attaques qui suivent et au mieux de trouver de premières vulnérabilités.

1/ Ouvrir un certain nombre de sessions faisant intervenir les cookies à analyser (NB : il est possible de s'aider d'un outil comme Cookie Digger pour les étapes qui suivent).

• Combien de cookies sont générés pour ouvrir une session ? Quand ? Comment ? Sont-ils modifiés dans le cadre de la session ?
• Les cookies eux-mêmes révèlent-ils des informations intéressantes ? (notamment le Session ID)
• Les données contenues dans les cookies sont-elles chiffrées ? Si oui, l'algorithme utilisé est-il fiable ?
• La génération des Sessions ID est-elle prédictible ou réellement aléatoire ?

2/ Reverse engineering des cookies.

• Est-il possible de créer un cookie valide ?
• Est-il possible de modifier un paramètre contenu dans le cookie ? (ex : Admin=No que l'on changerait en Admin=Yes).
• Que se passe-t-il en cas de modification du cookie ? (suppression / remplacement ou ajout de caractères) ?
• Quels est l'ensemble des caractères utilisés ?

3/ Manipulation des cookies.

• L'ID est-il présent en clair ?
• Sinon, peut-il être deviné ? (ex : algorithme trop simple)
• Sinon, est-il résistant aux attaques de type Brute-Force ? (NB : cf. Cookie Digger)

2.2 - SM-002 : Les attributs des cookies

Les cookies les plus critiques doivent comporter un certain nombre de flags et ceux-ci doivent être correctement configurés :

• Le flag secure (impose la transmission via un tunnel chiffré comme SSL) ;
• Le flag HTTP-Only (pour se prémunir contre certaines attaques de type XSS) ;
• Le flag Domain doit être présent et le plus précis possible ;
• De même pour le flag Path (i.e. différent de "/") ;
• De même pour le flag expires doit être configuré pour éviter le rejeu.

2.3 - SM-003 : Fixation des cookies

Admettons qu'un même cookie puisse être réutilisé pour ouvrir une session, le récupérer d'une manière ou d'une autre donne un accès, voir l'accès d'un autre utilisateur.

• Il suffit de générer un cookie via une requête GET sur le site cible.
• Ensuite, on réutilise ce cookie avec une requête POST.

Par exemple, faites un GET sur le site blogspot.com :

telnet www.blogspot.com 80
GET / HTTP/1.0

Ces opérations peuvent être effectuées via un proxy local (Burp, Paros, Webscarab, ...).


2.4 - SM-004 : Exposition des variables (cookie, session-ID, ...)

1/ Tenter de se connecter via un session HTTP. Les cookies sont-ils systématiquement générés via un protocole chiffré ? (e. g. HTTPS). La partie authentifiante est-elle renouvelée à chaque authentification ? Sinon, il y a un risque de rejeu...

2/ La version 1.1 du protocole HTTP est-elle implémentée ? Elle permet l'interprétation de l'attribut cache avec l'argument no-cache évite la réutilisation du cookie (cf. image ci-dessus).

3/ La génération des cookies se fait-elle à travers la méthode POST ? Cette dernière est moins vulnérables que la méthode GET.


2.5 - SM-005 : Attaque CSRF

Ce post n'a pas pour ut d'expliquer cette attaque en détail mais le lecteur curieux trouvera des informations sur le site Wikipedia de nouveau.
Le test peut être mener en cinq étapes :

1/ Trouver une URL valide qui lance l'action souhaitée (ex : www.cible.com/administrative_task) ;
2/ Créer une page HTML contenant cette URL (lien HTTP, image, ...) ;
3/ Assurez-vous que l'utilisateur est actuellement loggé à l'application (et donc que sa session est ouverte) ;
4 / Trouvez un moyen de faire cliquer l'utilisateur sur le lien (1/) présent sur votre page (2/) ;
5/ Vérifier que la commande a bien été exécutée.

Le but est donc que la commande que vous souhaitez exécuter le soit par l'utilisateur lui-même avec sa session quand vous n'avez pas les accès nécessaires.


La suite au prochain épisode ...