Si le Token de session (cookies, ID de session, Champ masqué) est exposé, il va généralement permettre à un attaquant d'usurper l'identité d'une victime et accéder à l'application de manière illégitime. En tant que tel, il est important qu'ils soient protégés contre les écoutes en tout temps - en particulier pendant le transit entre le navigateur client et les serveurs d'applications

Il convient de faire en sorte que la sécurité des transports s'applique en priorité au transfert de données sensibles d'ID de session plutôt qu'aux données en général, et de façon peut-être plus strictes que les politiques de mise en cache et de transport appliqués aux données servies par le site. En utilisant un proxy, il est possible de déterminer pour chaque demande et chaque réponse:

• Protocole utilisé (par exemple, HTTP vs HTTPS)
• En-têtes HTTP
• Corps du message (contenu par exemple du POST ou de la page)

Chaque fois qu'un ID de Session ID est transmis entre le client et le serveur, le protocole, le cache, et les directives de confidentialité et le corps doivent être examinés. La sécurité des transports fait ici référence aux ID de session passées en GET ou POST, dans le corps de message, ou par d'autres moyens sur les demandes HTTP valides.

La protection contre les écoutes est souvent fournie par cryptage SSL, mais peut incorporer d'autres tunnels de chiffrement. Il convient de noter que le hachage de chiffrement cryptographique ou de l'ID de session doit être considérée séparément du cryptage de transport, car c'est l'ID de session lui-même qui est protégé, et non les données qui peuvent être représentées par celuie-ci. Si l'ID de session peut être présenté par un attaquant lors d'unea demande d'accès, son transport doit être protégé pour atténuer ce risque. Il convient donc de s'assurer que le cryptage de l'ID de session et sa valeur par défaut, appliquée pour toutes demandes ou réponses, soient valides, quel que soit le mécanisme utilisé (par exemple, un champ de formulaire caché). Des contrôles simples telles que le remplacement par http: https: au cours de l'interaction avec l'application doivent être réalisés, avec la modification des posts du formulaire pour déterminer si une séparation adéquate entre les sites sécurisés et non sécurisé est mise en œuvre.

Note: si il y a aussi un endroit dans le site où l'utilisateur est suivi, mais où la sécurité n'est pas présente (par exemple, l'enregistrement des documents publics auxquels l'utilisateur inscrit a accès) , il est essentiel qu'un ID de de session différent soit utilisé. L'ID de session doit donc être contrôlé dés que le client passe d'éléments sécurisés à des éléments non sécurisés afin d'assurer un traitement différent.

Résultat attendu:

Chaque fois que l'authentification est réussie, l'utilisateur doit s'attendre à recevoir:

• Un jeton de session différent
• Un jeton envoyé par un canal chiffré chaque fois qu'ils faitt une requête HTTP

Les procurations doivent également être considérées lors de l'examen de la sécurité des applications. Dans de nombreux cas, les clients pourront accéder à l'application par le biais des entreprises, FAI ou autres mandataires ou passerelles utilisant des protocoles intelligents ( pare-feu par exemple). Le protocole HTTP fournit des directives pour contrôler le comportement des mandataires en aval, et la mise en œuvre correcte de ces directives doivent également être évalués. En général, l'ID de session ne doit jamais être envoyé en clair sur le canal de transport et ne doit jamais être mis en cache. La demande doit donc être examinée afin de s'assurer que les communications cryptées sont à la fois la valeur par défaut et appliquées pour tout transfert d'ID de session. En outre, chaque fois que l'ID de session est passé, les directives doivent être mises en place pour empêcher sa mise en cache par les caches intermédiaires ni même locaux.

L'application doit également être configurée pour sécuriser les données dans les caches à la fois sur HTTP/1.0 et HTTP/1.1 - la RFC 2616 décrit les contrôles appropriés par rapport à 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 pas réutiliser les données. Mais alors que Cache-Control: Private semble être une directive appropriée, elle permet à un proxy de mettre en cache les données partagées. Dans le cas des web-cafes ou autres systèmes partagés, cela présente un risque évident. Même avec les stations de travail mono-utilisateur l'ID de session mis en cache peut être exposé par un système de fichiers compromis ou lorsque des magasins en réseau sont utilisés. HTTP/1.0 ne reconnait pas l'option Cache-Control: no-cache.

Résultat attendu:

Les directives “Expires: 0” et Cache-Control:max-age=0 devraient être utilisées pour mieux garantir les caches et ne pas exposer les données. Chaque donnée de requête / réponse délivrant un ID de Session doivent être examinés pour s'assurer que les directives de cache appropriées sont en cours d'utilisation.

En général, les requêtes GET ne doit pas être utilisées, car l'ID de session peut être exposé dans les journaux du proxy ou pare-feu. Ils sont aussi beaucoup plus faciles à manipuler que les autres types de transport, mais il convient de noter que presque tous les mécanismes peuvent être manipulés par le client avec les bons outils. En outre, les attaques Cross-Site Scripting (XSS) sont les plus faciles à exploiter en envoyant un lien spécialement conçus pour la victime. C'est beaucoup moins probable si les données sont envoyées à partir du client dans un POST.

Résultat attendu:

Tout le code côté serveur traitant des données de requêtes POST doit être testé pour s'assurer qu'il n'accepte pas les données si elles sont envoyées en tant que GET. Par exemple, considérons la requête POST suivante généré par une page de connexion.

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

Les scripts côté serveur potentiellement dangereux peuvent être identifiés en vérifiant chaque pose de cette façon.

Toutes les interactions entre le client et l'application devraient êtres testées au moins selon les critères suivants.

• Comment sont transférées les ID de session? par exemple, GET, POST, Champ du formulaire (y compris les champs masqués)
• Les ID de session sont toujours envoyés par un transport chiffré par défaut?
• Est-il possible de manipuler l'application pour envoyer des identifiants de session non chiffrée? par exemple, en changeant HTTP vers HTTPS?
• Quelles directives cache-control sont appliquées à des demandes / réponses passant des ID de session?
• S'agit-il de directives toujours présentes? Si non, quelles sont les exceptions?
• Des requêtes GET incorporant l'ID de session sont-elles utilisées?
• Si le POST est utilisé, peut-il être interchangé avec GET?

• RFC 2109 & RFC 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