Tester le transport des informations d'identification signifie vérifier que les données d'authentification de l'utilisateur sont transférées via un canal crypté pour éviter d'être interceptées par des utilisateurs malveillants. L'analyse se contente de déterminer si les transports de données non cryptés à partir du navigateur au serveur sont possibles, ou si l'application Web prend les mesures de sécurité appropriées en utilisant un protocole tel que HTTPS. Le protocole HTTPS est construit sur TLS / SSL pour chiffrer les données transmises et faire en sorte que l'utilisateur est dirigé au bon endroit. De toute évidence, le fait que le trafic soit chiffré ne signifie pas nécessairement qu'il est totalement sûr. La sécurité dépend aussi de l'algorithme de chiffrement utilisé et de la robustesse des clés que l'application utilise, mais ce sujet en particulier ne sera pas abordé dans cette section. Pour une étude plus détaillée sur le test de la sécurité des canaux TLS / SSL, vous pouvez vous référer au chapitre « Testing for SSL-TLS ». Ici, le testeur va juste essayer de comprendre si les données que les utilisateurs mettent dans les formulaires Web, par exemple, pour se connecter à un site Web, sont transmises à l'aide de protocoles sécurisés qui les protègent contre un attaquant ou non. Pour ce faire, nous allons examiner divers exemples.

Aujourd'hui, l'exemple le plus courant de ce problème est la page de connexion d'une application web. Le testeur doit vérifier que les informations d'identification de l'utilisateur sont transmises via un canal crypté. Pour se connecter à un site Web, le plus souvent, l'utilisateur doit remplir un formulaire simple qui transmet les données insérées avec la méthode POST. Ce qui est moins évident, c'est que ces données peuvent être transmises en utilisant le protocole HTTP, ce qui signifie d'une manière non sécurisée ou HTTPS qui crypte les données. Pour compliquer encore les choses, il y a la possibilité que le site ait la page de connexion accessible via HTTP (faisant croire que la transmission n'est pas sûr), mais envoie les données via le protocole HTTPS. Ce test est effectué afin de s'assurer qu'un attaquant ne peut pas récupérer des informations sensibles, simplement en reniflant le net avec un sniffer.

Dans les exemples suivants, nous allons utiliser WebScarab afin de capturer mes en-têtes de paquets et les inspecter. Vous pouvez utiliser n'importe quel web proxy de votre préférence..

Supposons que la page de connexion présente un formulaire avec des champs utilisateur, mot de passe, et le bouton soumettre pour s'authentifier et donner accès à l'application. Si l'on regarde l'en-tête de notre demande avec WebScarab, on obtient quelque chose comme ceci:

POST http://www.example.com/AuthenticationServlet HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvVCGdyPkmn3S!
Content-Type: application/x-www-form-urlencoded
Content-length: 64
delegated_service=218&User=test&Pass=test&Submit=SUBMIT

Dans cet exemple, le testeur peut comprendre que le POST envoie les données à la page www.example.com/AuthenticationServlet simplement en utilisant le protocole HTTP. Donc, dans ce cas, les données sont transmises sans cryptage et un utilisateur malveillant pourrait lire notre nom d'utilisateur et mot de passe, simplement en reniflant le net avec un outil comme Wireshark.

Supposons que notre application web utilise le protocole HTTPS pour crypter les données que nous envoyons (ou du moins pour ceux qui ont trait à l'authentification). Dans ce cas l'en-tête de notre requête POST serait semblable à ce qui suit:

POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: language=English; 
Content-Type: application/x-www-form-urlencoded
Content-length: 50
Command=Login&User=test&Pass=test

Nous pouvons voir que la demande est adressée à www.example.com:443/cgi-bin/login.cgi en utilisant le protocole HTTPS. Cela garantit que nos données sont envoyées via un canal crypté et qu'ils ne sont pas lisibles par d'autres personnes.

Maintenant, supposons aue nous ayons une page web accessible via HTTP et que seules les données transmise ensuite à partir du formulaire d'authentification sont envoyées via HTTPS. Cela signifie que nos données sont transmises de manière sécurisée par cryptage. Cette situation se produit, par exemple, lorsque nous sommes sur un portail d'une grande entreprise qui offre diverses informations et services accessibles au public, sans identification, mais qui a aussi une section privée accessible depuis la page d'accueil par le biais d'une connexion. Alors, quand nous essayons de vous connecter, l'en-tête de notre demande va ressembler à l'exemple suivant:

POST https://www.example.com:443/login.do HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com/homepage.do
Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB6pLhjkW6F
Content-Type: application/x-www-form-urlencoded
Content-length: 45
...
User=test&Pass=test&portal=ExamplePortal

Nous pouvons voir que notre demande est adressée à www.example.com:443/login.do utilisant le protocole HTTPS. Mais si nous jetons un regard sur le champ de référence dans l'en-tête (la page à partir de laquelle nous sommes arrivés), celui-ci est www.example.com/homepage.do qui est accessible via HTTP simple. Donc, dans ce cas, nous n'avons pas de serrure à l'intérieur de notre fenêtre du navigateur qui nous dit que nous utilisons une connexion sécurisée, mais, en réalité, nous le sommes par l'envoi de données via le protocole HTTPS. Cela nous assure que personne d'autre ne peut lire les données que nous envoyons.

Dans ce dernier exemple, supposons que l'application transfère les données en utilisant la méthode GET. Cette méthode ne doit jamais être utilisé pour la transmission de données sensibles, telles que le nom d'utilisateur et le mot de passe, car ils sont affichés en clair dans l'URL, ce qui entraîne toute une série de problèmes de sécurité. Ainsi, cet exemple est purement démonstratif, mais, en réalité, il est fortement recommandé d'utiliser la méthode POST à la place. Car quand la méthode GET est utilisée, l'URL qui en fait la demande est facilement accessible et expose vos données sensibles à des fuites d'informations.

GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.example.com/form.html
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
If-None-Match: "43a01-5b-4868915f"

Vous pouvez voir que les données sont transférées en clair dans l'URL, et non dans le corps du message comme avant. Mais il faut considérer que TLS / SSL est un protocole de niveau 5, un niveau inférieur à celui HTTP, donc l'ensemble du paquet HTTP est toujours cryptée et l'URL est illisible pour un attaquant. Ce n'est pas une bonne pratique d'utiliser la méthode GET dans ces cas, parce que l'information contenue dans l'URL peut être stockée dans de nombreux serveurs Web ou serveurs proxy, rendant ainsi vulnérables les références privées de l'utilisateur.

Il convient de voir avec les développeurs de l'application et s'ils sont conscients des différences entre les protocoles HTTP et HTTPS et pourquoi ils devraient utiliser HTTPS pour les transmissions d'informations sensibles. Ensuite, vérifier avec eux si HTTPS est utilisé dans toutes les transmissions sensibles, comme les pages de connexion, afin d'empêcher les utilisateurs non autorisés de lire les données.

• HTTP/1.1: Security Considerations - http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html

• WebScarab