Projet individuel 2 - Analyse d`un site web

1
Projet individuel 2 - Analyse d’un site web
Alexandre Hauet - SINF10PM
C
I.
I NTRODUCTION
E présent document rapporte l’analyse d’un site
web dans le cadre du cours LINGI1341 - Réseaux
informatiques de l’Université catholique de Louvain.
Cette étude porte sur le site www.imdb.com et comprend
trois parties qui analysent premièrement les requêtes
Http reçues et envoyées, deuxièmement son DNS et
finalement, l’impact de TCP sur les performances de ce
site.
Le site Internet Movie Database est une base de données
en ligne sur le cinéma mondial, sur la télévision, et
secondairement sur les jeux vidéo. Il a été acheté en
1998 par Amazon. Cette information pourrait expliquer
certains résultats obtenus.
D
II.
R EQU ÊTES H TTP
ANS cette section, les différentes analyses seront
basées sur deux scénarios :
l’accès à la page principale du site
l’accès à la fiche d’un film
Chacun des scénarios a été répété 10 fois pour
les navigateurs web suivants : Google Chrome,
Firefox et Internet Explorer1 , afin de pouvoir comparer
les différentes données obtenues pour chaque navigateur
mais également pour observer s’il est possible d’obtenir
des résultats différents concernant un même navigateur.
•
•
A. Requêtes et domaines
Nous pouvons remarquer, comme indiqué dans le
tableau ci-dessous, que le nombre de requêtes varie à
chaque fois et entre chaque navigateur.
1
2
3
4
5
6
7
8
9
Chrome 146 161 148 149 154 149 148 149 152
Firefox 145 142 150 145 144 143 150 148 140
IE
163 163 166 165 165 160 164 165 165
10
144
155
164
supplémentaire : cache.btrll.com, différent des deux
autres navigateurs. D’autre part, Firefox, Chrome et
Internet Explorer accède respectivement 53, 56 et 68 fois
au domaine ia.media-imdb.com mais il est difficile de
justifier concrètement cette différence.
En ce qui concerne la différence du nombre de
requêtes au sein d’un même navigateur, celle-ci est
principalement expliquée par l’accès au domaine fls-na.
amazon.com. En général la requête suivante http://fls-na.
amazon.com/1/batch/1/OP est appelée deux ou sept fois.
Cependant, il arrive parfois que le service http://fls-na.
amazon.com/1/display-ads-cx/1/OP soit, quant à lui, appelé cinq fois, il semble agir comme un parseur mais son
rôle reste très obscur.
B. Différents fichiers téléchargés
Différents types de fichier sont téléchargés. Voici les
types répertoriés :
1) application/javascript
2) application/x-javascript
3) image/gif
4) image/jpeg
5) image/png
6) text/css
7) text/html
8) text/javascript
9) text/plain
En observant la liste précédente, nous remarquons que
les fichiers javascript envoyés peuvent être de trois types
différents. Selon les normes RFC2 , l’utilisation correcte
est application/javascript, text/javascript étant obsolète.
La notation application/x-javascript jusqu’au moment où
elle est normalisée, comme dans le cas présent, peut être
aussi considérée comme obsolète.
moy.
151.1
145.1
164
TABLE I: Nombre de requête pour accéder à www.imdb.
com
Les différentes variations peuvent être expliquées
par le fait qu’Internet Explorer accède à un domaine
Fig. 1: Graphique représentant les différents types de
contenus téléchargés
1
Google Chrome Version 39.0.2171.95 m, Mozilla Firefox 34.0.5
& Internet Explorer 11 Version : 11.096000.17498
2
http://www.rfc-editor.org/rfc/rfc4329.txt
2
Quand on observe le graphique précédent représentant
la proportion respective des différents types de fichiers
téléchargés, la plupart d’entre eux sont des images. Ce
qui semble tout à fait normal car ce site utilise beaucoup
d’images. Mais en regardant plus attentivement, nous
remarquons que certaines d’entre elles sont simplement
des images d’un 1x1 pixel. Elles sont appelés les pixels
espions et permettent de collecter de l’information sur
les utilisateurs.
Un pixel espion est une image numérique transparente
de petite taille qui rassemble des informations sur les activités de l’utilisateur. Il permet à un service de collecter
des données lorsque l’image est téléchargée.
En pratique sur le site, les données sont collectées via
l’en-tête des requêtes grâce aux champs Cookie, Referer
par exemple comme semble le faire le service fls-na.
amazon.com abordé précédemment.
C. HTTP request headers
Au sein des en-têtes des requêtes HTTP, il existe des
différences selon le navigateur utilisé :
1) Chrome:
Nous observons pour certaines requêtes l’apparition du
champs X-Client-Data. Il ne contient aucune information
personnelle et ne fait que strictement décrire l’état de
l’installation du navigateur lui-même3
On aperçoit également que Chrome accepte une
troisième méthode de compréhension des paquets http
: SDCH (nldr : les deux autres étant gzip et deflate).
Google propose donc un codage supplémentaire pour
HTTP qui s’appelle SDCH, et qui peut s’ajouter avant
gzip ou deflate.
2) User-Agent:
Le user agent est un code envoyé par chaque navigateur
web lors d’une connexion à un serveur. Le code permet
à un site web de savoir, entres autres, quel navigateur
et quel système d’exploitation sont utilisés par un internaute.
Nous pouvons remarqué, comme indiqué dans le
tableau suivant, que les User-Agents des navigateurs sont
différents :
Chrome Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Firefox Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101
Firefox/34.0
I.E. Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like
Gecko
Ces résultats sont assez intriguants car on observe que
les différents navigateurs semblent se faire passer pour
Mozilla.
3
Selon le Livre blanc sur la confidentialité dans Google Chrome
Il apparait que pour des raisons historiques, les navigateurs aient été contraints de mentir dans leurs User
Agents4 .
D. HTTP reponse headers
De nombreux champs dans les requêtes ne sont pas
standards. Voici une liste avec une brève description de
ceux-ci :
a) x-amz-cf-id: Contient une chaı̂ne cryptée qui
identifie une demande d’aide ou de dépannage. Elle est
utilisée pour les requêtes venant du serveur Amazon
Cloudfront.
b) x-amzn-RequestId:
Valeur
créée
par
ADM(Amazon Device Messaging) qui identifie la
requête. En cas de problème avec ADM, Amazon ne
peut utiliser cette valeur pour retrouver la requête.
c) x-fb-debug: Identifiant qui permet à Facebook de
retrouver plus simplement une requête lors d’un rapport
de bug.
d) x-cache: Indique si la cache provient d’un proxy
: Hit pour oui et Miss pour non.
e) x-cache-hits: Indique si l’objet demandé se
trouve dans le cache.
f) x-connection-hash: Remplace X-Transaction
g) x-content-type-options: Empêche le navigateur
de faire MINE sniffing. MIME-type sniffing permet au
navigateur de déduire les types des fichiers. La valeur de
cette en-tête est toujours à nosniff
h) x-frame-options: Ce champ pour but d’empêcher
le navigateur d’ouvrir une page web dans une iframe.
Il peut prendre les valeurs : DENY, SAMEORIGIN et
ALLOW-FROM.
i) x-response-time: Permet d’afficher la durée de la
réponse en millisecondes.
j) X-N: Permet d’augmenter la taille de l’en-tête
HTTP afin d’éviter certains bugs.
k) x-Served-By: Indique quel serveur a alimenté
Varnish. Varnish est un serveur de cache HTTP utilisé
par exemple par Twitter.
l) x-timer: Fournit des informations sur le voyage
d’une requête du début à la fin. La valeur attribuée à cette
en-tête est constituée de trois parties. Une première partie
qui commence par s, représente un Unix timestamp du
début de la requête. La seconde section commence par
vs, pour varnish start, qui représente le début du voyage
de la requête ; cette valeur doit être toujours égale à 0.
Et finalement, la dernière partie commence par ve, pour
varnish end, qui représente la longueur des sommes du
trajet.
4
Pour plus d’information, je vous invite à visiter le site suivant
http://letrainde13h37.fr/28/les-user-agents-cest-le-mal/
3
m)x-transaction: Indique le numéro de la transaction
n) x-xss-protection: ” Xss Protection ” est une protection coté client présente dans la plupart des navigateurs récents. Il s’agit en fait d’un composant, appelé
filtre XSS, chargé d’analyser les réponses HTTP afin
de détecter des comportements suspects typiques d’une
attaque par XSS réfléchi. Le filtre peut prendre la valeur 0
et 1 qui indique respectivement que celui-ci est désactivé
ou activé. Lorsque le filtre est actif, il existe le mode
“block” qui en cas de détection affichera uniquement
# comme rendu. Ce dernier en-tête protège d’autres
anomalies, telles que des valeurs de input très longue
et des liens très long anormalement formé.
E. Les cookies
De nombreux cookies sont utilisés à travers le site et
pour des utilisations bien différentes. Ils servent principalement à identifier l’utilisateur. Les cookies sont
utilisés par différents services :
a) Services propres au site:
L’historique des dix dernières pages visités sur le site
(acteurs, films) sont visibles sur la page d’accueil du
site. Cette fonctionnalité utilise les cookies. Lorsqu’une
page est visitée par l’utilisateur, le site va enregistrer
la référence de la page donc de l’acteur ou du film en
mémoire et la lier à l’identifiant attribué au cookie. Il faut
ajouter que ces enregistrements de données sont réalisés
via le domaine i.imdb.com
Il est également possible de gérer cet historique via
l’option ”Manage your history” du site. L’information
souhaitée est supprimée via une requête qui prend
en paramètre l’identifiant du film ou de l’acteur
mais également le cookie afin de pouvoir identifier
l’utilisateur. Nous pouvons voir que la ”suppression” des
données est réalisée par le domaine www.imdb.com
b) Services liés au commerce:
Les cookies peuvent être également utilisés pour collecter
des informations sur l’utilisateur. Lorsqu’il se connecte
au site, un cookie est créé et va permettre d’enregistrer
des informations sur lui. Lorsque l’utilisateur accèdera
à un autre site, ce cookie pourrait être réutilisé afin de
pouvoir mettre en évidence certaines informations.
III.
D
D OMAINE NAME S YSTEM
ANS cette partie de l’analyse, nous allons étudier
le DNS des noms de domaine les plus important utilisés sur le site. L’analyse est réalisée suite aux
résultats obtenus grâce à la commande dig.
A. www.imdb.com
Le serveur du site se trouve à Seattle. Il utilise un
CNAME, en réalité www.imdb.com est un alias vers
us.dd.imdb.com. Il utilise seulement des A records qui
correspondent donc à des adresses IPV4. Le Time to Live
du DNS qui indique le temps que l’information peut être
conservé en cache, est de 10800 secondes. Ce temps est
relativement court car, en général, le TTL est de l’ordre
d’un jour (TTL = 86400 secondes).
Nous pouvons également observer que le site utilise
le load balancing, c’est à dire que la charge de travail
est répartie entre les différents serveurs d’imdb. Par
exemple, lors de l’appel du web service http://www.
imdb.com/profile/recently-viewed/ ajax/deleteItem il va
utiliser l’adresse distante 72.21.203.211 et pour un second appel, il utilisera l’adresse 207.171.162.180.
B. ia.media-imdb.com
C’est à partir de ce domaine que sont téléchargées
les images du site. Le domaine est un alias (CNAME)
pour ia.imdb.com.edgesuite.net qui est lui-même un alias
pour a1886.g.akamai.net. Nous pouvons conclure donc
qu’imdb utilise des serveurs de la société Akamai qui
est une société américaine spécialisée dans la mise à
disposition de serveurs de cache pour les entreprises.
L’utilisation de ce type de serveur pour des images a
tout son sens.
Akamai est un service de content delivery network(CDN) commercial. Un CDN est un réseau
d’ordinateurs reliés à travers internet qui permet un gain
de rapidité grâce à une optimisation du mécanisme de
transmission / livraison des requêtes.
Le TTL du DNS est de 900 secondes ce qui est
encore plus court que le premier domaine. Le domaine
ne semble posséder que des adresses de type A records
(IPv4).
C. g-ecx.images-amazon.com
Le domaine est en réalité un alias(CNAME) pour
d1ge0kk1l5kmd0.cloudfront.ne. Amazon CloudFront est
un CDN tout comme Akamai. Nous pouvons également
le remarquer grâce à l’attribut x-cache de l’entête de la
réponse HTTP :
X-Cache:Hit from cloudfront
On peut observer que le domaine i.imdb.com utilise
le CDN CloudFront.
Le TTL du DNS, d’autre part, est de 60 secondes ce
qui est encore plus court que le premier domaine. Le
domaine ne semble posséder que des adresses de type A
records (IPv4).
4
D. www.facebook.com
Le domaine www.facebook.com est en réalité un
alias pour star.facebook.com qui est lui le CNAME de
star.c10r.facebook.com.
Il est accessible via IPv4 et IPv6. Lorsque nous le
contactons en IPv4, le serveur joint est situé aux ÉtatsUnis et en IPv6, celui-ci se trouve en Irlande.
Le TTL est de 60 secondes, ce qui est relativement
court.
IV. T RANSMISSION C ONTROL P ROTOCOL
URANT cette partie, nous allons utiliser
l’application Wireshark pour nos différentes
analyses.
D
A. Nombre de connexions TCP
Le nombre de connexions TPC établies est différent
pour les navigateurs testés.
Navigateur Nb. connexion
Chrome
6
Firefox
2
I.E.
8
Pour trouver ces données, il faut regarder le nombre
de SYN envoyés lors du chargement de la page.
B. Three way handshake
Durant le three-way handshake, les options négociées
sont la window scale et le MSS (Maximum Segment
Size).
Le client précise dans les options du paquet [SYN]
qu’il souhaite une MSS de 1460 octets et un window
scale de 8.
Le serveur précise dans les options du paquet [ACK,
SYN] qu’il souhaite une MSS de 1440 octets et un
window scale de 6.
C. La fenêtre de congestion
Le Round-trip delay time(RTT) est de 155ms. Le
premier paquet de données (indiqué par [TCP segment
of a reassembled PDU]) arrive à 751ms. Donc entre
751ms et 906ms, 17 paquets de données sont reçus; ce
qui montre que la taille de la fenêtre de congestion est
initialisée à 17.
D. Terminaison d’une connexion
Lors de la terminaison de la connexion TCP avec le
WEB-Serveur du site, nous observons un échange d’une
paire de segments FIN et ACK. La terminaison a lieu
quand plus aucune donnée n’est envoyée.
P
V.
C ONCLUSIONS
OUR conclure cette analyse, le site www.imdb.com
est hébergé sur plusieurs serveurs : un serveur
principal à Seattle où se trouve les web services (les
fonctionnalités du site), les différentes images du site
sont sur le CDN Akamai et la collecte d’informations
est réalisée par i.imdb.com qui est hébergé sur un CDN
Amazon CloudFront.
De nombreuses fonctionnalités Amazon sont présentes
sur le site, ce qui confirme notre intuition exposée dans
l’introduction, via des services comme Amazon Device Messaging, Amazon CloudFront... Amazon utilise
également les cookies d’IMDB.
D’un point de vue personnel, la réalisation de cette
analyse m’a fait découvrir la face cachée des pages d’un
site web. Elle m’a permis de ne plus être un surfeur passif
mais actif et attentif aux données échangées via les sites
visités.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Olivier Bonaventure, Computer Networking : Principles, Protocols and Practice, 2nd edition, 2013.
Amazon CloudFront, http://aws.amazon.com/fr/cloudfront/
HTTP cookie, http://en.wikipedia.org/wiki/HTTP cookie
How to test initcwnd? http://www.cdnplanet.com/blog/
tune-tcp-initcwnd-for-optimum-performance/#howtotest
Internet Movie Database, http://en.wikipedia.org/wiki/Internet
Movie Database
Livre blanc sur la confidentialité dans Google Chrome, https:
//www.google.fr/chrome/browser/privacy/whitepaper.html
Varnish
(software),
http://en.wikipedia.org/wiki/Varnish
(software)