4.7.4 Tester les variables de session exposées (OTG-SESS-004)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

S'ils sont exposé, les jetons de session (Cookie, identifiant de session, champs caché) vont permettre à un attaquant d'usurper l'identité d'une victime et d'accèder frauduleusement à l'application. Il est important que ces jetons soit protégés contre l'espionnage, particulièrement pendant leur transit entre navigateur client et serveurs d'application.

Ici, nous nous concentrons sur la sécurité du transport appliquée au transfert d'identifiant de session sensible, plutôt que de données en général, ce qui peut être plus strict que les données en cache et les politiques de transport des données servies par le site.

En utilisant un proxy personnel, il est possible de vérifier pour chaque requête et réponse :

• Le protocole utilisé (HTTP ou HTTPS)
• Les entêtes HTTP
• Le corps du message (POST, contenu de page)

Chaque fois que les données d'identifiant de session sont transmises entre le client et le serveur, le protocole, le cache, et les directives de confidentialité doivent être examinées. La securité de transport se réfère ici aux identifiants de session transmis en requêtes GET ou POST, au corps des messages, ou autres moyens dans des requêtes HTTP valides.

Comment tester

Tester les vulnérabilités sur le chiffrement et la réutilisation des jetons de session :
La protection contre l'espionnage est souvent assurée par un chiffrement SSL, mais cela peut aussi inclure d'autres canaux ou moyens de chiffrement. Il faut noter que le chiffrement ou le hashage cryptographique de l'identifiant de session doit être considéré séparément du chiffrement du transport, car c'est l'identifiant de session lui-même qui est protégé, pas les données qui peuvent le représenter.

Si l'identifiant de session peut être présenté à l'application par un attaquant pour y gagner accès, alors il doit être protégé pendant sa transmission pour réduire ce risque. Il faut donc s'assurer qu'un chifrement est activé par défaut et appliqué pour toutes les requêtes et réponses où l'identifiant de session est transmis, quelque soit le moyen utilisé (par exemple un champ caché dans un formulaire). De simples vérifications doivent être effectuées, comme remplacer https:// par http:// pendant les échanges avec l'application, ainsi que des modification de formulaires postés pour déterminer si une séparation adéquate est implémentée entre les sites sécurisés et non sécurisés.

A noter que si l'utilisateur est tracé avec son identifiant de session dans une partie non sécurisée (par exemple, noter quels documents publics télécharge un utilisateur), il est essentiel qu'un identifiant différent soit utilisé. L'identifiant de session doit donc est surveillé quand le client accède à des éléments sécurisé ou non sécurisés, pour s'assurer qu'un identifiant différent est utilisé.

Résultat attendu :
Lors de chaque authentification réussie, l'utilisateur doit s'attendre à recevoir :

• Un jeton de session différent
• Un jeton envoyé par un canal chiffré lors de chaque requête HTTP

Tester les vulnérabilités de proxies et de cache :
Les proxies doivent aussi être pris en compte lorsqu'on évalue une application. Dans beaucoup de cas, les clients accèdent aux application via des proxies ou des passerelles (firewalls, ...), fournis par des entreprises, des FAI, ou autres. Le protocole HTTP fournit des directives pour contrôler le comportement des proxies en aval. L'implémentation de ces directives doit aussi être étudiée.

En général, l'identifiant de session ne doit jamais être transmis via un cana non chiffré et ne doit jamais être stocké en cache. L'application doit être véirifiée pour assurer que les transmission d'identifiant de session sont chiffrées par défaut et que ce chiffrage est effectif. De plus, chaque fois que l'identifiant de session est transmis, des directives doivent être en place pour empêcher son stockage en cache intermédiaire et même local.

L'application doit aussi être configurée pour sécuriser les données en cache via HTTP/1.0 et HTTP/1.1 - la RFC 2616 décrit les contrôles appropriés en rapport avec HTTP. HTTP/1.1 fournit un certain nombre de mécanismes de contrôle de cache. Cache-control: no-cache indique qu'un proxy ne doit réutiliser aucune donnée. Alors que Cache-control: Private semble être une directive convenable, elle permet à un proxy non partagé de stocker des données en cache. Dans le cas de web cafés ou autre systèmes partagés, cela représente clairement un risque. Même des stations de travail mono-utilisateurs peuvent voir leur données de session stockée en cache compromises via le système de fichier ou lorsqu'un partage réseau est utilisé. Les caches HTTP/1.0 ne reconnaissent pas la directive Cahce-control: no-cache.

Résultat attendu :
Les directives "Expires: 0" et Cache-control: max-age=0 devrait être utilisées pour renforcer la protection contre l'exposition de données par les caches. Chaque requête/réponse passant l'identifiant de session devrait être examinée pour assure que les directives appropriées sont utilisées.

Tester les vulnérabilités GET & POST :
En général, les requêtes GET ne devraient pas être utilisées, car l'identifiant de session serait exposé dans les logs de proxies ou de firewall. Elles sont aussi bien plus facilement manipulable que les autres types de transport, bien qu'il faille souligner que presque tous les mécanismes peuvent être manipulés par le client avec les outils adéquats. De plus les attaques cross-site scripting ( Cross-site Scripting (XSS) ) sont plus faciles à exploiter en envoyant à la victime des liens spécialement construits. Cela est beaucoup moins évident sir les données sont envoyées par POST.

Résultat attendu :
Tout le code serveur recevant des données en requêtes POST doit être vérifié pour assurer qu'il n'accepte pas aussi les données en GET. Par exemple, la requête POST suivante, générée par une page d'authentification :

POST http://owaspapp.com/login.asp HTTP/1.1
Host: owaspapp.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b 
Accept: */*
Accept-Language: en-us, en
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 
Keep-Alive: 300 
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG 
Cache-Control: max-age=0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34

Login=Username&password=Password&SessionID=12345678

Si login.asp est mal implémentée, il peut être possible de s'authentifier avec l'URL suivante : http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

Les scripts serveur potentiellement non sécurisés peuvent être identifiés en vérifiant chaque requête POST de cette manière.

Tester les vulnérabilités de transport :
Toutes les interaction entre le client et l'application doivent être testées au moins selon des critères suivants :

• Comment les identifiants de session sont-ils transférés ? C'est-à-dire en GET, POST, champs de formulaires (y compris champs cachés)
• Est-ce que les identifiants de sesion sont toujours envoyés sur des canaux chiffrés par défaut ?
• Est-il possible de manipuler l'application pour que les identifiants de session soient envoyés sur des canaux non chiffrés ? C'est-à-dire en remplaçant HTTPS par HTTP
• Quelles directives de contrôle de cache sont-elles emplyées sur les requêtes/réponses contenant des identifiants de session ?
• Est-ce que ces directives sont toujours présentes ? Si non, quelles sont les exceptions ?
• Est-ce que des requêtes GET contenant des identifiants de session sont utilisées ?
• Si POST est utilisé, peut-on le remplacer par GET ?

References

Whitepapers

• RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
• RFC 2616 – Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt