Rapport Sécurité Navigateurs 2009

Transcription

FRANCE TELECOM – ORANGE R&D – TELECOM SUD PARIS
La sécurité des
navigateurs Web
Projet de fin d’études
Aucher Arnaud
Esseghir Najat
22/06/2009
Ce document est notre rapport de projet de fin d’études dans le domaine de la sécurité des systèmes
& réseaux. Il couvre l’ensemble des problématiques de sécurité rencontrées dans le monde des
navigateurs Web. Il se base donc sur une étude approfondie des différentes solutions présentes sur
le marché de l’Internet au cours de l’année 2009.
La sécurité des navigateurs Web 2009
Table des matières
Introduction ............................................................................................................................................................................... 4
Les attaques sur le navigateur .................................................................................................................................................... 5
Quelles en sont les motivations ? .......................................................................................................................................... 5
Comment est-ce que les pirates procèdent ? ........................................................................................................................ 5
L'exploitation des bugs du navigateur .............................................................................................................................. 5
L'ajout de code malveillant dans des pages Web ............................................................................................................. 6
L'usurpation d'URL ............................................................................................................................................................ 6
Le vol de cookies ............................................................................................................................................................... 6
Quelles sont les attaques connues ? ..................................................................................................................................... 6
Le Cross-Zone Scripting..................................................................................................................................................... 6
Le Cross-Site Scripting (XSS) .............................................................................................................................................. 7
La sécurité dans les navigateurs Web ........................................................................................................................................ 9
Concepts de base des navigateurs web ................................................................................................................................. 9
HTTP ................................................................................................................................................................................. 9
HTML ................................................................................................................................................................................ 9
DOM ................................................................................................................................................................................. 9
JavaScript ........................................................................................................................................................................ 10
Les cookies ...................................................................................................................................................................... 10
Les contrôles ActiveX ...................................................................................................................................................... 11
Les mécanismes standards .................................................................................................................................................. 11
La Same Origin Policy ...................................................................................................................................................... 11
Le filtrage par port et par URL ........................................................................................................................................ 13
La limitation des connexions simultanées ...................................................................................................................... 13
Restriction de cookie au tiers. ........................................................................................................................................ 14
Authentification de http ................................................................................................................................................. 14
La défense contre l’insertion de script ........................................................................................................................... 14
Mozilla – Firefox ....................................................................................................................................................................... 15
Comment traite-t-on les questions de sécurité ? ................................................................................................................ 15
Quelles sont les implications pour le navigateur ? .............................................................................................................. 16
Chrome JS ....................................................................................................................................................................... 16
La Same Origin Policy et le JavaScript ............................................................................................................................. 16
La Signed Script Policy .................................................................................................................................................... 17
Comment l’utilisateur peut-il gérer la sécurité ? ................................................................................................................. 18
Les Configurable Security Policies................................................................................................................................... 18
Configurer les politiques globales ................................................................................................................................... 18
Politiques par zone ......................................................................................................................................................... 19
Les niveaux de sécurité ................................................................................................................................................... 19
Get & Set ........................................................................................................................................................................ 20
Syntaxe complète pour les références ........................................................................................................................... 20
Désactiver tout Javascript pour un site........................................................................................................................... 21
Peut-on recourir à un certificat maître comme tiers de confiance? .................................................................................... 21
1
Le certificat maître.......................................................................................................................................................... 21
L'API ................................................................................................................................................................................ 22
Un modèle reposant sur 2 certificats.............................................................................................................................. 22
Comment gérer les privilèges associés à des fichiers ? ....................................................................................................... 23
Définition ........................................................................................................................................................................ 23
Fonctionnement ............................................................................................................................................................. 23
Limitations ...................................................................................................................................................................... 24
Quelle est la politique de traitement des failles de sécurité ? ............................................................................................ 24
Quelles sont les vulnérabilités connues sous Firefox 3.0 ? .................................................................................................. 24
Différents impacts .......................................................................................................................................................... 24
Exemples de bugs de sécurité résolus dans Firefox 3.0.11 ............................................................................................. 25
Microsoft – Internet Explorer ................................................................................................................................................... 26
La version 6.......................................................................................................................................................................... 26
La méthodologie SDLC .................................................................................................................................................... 26
Microsoft Security Response Center .............................................................................................................................. 26
Le service Windows Update ........................................................................................................................................... 27
Les zones de sécurité ...................................................................................................................................................... 27
Microsoft Internet Explorer frame restrictions............................................................................................................... 28
IE 6 & Windows XP SP2........................................................................................................................................................ 28
Local Machine Zone Lockdown ....................................................................................................................................... 28
Zone Elevation Blocks ..................................................................................................................................................... 28
Les structures MIME ....................................................................................................................................................... 28
La prévention de l’usurpation d’adresses ....................................................................................................................... 29
La gestion des téléchargements sécurisés ...................................................................................................................... 29
Le blocage des fenêtres pop up. ..................................................................................................................................... 30
La gestion des compléments .......................................................................................................................................... 30
Microsoft Windows AntiSpyware (Beta)......................................................................................................................... 30
Internet Explorer 7 .............................................................................................................................................................. 31
Windows Defender ......................................................................................................................................................... 31
Le filtre anti-hameçonnage ............................................................................................................................................. 31
Les certificats SSL ............................................................................................................................................................ 31
La navigation par onglets ................................................................................................................................................ 32
La désactivation des contrôles ActiveX ........................................................................................................................... 32
La protection contre les logiciels malveillants ................................................................................................................ 32
Protection des données à caractère personnel .............................................................................................................. 32
IE7 sous Vista .................................................................................................................................................................. 32
IE8 ........................................................................................................................................................................................ 32
La rapidité, critère de réussite ........................................................................................................................................ 33
Des onglets avec des mémoires isolées .......................................................................................................................... 33
Navigation privée sans trace........................................................................................................................................... 33
Le filtre SmartScreen ...................................................................................................................................................... 34
Le filtre de script intersites (XSS) .................................................................................................................................... 34
2
La prévention de l'exécution des données (PED) ............................................................................................................ 35
La barre d'adresse intelligente et l’historique ................................................................................................................ 35
La restauration après crash ............................................................................................................................................ 35
Les autres navigateurs .............................................................................................................................................................. 36
Google – Chrome v 2.0 ........................................................................................................................................................ 36
Présentation ................................................................................................................................................................... 36
La sandbox ...................................................................................................................................................................... 36
Les black lists .................................................................................................................................................................. 37
Les failles découvertes .................................................................................................................................................... 37
Apple – Safari v 4.0 .............................................................................................................................................................. 38
Présentation ................................................................................................................................................................... 38
Les éléments de sécurité ................................................................................................................................................ 38
Les failles découvertes .................................................................................................................................................... 39
Opera v 9.64 ........................................................................................................................................................................ 39
Présentation ................................................................................................................................................................... 39
La sécurité....................................................................................................................................................................... 39
Les failles ........................................................................................................................................................................ 40
La nouvelle plateforme ................................................................................................................................................... 40
Comparatif des navigateurs ..................................................................................................................................................... 41
L’avis général ....................................................................................................................................................................... 41
Firefox Version 3 .................................................................................................................................................................. 41
IE Version 8 .......................................................................................................................................................................... 42
Safari Version 3 .................................................................................................................................................................... 42
Opera Version 9.5 ................................................................................................................................................................ 42
Chrome ................................................................................................................................................................................ 42
Comparaison des vulnérabilités .......................................................................................................................................... 43
Le Web 2.0 et ses nouvelles menaces ...................................................................................................................................... 45
Introduction au Web 2.0 .................................................................................................................................................... 45
Le Web 2.O et les nouvelles technologies ......................................................................................................................... 45
Les technologies coté client .......................................................................................................................................... 46
Protocol et chaine de communication ......................................................................................................................... 46
Les structures de données sur Internet .......................................................................................................................... 46
L’environnement applicatif ............................................................................................................................................. 46
Le Web 2.0 et les failles de sécurité ................................................................................................................................... 46
L’injection de code ( Html, XML, …).............................................................................................................................. 47
Manipulation de code ( JavaScript, …) ......................................................................................................................... 47
Cross site Scripting ....................................................................................................................................................... 47
Cross site Request Forgery ........................................................................................................................................... 47
Conclusion ................................................................................................................................................................................ 48
Bibliographie ............................................................................................................................................................................ 49
3
Introduction
Dans le cursus de notre formation nous avons été amenés à réaliser une étude approfondie sur une
thématique d’actualité ayant trait à la sécurité des systèmes ou réseaux. Nous avons alors choisi de
nous orienter sur un projet en partenariat avec une entreprise, nous garantissant un réel apport de
connaissances et transformant cette mission en un challenge professionnel. Le sujet qui nous a été
proposé est celui de la sécurité dans les navigateurs Web. Les questions qu’il soulève ainsi que les
nouvelles solutions apportées par les différents acteurs avaient retenu l’attention des chercheurs
d’Orange Labs.
Parmi les attaques portées à l’encontre du poste client, la tendance actuelle des cybercriminels est
de concentrer leur frappe sur le navigateur Web. Plusieurs raisons viennent justifier ce choix,
notamment le verrouillage des systèmes d’exploitation, l’accroissement du nombre d’antivirus et des
solutions de sécurité. Ces différents mécanismes ont accru la complexité de la réalisation d’attaques
directes visant le poste client. Le Bureau est donc entrain de devenir une réelle forteresse résistante
aux attaques frontales. C’est pourquoi les pirates ont déporté leur point d’entrée sur le navigateur et
les technologies Web associées. Le nombre potentiel de victimes est associé au nombre de machines
actuellement connectées à Internet et munies d’un navigateur, autrement dit la majorité des
Internautes.
Dans ce document vous trouverez la synthèse de nos recherches, qui ont porté sur l’ensemble des
navigateurs présents sur le marché au cours de l’année 2009. Nous avons essayé de rester le plus
neutre possible et de couvrir la majorité des outils de navigation disponibles sur Internet. Nos
sources proviennent des différentes documentations techniques ou marketing dispensées par les
éditeurs, des rapports et études de sécurité réalisés par des cabinets experts en sécurité…
Dans un premier temps nous reviendrons sur les motivations et le mode opératoire des attaquants.
Nous dresserons une liste exhaustive des différents procédés d’attaque : l’exploitation de bug, l’ajout
de code malveillant dans les pages Web ou encore l’usurpation d’adresse URL. Nous approfondirons
alors avec la méthodologie des attaques les plus communes : le Cross Zone Scripting et le Cross Site
Scripting…
Nous étudierons ensuite les concepts de base et les technologies associées à la navigation Web. Nous
traiterons notamment du mécanisme de cookies, des scripts (Javascript), des objets DOM, de la
programmation Html et du standard Http. Nous pourrons évoquer les différentes solutions de
sécurité implémentées sur les navigateurs telles que la Same Policy Origin, le filtrage, les sondes de
surveillance, la restriction des cookies, l’authentification Http…
Nous parviendrons alors à l’analyse détaillée de chaque navigateur : Firefox, Internet Explorer,
Chrome, Safari, Opera. Vous trouverez pour chacun de ces navigateurs une présentation intégrant
leur positionnement sur le marché, les points forts qui les caractérisent… Nous nous focaliserons sur
le management de la sécurité intégré dans ces navigateurs, nous y soulignerons les avancées et les
points faibles de chaque éditeur. Nous aboutirons au comparatif des vulnérabilités et de fiabilité des
navigateurs Web.
Enfin, nous évoquerons les concepts de base associés aux technologies du Web 2.0 : les protocoles,
les formats d’échange des données et l’environnement applicatif. Nous exposerons alors les
différents enjeux de sécurité et les nouvelles menaces associées telles que le Cross Site Request
Forgery.
4
Les attaques sur le navigateur
Quelles en sont les motivations ?
Il existe de nombreux facteurs qui suscitent l’attrait des cybercriminels, les amenant à prendre pour
cible le navigateur d'un internaute. La principale motivation d’un attaquant est de pouvoir exécuter
un code arbitraire sur le système de la victime, afin de contrôler sa machine. Il obtient alors l'accès
au système de fichiers et est ainsi capable de récupérer toutes les informations stockées sur l’hôte
distant. On parle du vol des données personnelles (fichiers locaux, mots de passe, informations
bancaires), ce qui est une source réelle de revenus pour les mafias.
Aussi, l’utilisateur doit faire face à de possibles modifications ou corruptions de fichiers réalisées par
des virus, vers ou autres chevaux de Troie. Pour cela, l’attaquant manipule sa victime en usant de
Social Engineering et l’incite à télécharger puis exécuter d’elle-même un contenu malveillant. Le
navigateur est alors utilisé comme un simple moyen de transport de l’attaque.
Un dernier enjeu bien moins vertueux est de porter atteinte à l'image de marque d'une entreprise.
L’attaquant cible le site Web de sa victime puis, le compromet au travers d’injection de codes. On
parle de défacement de site, ce procédé peut gravement impacter la notoriété d’une société.
Récemment, la protection accrue des postes de travail a déporté l’attention des attaquants sur les
failles de sécurité associées au navigateur Web. Internet étant aujourd’hui la source d’accès universel
à l’information, la grande majorité des clients possède un navigateur. Le nombre potentiel de
victimes est donc suffisamment important pour que les pirates focalisent leur attention sur ce
nouveau marché.
Comment est-ce que les pirates procèdent ?
Il existe différentes manières d'attaquer un navigateur Web parmi lesquels nous retrouvons :
l'exploitation d’erreurs dans le code source d'un explorateur, l'ajout de code malveillant dans des
pages Web et l'usurpation d'URL. En utilisant ces procédés, les attaquants cherchent à positionner le
navigateur dans un état inattendu, voir instable pour en obtenir le contrôle.
L'exploitation des bugs du navigateur
Il existe de nombreux types d'exploits tirant avantage des erreurs de programmation du navigateur,
des propriétés des protocoles Internet, ou combinant les deux afin de créer une exposition unique du
système.
Un exploit populaire est de pirater la page d'accueil de la victime, de la remplacer par celle du pirate
et d’en complexifier la réinitialisation par l'utilisateur. De même, il est fréquent de rencontrer des
attaques ajoutant des entrées publicitaires non sollicitées (ex: sites pornos) à la barre des favoris.
Un autre exploit consiste à exploiter la confiance inhérente de l’utilisateur envers le modèle de
sécurité de son navigateur Web, qui en présence de permissions inadéquates, autorise l'exécution
d’un contenu malveillant apparaissant fiable.
Le plus souvent les codes d’attaques reposent sur des vulnérabilités déjà présentes au sein du
navigateur : erreur de conception, comportement inattendu... D’autres méthodes exploitent la
complexité des interactions entre les plugins et le navigateur. En effet, le plus souvent ces
programmes propriétaires requièrent des privilèges de haut niveau pour fonctionner. Mais cela
contribue à rendre le navigateur plus sensible aux attaques.
5
L'ajout de code malveillant dans des pages Web
Un attaquant peut inclure un code exécutable ou des scripts sur un site Web préalablement
compromis. Sa mission consiste alors à convaincre l'utilisateur de télécharger puis d’exécuter les
contenus malveillants. Certains codes ou scripts interprétés peuvent réellement améliorer
l'ergonomie de la navigation, toutefois leur usage par un administrateur peu scrupuleux est une faille
non négligeable.
Les scripts utilisent des technologies Web : Html, JavaScript, ActiveX, Java, Flash, ... Individuellement
un contenu Html ou Javascript est inerte, même s’il peut dans certains vieux navigateurs créer des
crashs. Mais combiné avec un code malveillant ActiveX ou Java, il peut potentiellement faire planter
le navigateur, et parfois même l'ordinateur associé.
L'usurpation d'URL
Cette attaque implique préalablement la création d'un site Web similaire à celui de la victime qui doit
être connu et favorable au business. L'usurpation d'URL est communément utilisée par les Phishers
(attaquants collectant les données confidentielles des victimes afin de voler leur identité) qui
trompent les utilisateurs en leur faisant visiter des pages Web supposées appartenir à des sites
légitimes d'entreprises. Les attaques par Phishing utilisent donc des URL usurpées de sites Web,
typiquement ceux de commerces en ligne, de banques, ... et incitent la victime à saisir ses
informations confidentielles (mots de passe, numéros de compte).
Le vol de cookies
Les cookies transitent généralement en clair sur le réseau. Un attaquant peut écouter le trafic sur le
réseau et voler les cookies de ses victimes. Il obtient alors l’accès à l’ensemble des informations qu’ils
contiennent. Les cookies peuvent donc être considérés comme une brèche dans la confidentialité
des communications. Dans un premier temps, le vol des données stockées porte atteinte à la vie
privée de ses victimes. Mais le pire provient de ce que certains sites mal sécurisés conservent dans
les cookies des informations relatives à la session utilisateur. Le vol de cookie permet alors de
récupérer les informations nécessaires pour la phase d’authentification au site Web.
Quelles sont les attaques connues ?
Le Cross-Zone Scripting
Il s'agit d'un exploit du navigateur profitant d'une vulnérabilité dans les solutions à base de zones de
sécurité. Cette attaque permet à des scripts contenus dans des zones non privilégiées de s’exécuter
avec les permissions d'une zone privilégiée. La vulnérabilité peut provenir d'un bug du navigateur,
d'une erreur de configuration ou encore d'une vulnérabilité de type Cross-Site Scripting. Nous
reviendrons plus en détail sur l'origine du concept de zones, dans la suite de ce document.
Dans la simulation suivante, nous allons étudier une attaque par Cross-Zone Scripting ciblant la zone
de la machine locale. Il s’agit d’un exemple de code Html qui illustre une tentative naïve d'exploit.
<HTML>
<IMG SRC="attaque.gif">
<SCRIPT SRC="file://C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\attaque.gif">
</HTML>
Ce code Html tente de faire charger le fichier « attaque.gif » dans le cache, en utilisant une référence
IMG SRC. Puis le drapeau SCRIPT SRC est utilisé pour tenter d'exécuter ce script depuis la zone de la
machine locale, en localisant le fichier présent dans le cache.
6
Notre seconde simulation met en forme une attaque de type Cross-Zone Scripting ciblant la zone
associée à l’intranet local. Le scénario est le suivant :
 Un attaquant connaît une vulnérabilité de type Cross-Site Scripting localisée à l'adresse
http://intranet.example.com/xss.php
 Un grand nombre d'utilisateurs de http://intranet.example.com visite régulièrement
http://www.example.com/ où chacun peut ajouter des liens publics.
 L'attaquant ajoute le lien suivant :
http://intranet.example.com/xss.php?<script>alert()</script>
Le résultat de cette attaque est que tout ordinateur considérant intranet.example.com comme
appartenant à la zone d’intranet local sera victime de l'attaque.
Enfin, notre dernier exemple illustre une attaque Cross-Zone Scripting sur la zone associée aux sites
de confiance. Il s’agit d’une faille bien connue d’Internet Explorer : le bug %2f. Considérons l'URL
suivante : http://windowsupdate.microsoft.com%2f.example.com/. Nous supposons aussi que le
domaine windowsupdate.microsoft.com a été préalablement enregistré dans la liste des sites de
confiance. Alors la requête renvoie ses victimes sur le site http://example.com et s’exécute avec les
permissions des sites de confiance.
Le Cross-Site Scripting (XSS)
Cette attaque exploite le fait qu'un site Web compromis puisse charger une page d’un second site au
travers d'une fenêtre (frame) et puisse alors utiliser du JavaScript pour lire-écrire des données sur cet
autre site. Avec le temps, la définition a évolué pour intégrer l'injection de code Html/Javascript dans
une page Web. Ces dernières années, les attaques à base de XSS devancent le nombre d’exploits
basés sur le dépassement de tampon, pour devenir la vulnérabilité de sécurité la plus communément
rencontrée.
Il existe 3 types distincts de vulnérabilités XSS : les attaques à base de DOM, les attaques non
persistantes, et les attaques persistantes.
Type 1. Les attaques à base de DOM
Aussi appelée « Local Cross-Site Scripting », elle est basée sur le modèle d’objets standards
représentant Html ou Xml, appelé « Document Object Model » ou DOM. Le problème induit par ce
type de vulnérabilité se situe à l’intérieur du script exécuté du côté client. Par exemple, si un code
JavaScript accède à un paramètre de requête contenu dans l’URL et qu’il utilise cette information
dans sa propre page web sans l’encoder avec des balises HTML, une brèche XSS apparaîtra puisque la
donnée écrite sera réinterprétée par les navigateurs comme du code HTML pouvant contenir un
script supplémentaire.
En général, l’exploitation de ce type de faille sera assez similaire aux attaques XSS non
persistantes. Il faut tout de même noter qu’à cause de la manière dont Internet Explorer traite les
scripts côté client au travers des objets situés dans la « zone locale », une telle faille peut conduire à
des vulnérabilités d'exécution à distance. En ce cas, l’attaque contourne non seulement les
restrictions inter-domaines habituelles, mais elle met aussi en échec le mécanisme de sécurité
« Sandbox ».
Type 2. Les attaques non persistantes
Il s’agit de la vulnérabilité la plus répandue, elle apparaît lorsque des données fournies par un
client web sont utilisées directement par les scripts du serveur dans le but de produire une page de
7
résultats. Il s’avère que si ces données ne sont pas préalablement vérifiées et sont incluses dans la
page sans encodage avec des balises HTML, alors elles pourront être utilisées pour injecter du code
dans la page dynamique reçue par le navigateur client.
On peut citer l’exemple des moteurs de recherche qui affichent souvent la chaîne recherchée
dans la page de résultat pour rappeler l’objet de la recherche, ou qui intègrent une boîte de texte
pour la réédition de cette chaîne. Quand la chaîne affichée n'est pas encodée, il y a une faille XSS.
Au premier abord, la criticité de cette faille ne paraît pas d’une importance majeure puisque
l'utilisateur peut seulement injecter du code dans ses propres pages. Cependant, en ayant recours à
de l'ingénierie sociale, un attaquant peut amener un utilisateur à suivre une URL piégée. Celle-ci
injectant du code dans la page de résultat, l'attaquant détient alors tout contrôle sur le contenu de
cette page. L'exploitation de ce type de faille nécessitant des notions d’ingénierie sociale, beaucoup
d’administrateurs ont considéré que ces vulnérabilités n'étaient pas très importantes. Il s’agit bien
sûr d’une erreur trop souvent exploitée par les failles XSS.
Type 3. Les attaques persistantes
Elles sont aussi qualifiées de vulnérabilités stockées ou de second ordre, mais elles sont à
l’origine des attaques les plus puissantes. Elles se présentent lorsque des données clientes destinées
à une application Web sont d’abord stockées de façon persistante sur le serveur (base de données,
fichier système, …), puis renvoyées aux utilisateurs au travers d’une page Web, sans être
préalablement encodées via des balises Html. Les forums de discussions sont un exemple classique,
où les utilisateurs sont autorisés à écrire des messages au format Html à destination de la
communauté.
Les attaques XSS persistantes peuvent être plus redoutables que les autres puisque le script
malveillant d’un attaquant sera visualisé plusieurs fois. En effet, une telle attaque peut affecter un
nombre significatif d’utilisateurs, ne nécessitant que peu de Social Engineering et infectant
l’application via un vers spécialiste du XSS.
Les méthodes d'injection varient beaucoup et un attaquant peut même se passer de
l'application Web pour l’exploitation de telles failles. En fait, l’ensemble des données reçues par
l'application (courriers électroniques, Logs système, …) peut être contrôlé par un attaquant. Elles
doivent donc être encodées avant leur restitution dans une page dynamique, autrement une
vulnérabilité XSS pourrait apparaître.
8
La sécurité dans les navigateurs Web
Les mécanismes de sécurité au niveau des navigateurs web ont pour but principal de protéger les
utilisateurs des codes malveillants, sans pour autant sacrifier les fonctionnalités essentielles pour le
bon fonctionnement de certaines applications.
Les niveaux de sécurité web dépendent de la source du contenu et du degré de confiance que l’on
attribue à celle-ci. Ainsi, les utilisateurs ont besoin d’adapter leurs paramètres de sécurité en
fonction de leur environnement de travail.
Concepts de base des navigateurs web
HTTP
Le protocole de base utilisé pour demander et annoter la majorité du trafic Web est appelé Hyper
Text Transfert Protocol (Http). C’est un protocole de communication client-serveur développé pour le
World Wide Web. Son principal but est de permettre un transfert de fichiers (essentiellement au
format HTML), localisés grâce à une chaîne de caractères appelée URL, entre un navigateur : client
Http et un serveur Web.
Le protocole HTTP peut fonctionner sur n'importe quelle connexion fiable, utilise le protocole TCP
comme couche de transport et utilise comme port dédié le port 80 pour se connecter au serveur
Http.
HTML
« HyperText Mark-Up Langage » est un langage de « structuration » dont le rôle est de formaliser
l'écriture d'un document avec des balises de formatage, afin que celui- ci puisse être universellement
compréhensible. Les balises permettent d'indiquer la façon dont doit être présenté le document et
les liens qu'il établit avec d'autres documents.
Le langage HTML permet notamment la lecture de documents sur Internet à partir de différentes
machines, indépendamment du système d’exploitation ou de l’architecture de l’ordinateur. Grâce au
protocole HTTP, il est possible d'accéder via le réseau à des documents repérés par une adresse
unique : l’URL.
DOM
Avec l’évolution du Web et le progrès qu’a connu la programmation côté client, le besoin de
documents Html, facilement accessibles et modifiables a poussé vers une nouvelle technologie
nommée « dynamique HTML » ou Document Object Model.
DOM Object est une interface de programmation de document XML et HTML. Elle définit la structure
logique de ces documents, la manière dont chacun est accessible et peut être modifié. L‘utilisation de
ces modèles de structures facilite énormément l’usage, la modification et la mise à jour des
documents XML et HTML. Les objets DOM permettent aussi de référencer des documents tiers et ce
dans le but de garantir quelques aspects sécuritaires.
Comme spécifié au niveau de la norme W3C, l’objectif principal de ces objets est de fournir une
interface de programmation standard qui pourrait être utilisée par une grande variété
d’environnements et d’applications indépendamment du langage utilisé.
9
JavaScript
Le JavaScript est un langage de scripts incorporés dans un document HTML. Il s’agit d’un langage de
programmation non compilé, orienté objet qui permet d'apporter des améliorations au langage
HTML en permettant d'exécuter des commandes du côté client. Il permet d'ajouter de l'interactivité
aux pages HTML et peut servir à en améliorer le design, à valider des formulaires, à distinguer les
navigateurs ou à créer des cookies.
Le code JavaScript est supporté par tous les navigateurs Web actuels. Son utilisation peut être
activée ou désactivée pour des raisons de sécurité. Toutefois son activation est parfois nécessaire
pour pouvoir accéder à certaines fonctionnalités dans les pages Web visualisées.
Il ne faut pas confondre JavaScript et Java. Contrairement au langage Java, est un langage de
programmation beaucoup plus complexe qui permet de produire des logiciels indépendants de toute
architecture matérielle. Le code JavaScript est directement écrit dans la page Html, c'est un langage
peu évolué qui ne permet aucune confidentialité au niveau des codes, et qui ne nécessite aucune
machine de compilation.
Les cookies
L’avancée très significative du Web vers des applications complexes, requiert de nouveaux éléments
permettant de maintenir la même session crée par un utilisateur pour plusieurs requêtes. Toutefois
l’absence de ces éléments créerait des problèmes de compatibilité et d’implémentation des
mécanismes actuels d’authentification.
Pour résoudre ce problème, Netscape a introduit la notion de cookie http : un paquet de caractères
texte envoyé par le serveur sollicité au client et qui est conservé par celui-ci dans le
paramètre d’entête « SetCookie header ». Il peut l’insérer par la suite dans toutes ses requêtes
auprès du même serveur et il peut aussi accéder au serveur sans avoir besoin de s’authentifier à
nouveau.
Les paramètres clés de ce mécanisme sont :
 La structure d’entête : chaque entête set-cookie envoyé par le serveur consiste en une ou
plusieurs paires Name=value séparées par des virgules, suivies d’un ensemble de paramètres
et mot-clé séparés par des tirets.
 La portée : par défaut, la portée d’un cookie est limitée à toutes les URL de l’hôte courant.
Celle-ci peut aussi être limitée par le paramètre « path= » qui spécifie le chemin où le cookie
doit être envoyé, ou par le paramètre « Domain= » qui liste le groupe des noms DNS
auxquels le cookie est attribué.
 Le Time To Live : chaque cookie, étant conservé dans la mémoire vive et non au niveau du
disque dur, possède une durée de vie limitée par celle de la session du navigateur utilisé. Par
ailleurs un autre paramètre « expires= » peut aussi être spécifié afin de déterminer la date à
laquelle le cookie doit être supprimé.
 L’écrasement de cookie : si un nouveau cookie a les mêmes paramètres : nom, Domain et
path qu’un cookie existant alors le plus ancien est remplacé par le nouveau, toutefois si la
moindre différence existe entre les deux alors ils vont tous les deux coexister et peuvent être
envoyés tous les deux par le client en même temps en tant que deux paires séparées dans
l’entête du cookie.
 Les cookies protégés: quelques cookies peuvent être marqués à l’aide d’un mot clé sécurisé
ce qui implique qu’ils ne peuvent être envoyés que par HTTPS.
10
Les contrôles ActiveX
ActiveX est une bibliothèque de composants utilisables par tous les logiciels Windows notamment
par un navigateur Internet, quel que soit le langage utilisé et quelle que soit la société qui a
développé ce programme. Les contrôles ActiveX permettent à ces programmes d'exécuter
arbitrairement d'autres programmes à l'intérieur d'eux-mêmes. ActiveX est une technologie
propriétaire (Microsoft) qui ne fonctionne qu'avec Internet Explorer et uniquement sous Windows. Il
est donc recommandé aux Webmasters de ne jamais l'utiliser s'ils souhaitent avoir un site
compatible avec tous les navigateurs et avec tous les systèmes d'exploitation (Mac OS, Linux, Unix,
Mainframes).
Les mécanismes standards
Dans cette partie, on va aborder en détails l’ensemble des mécanismes de sécurité implémentés au
niveau d’un navigateur Web afin de traiter les vulnérabilités les plus cruciales et les plus pertinentes.
La Same Origin Policy
Afin de s’adapter aux besoins des utilisateurs, les navigateurs Web actuels permettent aux
utilisateurs d’ouvrir plusieurs fenêtres ou même plusieurs onglets en même temps afin de pouvoir
accéder à plusieurs sites simultanément. Toutefois cette fonctionnalité augmente le risque
d’attaques exploitant le problème de contamination interzone et de double fenêtrage.
Ainsi une politique de sécurité très importante a été implémentée au niveau des navigateurs, afin de
permettre toutes les interactions nécessaires entre les différentes pages d’un même site tout en
empêchant les interférences entre les pages de sites différents.
Dans la pratique cette politique constitue un ensemble de règles qui se ressemblent
superficiellement mais qui ont quelques différences importantes.
Same Origin Policy pour l’accès au document DOM
Le terme “Same Origin Policy” fait généralement référence à un mécanisme qui gouverne la capacité
de JavaScript et d’autres langages de scripts d’accéder aux propriétés et méthodes DOM. Ce
mécanisme s’exécute en respectant les 3 étapes du processus décisionnel suivant :
 Si les protocoles, les hostnames et (pour tous les navigateurs autres qu’IE) les numéros de
port de deux pages en interaction sont identiques, alors l’accès est autorisé sans aucune
autre vérification.
 Une page Web peut donner au paramètre document.domain la valeur de la partie extrême
droite de son hostname (par exemple pour le hostname minet.telecom-sudparis.eu, le
paramètre peut prendre la valeur telecom-sudparis.eu). Si deux pages ont la même valeur du
paramètre document.domain, le même protocole et le même numéro de port alors, dans ce
cas l’accès au document DOM est autorisé.
 Si aucune des conditions ci-dessus n’a été vérifiée, alors l’accès est refusé.
Théoriquement, ce modèle paraît suffisamment robuste pour assurer une séparation efficace entre
des pages de sites différents. Il peut servir comme méthode de sandboxing du contenu
potentiellement risqué, auquel on ne fait pas confiance dans un domaine particulier. Toutefois, il
présente quelques failles importantes :
 N’importe quelle ressource d’un sous domaine du domaine telecom-sudparis.eu, peut opter
pour le même paramètre document.domain=«telecom-sudparis.eu » et par la suite gagner
l’accès à un autre sous domaine auquel il ne devrait pas accéder.
11
 Cette méthode est trop simpliste et ne tient pas compte de tous les cas. Notamment, les cas
suivants :
o Si les utilisateurs sont adressés par des adresses IP et non pas par des noms de
domaines.
o Si l’URL de l’utilisateur n’a pas un hostname significatif qui lui est associé
o Si un seul nom de domaine résout plusieurs adresses IP, cela peut permettre des
attaques de types DNS Rebinding.
Tous ces points ambigus et non traités ont entraîné un certain nombre de soucis de sécurité dans les
navigateurs web.
Same Origin Policy pour les requêtes Http
Tous les navigateurs web actuels fournissent une API JavaScript nommé XMLHttpRequest, à travers
laquelle les scripts font des requêtes Http auprès du site original et reçoivent les données
correspondantes. Ce mécanisme a été mis en place afin de permettre la lecture des réponses XML,
mais il permet aussi la lecture des messages JSON et la compréhension des protocoles de
communication.
Puisque toutes les requêtes envoyées par XMLHttpRequest nécessitent une conservation des cookies
au niveau du navigateur, et du fait que ce mécanisme autorise une meilleure interaction avec le
serveur, un renforcement des contrôles de sécurité à ce niveau s’avère très important. Ainsi, un
ensemble de vérifications en relation avec du XMLHttpRequest a été implémenté au niveau des
navigateurs :
 Vérifier que XMLHttpRequest ne prenne pas en considération le paramètre
Document.domain pour interdire à une tierce partie la possibilité d’échanger des requêtes
inter-domaine avec les sites légitimes.
 Prendre en considération le numéro de port dans le cas du navigateur IE dans la Same Origin
Policy du XMLHttpRequest, contrairement à ce qui est cas dans la celle des accès Dom.
 Utiliser des restrictions supplémentaires sur les protocoles, les champs d’entête et les
méthodes Http afin de détecter toute ambiguïté et d’empêcher toute fausse requête de
s’exécuter au niveau du serveur. Ces restrictions sont spécifiques à chaque navigateur selon
le niveau de sécurité que celui-ci offre à ses utilisateurs.
12
Pour combler les défaillances de la Same Origin Policy, d’autres limitations ont été implémentées au
niveau des navigateurs afin d’adresser plusieurs vulnérabilités et de prévenir plusieurs types
d’attaques.
Le filtrage par port et par URL
La structure de l’URL permet techniquement l’utilisation d’un port TCP non standard dans une
requête. Par conséquent, un attaquant peut facilement mettre un navigateur en interaction
significative avec des services réseaux qui ne sont pas du Http. Ceux-ci n’arriveront pas à interpréter
les données envoyées par le navigateur et pourraient effectuer des opérations indésirables telles que
le routage du trafic SMTP.
Pour éviter ce genre de problème, la majorité des navigateurs modernes dispose d’un mécanisme de
filtrage par port qui bloque l’accès à un certain nombre de ports appartenant à des services réseaux
bien spécifiques.
Pour certains types d’URL, les navigateurs implémentent des restrictions supplémentaires.
 Les sites Web sont généralement interdits de naviguer au niveau des ressources locales en
utilisant le champ file au niveau de l’URL. Ceci est dû aux 3 raisons suivantes :
o Il faut protéger les fichiers temporaires et les caches de données conservés dans des
emplacements facilement prédictibles sur le disque dur et qui ne doivent pas être
corrompus
o De même, il est important d’assurer aux utilisateurs que leurs fichiers et dossiers
critiques ne peuvent être accessibles à des sites auxquels ils ne font pas confiance
o Enfin, pour éliminer le risque potentiel que des balises de types <script> ou <LINK
REL="stylesheet" HREF="..."> puissent accéder à la lecture de certains fichiers de
format contraignant et se trouvant sur le disque dur.
 Pour éviter les injections HTML et les attaques de types Cross Sites Scripting, la majorité des
navigateurs bloquent les différents scenarios qui utilise JavaScript comme illustré dans le
tableau suivant.
La limitation des connexions simultanées
Pour assurer un certain niveau de performances, tous les navigateurs ont la possibilité de traiter
simultanément plusieurs requêtes en instanciant plusieurs sessions de connexions TCP. Toutefois une
demande excessive pourrait entrainer un déni de service sur le serveur web. Donc pour minimiser ce
risque d’abus, le nombre de connexions avec la même cible est généralement plafonné.
13
Restriction de cookie au tiers.
Le concept de restriction des cookies provenant des parties tierces est un mécanisme de sécurité très
intéressant. Pour des raisons de sécurité et pour assurer plus de confidentialité et de respect à la vie
privée des internautes, cette simple amélioration empêche tout sous domaine du domaine principal
de créer des cookies tant que la page concernée est toujours visitée. Ceci a pour but d’empêcher les
contenus externes ou les publicités insérées dans la page par des balises spéciales <IMG>, <iFrame>
ou <Script> de créer de faux cookies identifiant l’utilisateur dans d’autres sites basés sur la même
technologie.
Authentification de http
Le protocole Https, tel que définit dans la RFC2818, permet aux navigateurs et aux serveurs Web
d’établir des connexions TCP chiffrées utilisant le protocole TLS et des certificats à clés publiques
envoyées par les serveurs devant nécessairement s’authentifier auprès des clients Http. L’échange
du trafic chiffré se fait par la suite à travers un tunnel SSL qui permet de protéger les données
échangées de toute interception ou modification. Pour assurer une authentification mutuelle, le
navigateur peut aussi présenter au serveur un certificat signé qui lui est propre.
Https est très utilisé au niveau du web, toutefois il a aussi sa part de problème :
 La complexité de l’implémentation et de la gestion des PKI
 La révocation des certificats
 Face à des certificats non valides ou qui ne sont pas fournis par des tiers de confiance, le
navigateur affiche un message technique prévenant l’utilisateur qu’il doit prendre une
décision quant au maintien de sa connexion, alors que celui- ci n’est pas forcément en
mesure de répondre correctement.
 Une autre considération technique très intéressante et qui n’est pas encore complètement
résolue dans les navigateurs actuels est le mélange de l’Http et de l’Https dans certaines
configurations, qui crée de nouvelles possibilités d’attaques man-in-the-middle surtout avec
l’utilisation de scripts. Ainsi, la majorité des navigateurs a pris des mesures afin de détecter
et bloquer ce genre de mélange.
La défense contre l’insertion de script
L’utilisation de JavaScript et d’autres langages de scripts par les navigateurs facilite la mise en place
d’attaques. Un attaquant pourrait facilement les exploiter et lancer des actions qui monopoliseraient
la mémoire vive ainsi que le CPU de la machine client, empêchant l’utilisateur de surfer sur d’autres
pages. Quelques restrictions ont été implémentées sur les navigateurs pour contourner ce genre
d’attaques, notamment le filtrage des fenêtres pop-up qui sont largement exploitées dans cette
optique. Mais aussi des restrictions imposées à la présentation des fenêtres du navigateur en
général.
14
Mozilla – Firefox
Comment traite-t-on les questions de sécurité ?
Un bon niveau de sécurité ne s’improvise pas. Ces questions doivent être prises en compte dès la
phase de conception du produit. Quelque soit son origine, un bug peut créer des vulnérabilités. Les
bugs de sécurité ne proviennent pas forcément des scripts liés au management de la sécurité. C’est la
raison pour laquelle les équipes de Mozilla Firefox consacrent un temps non négligeable lors de la
revue de code à vérifier la conformité de leur produit. Un programme contenant des fuites de
mémoire, des variables non initialisées, … ne sera pas validé. De même, tout code contenant des
dépassements de buffer, des vulnérabilités aux attaques XSS, … est inacceptable. La sécurité dépend
de l’implication de chacun des acteurs.
L’attention des équipes de développement porte principalement sur les critères suivants :







Interdire l’exécution de code arbitraire et contrôler l’accès aux fichiers systèmes
Sécuriser le navigateur face aux exploits et autres chevaux de Troie déjà référencés
Surveiller la gestion des privilèges
Limiter les accès aux fichiers locaux et surveiller la gestion du cache
Prévenir tout risque de vol d’identité ou de données personnelles
Détecter les sites malveillants et les usurpations d’adresses (URL)
Assurer une certaine résistance aux dénis de service
En revanche, certaines questions sont laissées à l’appréciation de l’utilisateur. Ainsi, lors de
l’installation de plugins, le téléchargement de code natif n’est soumis à aucune vérification
particulière. C’est à l’utilisateur de savoir si l’extension qu’il souhaite déployer peut être considérée
comme fiable. Aussi, les questions relatives à l’accès physique au navigateur par un utilisateur sont
placées sous la responsabilité du client. Les équipes doivent donc faire face à plusieurs challenges.
Tout d’abord, Mozilla est embarqué dans de nombreuses applications et est distribué à différents
types d’utilisateurs. Cela implique que l’on ne peut pas compter sur la présence d’un personnel
expérimenté capable de configurer le navigateur et de le conserver à jour pour chaque client. Le
second point à prendre en compte est la complexité de la plateforme Mozilla. Elle inclut de
nombreux composants : le navigateur « Firefox », le webmail « Thunderbird », ainsi que de
nombreux modules complémentaires. Aussi la complexité et la sécurité ne sont pas réellement
compatibles. Au cours d’interactions complexes entre différents modules, potentiellement écrites
par diverses équipes, des failles de sécurité apparaissent. C’est pourquoi chaque module doit être
conçu pour fonctionner correctement, quelle que soit la nature des données transmises par les
autres modules. Une autre considération à garder en mémoire, est que l’interface utilisateur est
écrite dans les mêmes langages que les contenus Web. Il faut donc faire attention à ne pas faire de
confusion entre les contenus Web non fiables et le code sécurisé de l’interface. Enfin, la grande
majorité des utilisateurs n’est pas expérimentée et ne cerne pas les risques induits par l’utilisation de
contenus interactifs. Cela implique qu’il faut éviter de requérir au jugement du client Web, dans les
processus décisionnels.
La règle d'Or est donc de ne jamais faire confiance aux variables d’entrée. Il est alors nécessaire de
vérifier toutes les variables et de tester leur fiabilité.
15
Quelles sont les implications pour le navigateur ?
Chrome JS
L’écriture du code Chrome ressemble de très près à celle de pages Web et pose les mêmes questions
de sécurité. Les enjeux sont plus importants avec Chrome. En effet, il est considéré comme une
partie du code natif du navigateur. Il n’y a donc aucune restriction quant à ce qu’il peut réaliser.
La chose la plus importante à se rappeler, c’est qu’il faut traiter l’ensemble des entrées de
l’utilisateur ainsi que les données en provenance du Web, notamment les URL qui sont non fiables et
potentiellement malveillantes. Quelle que soit la donnée issue d’Internet utilisée par Chrome, elle
doit être filtrée de tout contenu dangereux.
Il faut garder à l’esprit que tout rendu HTML, XML, ou chargement d’URL peut provoquer l’exécution
de code Javascript. Avec une page Web affichée dans la fenêtre principale du navigateur, cela est
inoffensif, puisque l’ensemble des contenus de cet espace est traité comme non sûr et donc joué
dans une « Sandbox ».
Enfin, un certain nombre de préconisations doivent être respectées :
 La source ou l'origine d'un fichier détermine sa zone de confiance et non son format ou son
langage d'écriture ;
 Eviter de recourir à la commande eval(XXX), qui est trop souvent la source de corruption des
données. Si cela est obligatoire, il faut d’abord vérifier que XXX corresponde bien à l'entrée
attendue ;
 Se méfier des appels de fonctions en provenance de _content, qui sont par définition non
sûrs. Par exemple, il est préférable d’utiliser ToString(obj) à la place de obj.toString(), si obj
provient de _content, la page Web ayant pu surcharger la fonction toString de obj ;
 Ne pas télécharger les images à partir d’URL ayant recours aux protocoles de type javascript
ou data, ils peuvent dissimuler l’exécution de scripts malveillants ;
 Eviter d’utiliser la programmation en C & C++ qui est trop souvent source d'erreurs, puisque
ces langages sont très versatiles. Elle peut produire notamment des dépassements de buffer,
induire de nombreux Bugs liés à la gestion des formats de chaînes. De plus, ces langages
contiennent de nombreuses fonctions à proscrire.
La Same Origin Policy et le JavaScript
La Same Origin Policy permet d’éviter qu’un document ou script chargé depuis une première source
puisse obtenir ou modifier les propriétés d'un document provenant d'une seconde source. Cette
politique date de l’époque de Netscape Navigator 2.0.
Mozilla considère que 2 pages ont la même origine si le protocole, le port (si spécifié) et l'hôte sont
identiques entre les 2 pages.
Il existe toutefois une exception à cette règle. Un script peut spécifier la valeur "document.domain"
sur un suffixe du domaine courant. Dans ce cas, le domaine le plus court est utilisé pour les
vérifications ultérieures. Par exemple, considérons qu’un script dans le document
http://store.company.com/dir/other.htm exécute la commande suivante :
Document.domain = « company.com »
Alors la page http://company.com/dir/page.htm satisfera la vérification d’origine. En revanche,
company.com ne pourra plus positionner document.domain à othercompany.com.
16
La Signed Script Policy
Cette politique implique de générer une signature digitale puis de l'associer avec le script
correspondant. Anciennement avec Netscape, l'association était réalisée en ajoutant l'attribut
ARCHIVE="..." au tag SCRIPT en référence à une archive JAR contenant les signatures de chacun des
scripts de la page. Dans Mozilla, cette association est gérée différemment. La page HTML et les
scripts qu'elle inclut via le tag <SCRIPT SRC="..."> sont signés et placés dans un fichier JAR avec leur
signature. En se référant à la page HTML par la syntaxe suivante :
jar:http://www.site.com/myjar.jar!/signed.html, la signature est automatiquement associée avec le
script puis vérifiée au chargement de la page. Les syntaxes HTML spéciales identifiant les scripts
(attributs ARCHIVE et ID) ne sont pas nécessaires sous Mozilla et ne sont d'ailleurs plus reconnus.
Le modèle de sécurité JavaScript pour la signature est basé sur le modèle de sécurité Java pour les
objets signés de Netscape. Le fait de signer un script via un certificat valide issu d'une autorité de
certification telle que VeriSign vous certifie que vous êtes le propriétaire du script et que celui-ci n'a
subi aucune modification avant d'arriver à l'utilisateur final. Puisque les scripts signés offrent une
preuve d'identité, ils sont les seuls à pouvoir accéder aux privilèges étendus avec l'autorisation de
l'utilisateur.
Un script signé peut donc prétendre à des privilèges étendus qui lui donnent accès à des
informations et capacités restreintes. Vous pouvez alors utiliser ces privilèges afin d'exercer un
contrôle plus fin que celui auquel le Javascript normal vous autorise.
Toute décision du contrôle d'accès dépend de qui est autorisé à faire quoi. Dans ce modèle, l'auteur
représente le "Qui", la cible représente le "Quoi" et le privilège associé à l'auteur représente
l'autorisation (ou l'interdiction) pour le code signé par l'auteur d'accéder à des droits spécifiques.
Une fois le script écrit, vous le signez en utilisant l'outil de signature Mozilla, qui est l'un des outils
"Network Security Services". SignTool associe la signature électronique avec les fichiers HTML et JS.
Cette signature est détenue par un auteur particulier (une entité réelle telle Netscape ou John
Smith). La signature électronique et les fichiers signés sont placés dans une archive Java : un fichier
JAR.
L'auteur associé permet à l'utilisateur de confirmer l'identité de l'entité qui a signé le script. Cela
permet aussi à l'utilisateur de s'assurer que le script n'a pas été modifié depuis sa dernière signature.
L'utilisateur peut enfin décider d'autoriser l'augmentation des droits en se basant sur la validité de
l'identité détenant le certificat propriétaire ainsi que l'intégrité du script.
Il est tout de même important de garder à l'esprit que l'utilisateur final peut refuser l'augmentation
de privilèges requise par le script. L'émetteur doit donc écrire des scripts réactifs à ce type de
décision.
Les privilèges représentent des permissions d’accès à des cibles spécifiques. Le tableau suivant liste
les privilèges JavaScript et les droits associés.
17
Privilèges
Droits Associés
Lecture de données sensibles liées au navigateur
UniversalBrowserRead
Permet au script de passer outre le test de la Same Origin lors de la
lecture d'un document
Modification de données sensibles liées au navigateur
UniversalBrowserWrite
UniversalXPConnect
Permet au script de passer outre le test de la Same Origin lors de
l'écriture d'un document
Accès illimité aux API du navigateur utilisant XPConnect
UniversalPreferencesRead
Lecture des préférences utilisant la méthode navigator.preference
UniversalPreferencesWrite
Modification
des
navigator.preference
CapabilityPreferencesAccess
préférences
utilisant
la
méthode
Lecture/Ecriture des préférences qui définissent la politique de
sécurité, incluant quels privilèges ont été autorisés ou interdits aux
scripts (You also need UniversalPreferencesRead/Write.)
Ouverture de fichiers via window.open pour file:// URLs
UniversalFileRead
Téléchargement de fichiers depuis le disque local via la commande
<input type="file">
Comment l’utilisateur peut-il gérer la sécurité ?
Les Configurable Security Policies
Les politiques de sécurité configurables de Mozilla permettent à l'utilisateur de configurer le niveau
de sécurité associé au navigateur, mais aussi celui associé à différents sites Internet. Ce concept de
politique de sécurité configurable provient de nombreuses sources. Les chercheurs de Bell Labs :
Vinod Anupam et Alain Mayer ont écrit plusieurs rapports et contribué à l'écriture de ce code
Mozilla. Le célèbre bug 858 a aussi servi d'accélérateur pour le déploiement de ces fonctionnalités.
Le code associé est appelé CAPS (capacités). Finalement, les zones de sécurité d'IE utilisent une part
de ces concepts.
Configurer les politiques globales
Supposons que vous souhaitiez supprimer les publicités par pop-up et que vous désiriez interdire à
toute page web d'ouvrir de nouveaux navigateurs. Vous pouvez le faire en ajoutant la ligne de code
suivante dans votre fichier de préférences utilisateur (user.js) :
user_pref("capability.policy.default.Window.open", "noAccess");
Le fichier de préférences utilisateur (user.js) permet de modifier les caractéristiques d'un profil
donné, pour le créer vous devez ajouter ce fichier dans le dossier correspondant au profil. Pour que
« user.js » prenne effet, vous devez redémarrer l'application.
Positionner Window.open à la valeur noAccess signifie qu'aucune page Web ne pourra plus accéder à
la propriété open d'objets de type Window. Si un site web essaie d'ouvrir une fenêtre en utilisant
window.open() (ou open()), la tentative échouera. Le manager de sécurité lèvera une exception
18
JavaScript, interdisant l'appel de la fonction. Bien que la page Web gère l'exception, le script sera
arrêté et un message d'erreur apparaîtra dans la console JavaScript console (Outils->Console
d'erreurs).
Politiques par zone
La politique par défaut est spéciale, elle s'applique à tous les sites. Vous pouvez aussi configurer des
politiques qui s'appliquent à des sites ou groupes de sites spécifiques, en surchargeant la politique
par défaut. Par exemple, si vous voulez restreindre la création de fenêtre de dialogue pour les sites
www.evil.org et www.annoying.com, vous pouvez utiliser le code suivant :
user_pref("capability.policy.policynames", "strict");
user_pref("capability.policy.strict.sites", "http://www.evil.org http://www.annoying.com");
user_pref("capability.policy.strict.Window.alert", "noAccess");
user_pref("capability.policy.strict.Window.confirm", "noAccess");
user_pref("capability.policy.strict.Window.prompt", "noAccess");
La première ligne définit le nom de la politique ou des politiques que vous souhaitez créer, dans
notre cas strict. Si vous définissez plus d'une politique, listez les toutes sur la même ligne, par
exemple :
user_pref("capability.policy.policynames", "strict, shoppingsites");
La préférence capability.policy.strict.sites définit les sites Web pour lesquels la politique strict
s'applique. La valeur de cette préférence est une liste de sites (protocole et nom d'hôte uniquement),
séparés par des espaces. Les 3 dernières lignes définissent la politique de sécurité. Pour ces sites,
l'exemple ci-dessus désactivera l'accès aux fonctions
window.alert(), window.confirm() et window.prompt()
A noter que tant que nous n'avons pas défini si les sites de la politique strict pouvaient ouvrir de
nouvelles fenêtres avec window.open(), la politique par défaut s'applique.
Supposons aussi que nous ayons découvert qu'en bloquant l'accès à window.open(), nous
empêchions un script sur www.usefulsite.net de fonctionner. Nous pouvons autoriser cette page à
outrepasser la restriction sur window.open en reconfigurant la politique window.open à sa valeur
initiale : sameOrigin.
user_pref("capability.policy.policynames", "trustable");
user_pref("capability.policy.trustable.sites", "http://www.usefulsite.net");
user_pref("capability.policy.trustable.Window.open", "sameOrigin");
Les niveaux de sécurité
Il existe 3 niveaux de sécurité :
 noAccess: les sites web ne peuvent jamais accéder à cette propriété ou appeler cette
fonction ;
 sameOrigin (défaut): les sites web peuvent accéder à cette propriété, mais seulement pour
les pages du même site ;
 allAccess: un site web peut accéder à cette propriété depuis n'importe quel site.
Si le niveau de sécurité n'est pas l'un des précédents, il est traité comme un privilège nommé, et un
script peut y accéder uniquement s'il est signé et que l'utilisateur l'autorise via une boite de dialogue.
19
Get & Set
Vous pouvez spécifier une politique qui s'applique uniquement sur la lecture d'une propriété ou
uniquement au changement de sa valeur, en ajoutant .get ou .set après le nom de la propriété. Cela
permet d'affiner les politiques de sécurité et de différencier les options de lecture des options
d'écriture.
A noter que configurer Class.property.get et Class.property.set au même niveau de sécurité est
équivalent au paramétrage de Class.property. Il faut donc éviter les surcharges inutiles.
En bloquant l'accès de propriétés, il est important de noter qu'il y a plus d'une façon d'accéder à
certaines propriétés, telles que les attributs d'éléments HTML. Par exemple, supposons qu'un
utilisateur veuille interdire aux scripts de www.evil.org, l'accès à l'attribut href des balises HTML (<A
HREF="...">). Les préférences suivantes ne sont pas suffisantes :
user_pref("capability.policy.policynames", "nohrefs");
user_pref("capability.policy.nohrefs.sites", "http://www.evil.org");
user_pref("capability.policy.nohrefs.HTMLAnchorElement.href", "noAccess");
Pendant que ces préférences interdiront au site www.evil.org, l'accès à document.links[1].href, le
script pourra accéder à la même information en utilisant la syntaxe DOM 2 :
document.links[1].attributes.getNamedItem("href") ou document.links[1].getAttribute("href"). Les
préférences suivantes couvrent l'ensemble des méthodes d'accès :
user_pref("capability.policy.policynames", "nohrefs");
user_pref("capability.policy.nohrefs.sites", "http://www.evil.org");
user_pref("capability.policy.nohrefs.HTMLAnchorElement.href", "noAccess");
user_pref("capability.policy.nohrefs.HTMLAnchorElement.attributes", "noAccess");
user_pref("capability.policy.nohrefs.HTMLAnchorElement.getAttribute", noAccess");
user_pref("capability.policy.nohrefs.HTMLAnchorElement.getAttributeNS", "noAccess");
En règle générale, pour bloquer l'accès à un attribut, vous devez bloquer les propriétés de l'attribut
et les méthodes getAttribute et getAttributeNS.
Syntaxe complète pour les références
Voici la syntaxe formelle pour les politiques de sécurité JavaScript :
 Une politique se compose d'une ligne policynames, d'une ligne sites, et d'une ou plusieurs
lignes policy. La ligne sites doit être omise pour la politique par défaut, mais présente dans
les autres cas.
 La ligne policynames spécifie les noms de toutes les politiques que vous souhaitez définir. Il
ne doit y avoir qu'une unique ligne policynames, peu importe le nombre de politiques que
vous définirez. Elle a le format suivant :
user_pref("capability.policy.policynames", "<list of policy names>");
Où :
<list of policy names> est la liste des noms de politiques que vous souhaitez définir, séparés
par des virgules et/ou espaces.
 La ligne "sites" a le format suivant :
user_pref("capability.policy.<policy name>.sites","<URL list>");
Où :
<policy name> est une combinaison de lettres et de chiffres, débutant par une lettre.
20
<URL list> est une liste d'URLs séparées par des espaces. Chaque URL peut être de la forme
"protocole:", qui appliquera la politique à toutes les URLs associées au protocole donné (ex:
http:), ou de la forme protocole://hôte qui appliquera la politique à un hôte donné. Ne
spécifiez pas la partie Path de l'URL, mais juste le nom d'hôte.
 La ligne policy a le format suivant :
user_pref("capability.policy.<policy name>.<class name>.<property name>",
"allAccess | noAccess | sameOrigin | <capability name>");
Où :
<policy name> est une combinaison de lettres et de chiffres, débutant par une lettre.
Désactiver tout Javascript pour un site
La propriété spéciale javascript.enabled peut être utilisée pour désactiver l'exécution de JavaScript.
Pour cette politique spécifique, la valeur de la préférence doit être noAccess ou allAccess. Aucune
autre valeur ne fonctionnera.
L'exemple suivant désactive toute exécution Javascript pour les sites site1.com et site2.com :
user_pref("capability.policy.policynames", "nojs");
user_pref("capability.policy.nojs.sites", "http://site1.com http://site2.com");
user_pref("capability.policy.nojs.javascript.enabled", "noAccess");
L'exemple suivant désactive toute exécution Javascript pour les sites à l'exception de goodsite.com :
user_pref("capability.policy.policynames", "jsok");
user_pref("capability.policy.default.javascript.enabled", "noAccess");
user_pref("capability.policy.jsok.sites", "http://goodsite.com");
user_pref("capability.policy.jsok.javascript.enabled", "allAccess");
A noter que la préférence suivante :
user_pref("javascript.enabled", false);
Surcharge toutes les préférences capability.policy, incluant capability.policy.default.javascript.
enabled et ce pour tous les sites.
Peut-on recourir à un certificat maître comme tiers de confiance?
Il s'agit d'une option disponible auprès des distributeurs de Mozilla qui permet d'établir un certificat
maître. Celui-ci peut alors accorder sa confiance à d'autres certificats (signatures de code) sans
interagir avec l'utilisateur.
Le certificat maître
Dans Mozilla, il est défini comme une signature dans le fichier systemSignature.jar. Sur Windows et
les systèmes Unix, ce fichier doit être installé dans le même répertoire que le binaire Mozilla, et sur
les Macintoshs, dans le répertoire "Essential Files". Ce fichier peut être généré en utilisant SignTool,
un utilitaire de Mozilla pour signer les fichiers de codes.
Une fois le certificat MyMasterCertNickname que vous souhaitez utiliser comme certificat maître, est
installé dans votre base de données de certificats, un fichier de certificat maître peut être généré
avec la commande suivante :
signtool -k "MyMasterCertNickname" -Z systemSignature.jar emptyDir
21
Le répertoire vide emptyDir indique qu'aucun fichier à part le fichier de signature lui-même, ne doit
être placé dans le jar. On obtient alors le fichier suivant : systemSignature.jar qui peut être distribué
avec un navigateur de type Mozilla. Sans la présence de ce fichier dans le navigateur distribué,
l'option de certificat maître ne fonctionnera pas.
Pensez à protéger la clé privée de votre certificat maître. A savoir que n'importe quelle personne
capable de signer des scripts avec votre certificat maître peut obtenir des accès non autorisés vers
tout navigateur distribué équipé de ce certificat.
L'API
Un script signé par le certificat maître courant peut appeler 2 fonctions qu'aucun autre script ne peut
appeler :
 netscape.security.PrivilegeManager.setCanEnablePrivilege(certificateID, privilegeList)
Qui peut conférer la confiance vers d'autres certificats.
 netscape.security.PrivilegeManager.invalidate(certificateID)
Qui révoque de façon permanente la confiance accordée à un certificat.
Où :
 certificateID est l'empreinte digitale du certificat ;
 privilegeList est la liste des privilèges accordés, séparés par des espaces.
Pour obtenir la liste des privilèges existants, veuillez vous référer au chapitre : Signed Script Policy.
Un modèle reposant sur 2 certificats
Il est important de comprendre qu'il y a 2 certificats impliqués dans le processus. Le premier est le
certificat maître qui est installé par le distributeur des navigateurs basés sur Mozilla et le second est
celui qui sera utilisé par le créateur de contenus pour signer ses propres scripts, appelé WebSite
certificate. Voici la procédure :
1. La compagnie ABC distribue un produit basé sur un code Mozilla qui inclut un fichier système
Signature.jar.
2. Foobar.com, un développeur de contenu Web, obtient un certificat électronique pour signer
son code (website certificate) et envoie la signature de son certificat (certificateIDFoo) à ABC.
3. ABC écrit un script du type :
netscape.security.PrivilegeManager.setCanEnablePrivilege("certificateIDFoo",
"UniversalPreferencesRead UniversalBrowserRead")
ABC signe ce script avec son certificat maître et donne le script signé à Foobar.com. Notez
que le script ci-dessus autorise le certificat de Foobar à utiliser 2 privilèges.
4. Foobar.com crée un site web et inclut le script signé reçu d'ABC. Quand le site requiert
l'accès aux privilèges utilisateur du navigateur, Foobar signe ses scripts avec le certificat
obtenu en (1).
5. Quand un utilisateur visite le site de Foobar, le navigateur ABC commence par charger le
script actif signé par ABC. Alors, tous les scripts signés par le certificat du site web de Foobar
peuvent appeler la fonction :
netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead")
Suivi par exemple de :
var homepage = navigator.preference("browser.startup.homepage")
Qui lit les préférences du navigateur client. Aucune confirmation ne sera demandée à
l'utilisateur. En fait le script peut être lancé sans aucune connaissance de l'utilisateur.
22
Le script setCanEnablePrivilege n'a besoin de tourner sur le navigateur client qu'une seule fois. Les
privilèges accordés au certificat du site Foobar sont enregistrés dans les préférences du navigateur
qui s'en souviendra pour les futures visites du site Foobar.
Ce modèle permet aux distributeurs de Mozilla de décider quels créateurs de contenus peuvent
disposer des privilèges silencieux, mais aussi de révoquer cette même confiance si nécessaire. En se
basant sur l'exemple précédent, supposons que le certificat du site Foobar.com ait été compromis,
ou qu'une faille de sécurité ait été trouvée dans le code. ABC, le distributeur du navigateur basé sur
Mozilla, peut distribuer un script signé par le master certificat du style :
netscape.security.PrivilegeManager.invalidate("certificateIDFoo")
La fonction de révocation ne prend en entrée qu'une seule donnée, l'identifiant du certificat à
révoquer. Une fois lancé, ce script révoque de façon permanente la confiance accordée au certificat
du site Foobar.com, ce qui implique que les scripts signés par ce certificat ne sont plus valables.
Comme setCanEnablePrivilege, la fonction invalidate ne peut être invoquée que depuis un script
signé par le certificat maître.
Comment gérer les privilèges associés à des fichiers ?
Définition
Généralement, les permissions sont accordées à toutes les pages pour un hôte donné (ou pour
toutes les pages signées par un même certificat), comme un bloc. Quand un script requiert des
privilèges et qu'aucune préférence n'a été paramétrée par l'utilisateur pour cet hôte ou certificat, la
boîte de dialogue "autoriser/interdire" est présentée. La décision de l'utilisateur est appliquée à tous
les fichiers associés à l'hôte/certificat.
Une des limites de ce modèle est que le système local de fichiers (tout accès depuis le protocole
file://) est traité comme un unique domaine de sécurité, ainsi les privilèges accordés à une page pour
le système local de fichiers, le sont pour toutes les pages, ce qui est potentiellement un danger. Les
permissions par fichier autorisent d'octroyer des privilèges à des fichiers individuels.
Fonctionnement
Les permissions par fichier doivent être configurées dans les préférences utilisateur, soit par un script
contenant les privilèges à modifier, soit en éditant directement le fichier des préférences.
Par exemple, supposons qu'un développeur d'applications Web ait installé une page HTML sur le
disque local C:/Programs/Webapp/index.html et que cette page contienne du JavaScript qui
nécessite l'accès à XPConnect. Il serait dangereux d'autoriser le privilège UniversalXPConnect à tous
les fichiers du disque local. A la place, le développeur devrait ajouter les lignes suivantes à ses
préférences utilisateur :
user_pref("capability.principal.myapp.id", "file:///C|/Programs/Webapp/index.html");
user_pref("capability.principal.myapp.granted", "UniversalXPConnect");
Ces lignes autoriseront l'accès à XPConnect pour le fichier index.html uniquement. Le mot clé myapp
peut être remplacé par tout identifiant unique de votre application, tant que les 2 lignes possèdent le
même identifiant.
23
Pour une syntaxe un peu plus générale :
user_pref("capability.principal.<group name>.id", "<Space-separated list of absolute URLs.>");
user_pref("capability.principal.<group name>.<granted|denied>", "<privilege name>");
Où :
<group name> est un identifiant alphanumérique
<privilege name> est UniversalXPConnect ou tout autre chaîne de privilège représentant une
fonctionnalité étendue requise pour votre script.
Limitations
Ce mécanisme n'est pas inter plateforme (systèmes Unix/Windows/...). Manifestement, l'URL de
l'exemple précédent devra être changée pour chaque plateforme, mais aussi si le fichier est déplacé.
La possibilité d'utiliser des liens relatifs serait meilleure.
Quelle est la politique de traitement des failles de sécurité ?
Toute personne qui pense avoir trouvé une vulnérabilité liée à la sécurité de Mozilla, peut et devrait
la rapporter en envoyant un email à l'adresse suivante : [email protected].
Pour améliorer son approche dans la résolution des vulnérabilités de sécurité, mozilla.org a créé une
procédure plus formelle, pour traiter les bugs relatifs à la sécurité de Mozilla. Tout d'abord,
mozilla.org va désigner un responsable de module de sécurité qui sera chargé de coordonner les
investigations et de résoudre les vulnérabilités rapportées. Ce responsable sera assisté dans sa tâche
par un ou plusieurs collègues. En même temps, Mozilla.org crée un groupe plus important : "Mozilla
security bug group", par lequel les contributeurs peuvent participer en envoyant des vulnérabilités
de sécurité. Pour plus d'informations, veuillez vous référer à l'adresse suivante :
http://www.mozilla.org/projects/security/security-bugs-policy.html.
Quelles sont les vulnérabilités connues sous Firefox 3.0 ?
Différents impacts
Mozilla classe ses avertissements de sécurité sous 4 catégories, en fonction de leur impact :
 Critique : vulnérabilité pouvant être utilisée pour lancer un code d'attaque et installer des
logiciels. Ne nécessite pas une interaction avec l'utilisateur, à part une navigation normale.
 Elevé : vulnérabilité pouvant être utilisée pour obtenir des données sensibles depuis des sites
ouverts dans d'autres fenêtres, ou par l'injection de données ou de code depuis ces sites. Ne
nécessite rien de plus que des actions normales de navigation.
 Modéré : vulnérabilité qui serait considérée comme Elevée ou Critique si ce n'est qu'elle ne
fonctionne uniquement dans des configurations spécifiques ou qui requiert des interactions
compliquées pour l'utilisateur.
 Faible : vulnérabilités mineures de sécurité, telles que des attaques par déni de service, des
fuites de données mineures, ou des usurpations. (Les usurpations indétectables SSL auront
un impact Elevé car elles sont généralement utilisées pour voler des données destinées à
d'autres sites).
24
Exemples de bugs de sécurité résolus dans Firefox 3.0.11
 Critique
 MFSA 2009-32 Elévation des privilèges Chrome Javascript
 MFSA 2009-29 Exécution de code arbitraire utilisant les capteurs d’évènements attachés à
un élément dont le propriétaire est null
 MFSA 2009-28 Compétition lors de l’accès aux données privées d’un objet de la classe
NPObject JS
 MFSA 2009-24 Plantage avec corruption de mémoire évidente
 Elevé
 MFSA 2009-27 Temporisation SSL lors de 200 absences de réponses à des requêtes proxy
CONNECT
 Modéré
 MFSA 2009-30 Gestion principale des fichiers incorrecte : chargement des ressources via la
barre de navigation
 MFSA 2009-26 Fichier local accédant aux cookies de domaines arbitraires : ressources
 Faible
 MFSA 2009-31 Scripts XUL outrepassant la vérification de la politique de contenu
 MFSA 2009-25 Usurpation d’URL via des caractères unicodes invalides
25
Microsoft – Internet Explorer
La version 6
Avec IE6 Microsoft a intensifié ses activités afin d’assurer la sécurisation de ses produits. Plusieurs
ressources et programmes ont été spécifiquement créés pour accroître la sécurité de son navigateur
Web. Les différents outils qui suivent font partie de la solution mise en place.
La méthodologie SDLC
Security Development Life Cycle, il s’agit d’un processus adopté par Microsoft afin de garantir la
conception de logiciels résistants aux attaques, se basant sur plusieurs activités et livrables, destinés
à chaque phase du développement des logiciels Microsoft.
La modélisation des risques
Il s’agit de l’identification et de l’estimation des risques qui peuvent nuire à chaque logiciel.
Elle permet de déterminer les contre-mesures qui permettront d’atténuer le risque, telles
que le cryptage ou l’utilisation de logiciels protégeant le produit de tout dommage possible.
Ainsi, l’équipe de production est capable de déterminer les besoins de sécurité et les
domaines auxquels il faut prêter plus d’attention.
La réalisation de tests de sécurité
Elle permet de maximiser la capacité de détection d’erreurs susceptibles de conduire à des
vulnérabilités logicielles.
Les scanners de code
Cette méthode d’analyse permet de détecter les erreurs de conception : dépassements de
tampons, variables non initialisées, … Microsoft investit énormément dans le développement
de ce genre d’outils pour leur mise à jour mais aussi parce qu’ils prennent en charge
l’ensemble des vulnérabilités découvertes auparavant.
La vérification du code source
Les outils automatiques de vérification du code source permettent de détecter et d'éliminer
les failles de sécurité. C’est une étape cruciale dans le processus d'élimination des failles
logicielles pendant le processus de développement.
Selon le processus SDLC, tout logiciel final doit être soumis à un examen de sécurité par une équipe
indépendante de son groupe de développement avant d’être livrée au client. Ceci permet de réduire
de manière très significative le degré de vulnérabilité.
Microsoft Security Response Center
Le MSRC est un centre de recherches qui se focalise sur les différents incidents liés à la sécurité, pour
faire face aux menaces avant qu'elles ne se développent et n’impactent le consommateur ou
l‘entreprise.
Si le MSRC reçoit un rapport de vulnérabilité de sécurité, il tente d'identifier immédiatement l'impact
possible sur les clients et lui assigne une priorité. Une fois la faille de sécurité confirmée, le MSRC
évalue la gravité de la situation et mobilise rapidement les ressources de Microsoft dans le monde
entier afin d'acquérir une compréhension approfondie de la vulnérabilité.
Le MSRC est très vigilant par rapport à la découverte et la recherche des problèmes potentiels de
sécurité liés à Internet Explorer.
26
Internet Explorer bénéficie d'une amélioration continue du processus de mise à jour de la sécurité de
MSRC mais aussi des éléments suivants :
Un calendrier mensuel prévisible des publications des patchs de sécurité, le deuxième mardi de
chaque mois. D’autres mises à jour peuvent être déployées à tout instant, lorsque le client se
retrouve face à une attaque malveillante.
Un programme de validation des mises à jour des logiciels qui permet de garantir la plus haute
qualité des mises à jour.
La mise à disposition d’outils et de guides évolués :
- Un bulletin de sécurité mensuel diffusé sur le Web
- Des flux RSS pour les bulletins de sécurité
- Des outils de suppression des logiciels malveillants tels que Windows Defender
Les bulletins de sécurité permettent de compléter les guides et d’apporter les informations
relatives aux mises à jour de la distribution, lors de leur déploiement.
Le service Windows Update
Microsoft a mis en place un système de mise à jour robuste : le service Windows Update. Cet outil
peut combler les failles de sécurité, en fournissant instantanément les mises à jour aux utilisateurs.
Les administrateurs systèmes de Microsoft peuvent donc mieux contrôler le processus SDLC, peu
importe la taille ou la complexité de l’organisation cliente. La maintenance d’Internet Explorer
s'appuie sur l’infrastructure Windows Update pour fournir les options de mise à jour listées ci-après:
Le site Web Microsoft Windows Update
Mises à jour automatiques Windows
Windows Server Update Services (WSUS)
WSUS permet à l'organisation de télécharger la mise à jour du système d’exploitation et d’Internet
Explorer. Cette infrastructure est capable de fournir 100 millions de patchs par jour et est
suffisamment robuste pour pouvoir offrir des packs dont la taille dépasse de 100 MB. Aussi, cette
infrastructure Windows est flexible : les mises à jour peuvent être distribuées par ordre de priorité
La performance de l’infrastructure système de Windows Update est continuellement mesurée et
contrôlée. Ces paramètres permettent à Microsoft de réagir dynamiquement à l'apparition des
problèmes de performance afin de les corriger rapidement. L'anonymat dans le cadre de ces rapports
est crucial pour Microsoft, aucune des informations personnelles identifiables n’est recueillie ou
transmise à Microsoft. Les seules données qui peuvent être considérées comme identifiables sont
l’adresse IP ainsi que l’heure de l’attaque.
Les zones de sécurité
Les dernières versions d’Internet Explorer disposent toutes du concept de zones de sécurité. C’est
une approche de sécurité à plusieurs niveaux, permettant de classer les sites en 5 zones différentes :
Sites sensibles, Internet, Intranet local, Sites de confiance et Machine locale.
Cette fonctionnalité est accessible par le Menu Outils → Options Internet onglet Sécurité et permet
pour chaque zone de déterminer le niveau de sécurité en fonction du niveau estimé de risques des
sites appartenant à chaque zone.
 La zone la plus restrictive est celle des Sites sensibles, contenant les sites que l'utilisateur a
restreints manuellement, ou insérés via des outils de protection externes.
 La zone Internet est aussi assez restrictive et on y trouve par défaut tout site inconnu.
 Les sites de la zone Intranet local n’appartiennent pas à la zone de confiance et sont soumis
27
à certaines restrictions. Toutefois ils sont toujours moins contraints que ceux de la zone
Internet car ils ont accès aux ressources partagés sur le réseau local tels les fichiers ou
imprimantes qui sont partagés.
 Les sites appartenant à la zone de confiance sont ceux auxquels l’utilisateur fait confiance,
mais aussi les sites sécurisés via le protocole Https .Le degré de sécurité de cette zone est
très faible, ainsi le téléchargement et l’accès au contenu est permis sauf pour les scripts
ActiveX.
Microsoft Internet Explorer frame restrictions
Il s’agit d’un mécanisme de sécurité très intéressant, spécifique à IE basé le concept :
Sécurité = RESTRICTED frames
L'idée derrière ce mécanisme est que certains services peuvent limiter l’accès aux données
malveillantes affichées dans les conteneurs <iframe>, et placer le contenu de ces dernières dans la
zone des sites restreints afin de leur interdire l’exécution de scripts perturbateur et bloquer leur
accès aux cookies.
IE 6 & Windows XP SP2
Windows XP Service Pack 2 (SP2) apporte des améliorations de la sécurité et de la protection du
navigateur Web Internet Explorer. La combinaison des fonctions de sécurité, des innovations de
Windows XP SP2 avec les technologies avancées de sécurité a permis de mettre en place une
approche proactive de la sécurité au niveau d’IE.
Local Machine Zone Lockdown
LMZ est une zone de sécurité d'Internet Explorer se référant aux contenus accessibles à partir de
l'ordinateur local. Le LMZ est une zone implicite qui ne figure pas sur la liste des zones de sécurité.
Windows XP SP2 protège les LMZ en empêchant le contenu actif des pages Web (contrôles ActiveX,
applets Java et JavaScript) de fonctionner dans la zone Ordinateur local. Pour assurer le bon
fonctionnement quand un contenu actif tente de s'exécuter, un message d'avertissement s’affiche au
niveau de la nouvelle barre d'informations informant l’utilisateur qu’il a la possibilité de cliquer sur la
barre d’informations afin de débloquer le contenu ou non.
Zone Elevation Blocks
Chaque zone de sécurité définit un certain nombre de paramètres d’Internet Explorer pour le
contrôle d'accès et la configuration de sécurité en se basant sur son propre niveau de confiance.
Windows XP SP2 Zone Elevation Blocks permet d'empêcher que les pirates n’augmentent de façon
inappropriée le niveau de confiance accordé aux contenus ou aux pages Web pour fonctionner dans
un contexte de sécurité plus élevé que l'original.
Le principe de bloquer toute augmentation de zone empêche les pirates d'utiliser des scripts pour
naviguer à partir d'une zone plus restreinte à une zone moins limitée. Lorsque le code d’un site tente
de rediriger le navigateur vers une zone moins restrictive, l'action par défaut d'Internet Explorer pour
Windows XP SP2 est de bloquer la tentative.
Les structures MIME
Multipurpose Internet Mail Extensions sont des structures de données qui ont été créées pour les
systèmes d'exploitation et des applications telles que les navigateurs, afin d’identifier correctement
et convenablement les types de fichiers disponibles. Dans l'environnement Web, les serveurs
fournissent des informations de formatage MIME au navigateur. Ce processus devrait accroître la
rapidité et l'efficacité de l'expérience en ligne. Par conséquent, Internet Explorer utilise les données
28
MIME fournies par le serveur Web pour déterminer la façon de traiter l'information transmise au
navigateur.
MIME Sniffing est le processus examinant le contenu d'un fichier pour déterminer son contexte, que
ce soit un fichier de données, un fichier exécutable, ou tout autre sorte de fichier. Il est conçu pour
interdire la promotion d'un type de fichier à un type plus dangereux, même dans le cas où une
enquête suggère du changement. Aussi, désactiver MIME Sniffing contourne les protections et
expose potentiellement l’utilisateur à une attaque utilisant une mauvaise manipulation de type
MIME dans le navigateur. Un exemple serait la promotion d'un fichier texte à un fichier graphique et
le lancement de l'application de visualisation. Une fois lancée, celle-ci ne serait pas en mesure
d’interpréter correctement le fichier et pourrait avoir un comportement imprévisible, ouvrant la
porte à de probables activités malveillantes à l’encontre du système.
La prévention de l’usurpation d’adresses
Les attaques par usurpation d’adresses URL sont parmi les attaques les plus communes au navigateur
Web. Dans le cas, l’utilisateur est surpris par l’affichage d’une adresse URL imprécise dans la barre
des adresses.
Pour répondre à cette vulnérabilité, Microsoft a amélioré le design d’Internet explorer et a
implémenté de nouveaux codes pour obtenir une vérification plus précise des URL. Ce changement a
résolu le problème d’exploitation de l’hexadécimal (computer encoded text formatting) pour
corrompre les adresses URL. Cette technique fut longtemps utilisée par les hackers afin de cacher
l’adresse correcte du site de destination et tromper l’utilisateur qui supposait le site web vers lequel
il était redirigé comme étant correct. La victime fournissait alors ses paramètres de compte à son
insu.
Une autre amélioration très importante fournie par Internet Explorer pour Windows XP SP2,
concerne le traitement de la vulnérabilité dite « IFRAME Hiding ». Dans cette attaque, le hacker crée
des fenêtres internet, auxquelles il cache l’adresse URL réelle, et les fait passer pour d’autres sites.
Pour gagner plus de crédibilité, l’attaquant peut même ajouter des icones notamment celles qui
montrent que le site est sécurisé, ou encore des références visuelles du chiffrement de connexion.
La gestion des téléchargements sécurisés
L’attaquant a besoin d’installer discrètement son code sur la machine de la victime pour gagner plus
de contrôle sur le système. Pour y parvenir, il utilise différentes méthodes pour créer de la confusion
et pousser l’utilisateur par la suite à installer ses applications.
Il existe 4 catégories importantes de téléchargements au travers du navigateur Web qui sont
exploitées par les attaquants afin d’installer leurs programmes.
 Les téléchargements sans consentement
Les boites de dialogue utilisées par les versions ultérieures d’IE pour télécharger et installer les
applications web étaient confuses et fallacieuses. Elles se présentaient sous la forme d’un choix
auquel l’utilisateur devait répondre par oui ou annuler. En revanche, IE sur Windows XP SP2
fournit aux utilisateurs des choix beaucoup plus significatifs et plus intuitifs : « Install » ou « Don’t
install ».
 Les téléchargements superposés aux installations logicielles approuvées
Ce type de téléchargements a lieu au moment où l’utilisateur essaie de télécharger et d’installer
une application approuvée incluant d’autres applications ignorées et même parfois des spyware.
Pour protéger l’utilisateur de ce genre de menace, une défense très renforcée et très
29
approfondie est nécessaire, d’où l’intérêt du logiciel Microsoft antispyware beta implémenté par
Microsoft pour mettre fin à ce genre d’attaques que l’on détaillera par la suite.
 Les téléchargements permis par des vulnérabilités des navigateurs
Quand un internaute visite un site malveillant ou corrompu, certains logiciels exploitent les
attaques contenues dans ces sites, qui a leur tour exploitent des vulnérabilités de navigateurs
Web bien déterminées et ils s’installent sur la machine de la victime sans même demander son
consentement.
Internet Explorer pour Windows XP SP2 permet de se protéger contre ce genre de
téléchargements en bloquant toutes sortes d’attaques pouvant causer un buffer over flow ou
d’autres soucis pour les navigateurs web.
 Les téléchargements dus à la personnalisation des paramètres de sécurité des navigateurs
L’utilisateur a parfois besoin pour effectuer certaines opérations, de changer les paramètres de
niveau de sécurité. Mais il oublie souvent de rétablir les changements temporels effectués.
Cependant, garder un niveau de sécurité très bas augmente le risque d’attaques et autorise le
navigateur à télécharger n’importe quelle application sans aucune vérification de sa source.
Internet explorer adresse ce risque en générant à chaque fois un message de rappel indiquant
d’augmenter le niveau de sécurité.
Le blocage des fenêtres pop up.
Les fenêtres pop up sont des fenêtres qui s’ouvrent souvent automatiquement en superposition du
navigateur déjà ouvert. Ces fenêtres sont utilisées pour faire de la publicité en direct ou pour
rediriger le client vers une autre fenêtre sous contrôle d’un site web illégitime. Ces fenêtres
représentent une vraie menace pour la sécurité et le bon fonctionnement du système. Pour cette
raison IE 6 pour Windows XP SP2 a déployé un bloqueur POP up qui peut être activé ou désactivé à
partir de l’onglet option internet. IE ne bloque pas les fenêtres pop up des sites Web appartenant à la
zone Intranet local ou la zone des sites de confiance.
La gestion des compléments
Pour améliorer et développer les fonctionnalités d’Internet Explorer, celui-ci introduit plusieurs
compléments : toolbar, pop-up ainsi que les contrôles ActiveX qui assurent le bon fonctionnement
de différentes applications telles que Macromedia Flash Player, Adobe Acrobat Viewer et RealPlayer.
Toutefois ces compléments représentent un risque important pour les navigateurs Web.
Dans les versions ultérieures d’IE, il était assez complexe de déterminer avec précision quels
suppléments étaient déjà installés sur le système. Toutefois avec Windows XP SP2, le gestionnaire
des suppléments fournit une interface utilisateur intuitive qui facilite la détection et le contrôle des
suppléments. Cet outil permet d’avoir une liste de ce qui est déjà installé, c’est un moyen très
efficace qui permet de trouver rapidement la faille si le système a été compromis par un site
malveillant. Il permet alors de supprimer le supplément malveillant avant que le système ou les
données ne soient endommagés.
Microsoft Windows AntiSpyware (Beta)
Microsoft Windows Antispyware est une nouvelle technologie implémentée en version d’essai au
niveau d’IE pour Windows XP SP2. Il permet de protéger les utilisateurs Windows des spywares et de
toute sorte de logiciels malveillants ou indésirables. En effet, cet outil réduit l’effet négatif des
spyware notamment au niveau de l’impact des performances du PC, le changement des paramètres
internet, la collecte des informations privée et la gêne que peuvent causer les fenêtres pop-up.
Cette technologie offre une protection permanente contre les sites Web et les applications
susceptibles d’installer des spywares sur la machine du client. Un spyware détecté est sur le champ
30
bloqué et si un logiciel suspect est détecté, des notifications significatives alertent l’utilisateur du
risque encouru et demande l’autorisation de le supprimer.
Les utilisateurs ont aussi la possibilité d’adhérer à la communauté des Spynet de Microsoft dans le
monde entier. Ils peuvent ainsi aider les chercheurs de Microsoft à détecter et archiver tous les
spywares émergents afin de mettre en place des méthodes pour réagir face à ces menaces. Ces
méthodes sont téléchargées automatiquement en tant que mise à jour de Microsoft Windows
antispyware.
Internet Explorer 7
Microsoft a mis à jour son logiciel phare avec la venue, le 18 octobre 2006, de Windows Internet
Explorer 7. Cette version est proposée en téléchargement par le biais de Windows Update comme
mise à jour importante, mais peut être installée dès sa sortie sans attendre qu'il soit disponible sur
Windows Update. Dans Windows Vista, IE n'est plus une application étroitement intégrée au système
et peut être désinstallée comme n'importe quel autre logiciel, ceci à des fins de sécurité et de respect
de la concurrence. Cette nouvelle mouture remet en quelque sorte IE sur un pied d'égalité face à ses
concurrents, bien qu'il soit installé par défaut.
Internet Explorer 7, apporte de nouvelles fonctionnalités de sécurité plus puissantes afin de protéger
votre ordinateur des virus et des logiciels espions. De plus, Internet Explorer 7 affiche des
avertissements quand vos informations personnelles risquent d'être menacées.
Windows Defender
Il fonctionne avec Internet Explorer 7 pour empêcher les logiciels espions de s'installer sur votre
ordinateur. Ces derniers tentent notamment d'investir votre ordinateur lorsqu'ils sont inclus dans
des programmes téléchargés. Windows Defender est fourni avec Windows Vista. Si vous pouvez le
télécharger gratuitement pour Windows XP SP2.
Le filtre anti-hameçonnage
Le filtre anti-hameçonnage est un outil efficace pour vous protéger des usurpations d'identité.
Internet Explorer 7 offre un accès à un service de filtre en ligne qui vous prévient quand il détecte des
tentatives d'hameçonnage provenant de sites Web et visant à voler vos informations confidentielles.
Le filtre analyse votre ordinateur et recherche des éléments caractéristiques de techniques
d'hameçonnage. Il consulte également les données provenant du service en ligne qui sont mises à
jour plusieurs fois par heure.
Les certificats SSL
Internet Explorer 7 prend en charge les certificats SSL de validation étendue. Ceux-ci garantissent
non seulement que la communication avec un site Web est sécurisée, mais ils incluent également des
informations sur le propriétaire du site Web qui a été identifié par l'autorité de certification
émettrice du certificat SSL.
La barre d'adresses devient verte pour vous avertir que des informations supplémentaires sur le site
Web, sont disponibles. L'identité du propriétaire du site Web s'affiche également dans la barre
d'adresses.
31
La navigation par onglets
Cette nouvelle version dispose d'une navigation par onglets. Ces onglets sont déplaçables, et
entièrement modifiables dans le panneau de contrôle. On peut sauvegarder les onglets pour une
utilisation ultérieure ainsi que visualiser tous les onglets ouverts en cliquant sur un seul et même
bouton, pour les déplacer ou les fermer facilement en ayant un aperçu de la page active dans chacun
des onglets. Les onglets sont nouveaux dans IE7, ils permettent de n'avoir qu'une seule fenêtre de
navigation dans la barre des tâches et rendent ainsi la navigation sur le net beaucoup plus pratique.
La désactivation des contrôles ActiveX
Vue la criticité des attaques qui exploitent les vulnérabilités des contrôles ActiveX, une technologie
propriétaire Microsoft qui ne fonctionne qu'avec Internet Explorer et uniquement sous Windows. IE7
désactive les ActiveX installés par défaut dans le navigateur pour en permettre un meilleur contrôle
par l'utilisateur.
La protection contre les logiciels malveillants
Internet Explorer 7 intègre une importante amélioration de la sécurité pour aider à prévenir le risque
d'installation de logiciels malveillants. Cela signifie qu'il réduit les possibilités que des pirates
informatiques puissent être en mesure de perturber ou d'endommager la machine client.
Protection des données à caractère personnel
Microsoft s'est également attaché à améliorer la sûreté de son navigateur, grâce à un filtre antiphishing. IE7 intègre un filtre anti-phishing qui permet de vérifier, instantanément et sans ralentir la
navigation, que le site visité n'appartienne pas à une liste noire de sites Web falsifiés. Cette liste est
mise à jour par Microsoft et les sociétés de sécurité qui surveillent l’Internet.
Le service de filtre anti-phishing d’Internet Explorer 7 permet à l’utilisateur de repérer et de signaler
tout site suspect, de protéger vos données personnelles et de minimiser le vol d'identité. IE 7
propose également des certificats de validation SSL qui vous permettent de savoir si vous êtes sur un
site de confiance ou non.
IE7 sous Vista
Parmi les nouvelles avancées en ce qui concerne la sécurité d’IE7, la version pour Windows Vista
offre une sécurité plus renforcée dans l'utilisation du navigateur. En effet, Vista crée une zone isolée
dans laquelle IE7 s'exécute. De ce fait, il est isolé du reste du système, ce qui devrait empêcher toute
sorte de logiciels malveillants d'infecter le système.
Sous Windows Vista, IE 7 fonctionne indépendamment des autres applications. Cela permet
d'augmenter la sécurité de la machine cliente en limitant l'exploitation et l’écriture de fichiers
suspects en dehors des fichiers Internet temporaires, sans le consentement de l’utilisateur.
Internet Explorer 7 dispose d’une protection contre les sites Web frauduleux et d'une meilleure
notification lorsque vous êtes sur un site sécurisé. Il offre une bonne protection de la vie privée, des
mots de passe, et lorsqu'il est utilisé avec Windows Vista, IE 7 comprend le contrôle parental pour
aider à garder votre famille en sureté.
IE8
Face à Firefox qui ne cesse de gagner du terrain, IE7 n'est plus en mesure de relever les nouveaux
défis du Web. Microsoft a donc développé Internet Explorer 8, dont la première version d’essai
privée était dévoilée au mois de mars 2008. IE8 permet plusieurs améliorations aussi bien en termes
d’ergonomie que de fonctionnalités.
32
La rapidité, critère de réussite
Les navigateurs deviennent en effet de véritables machines à faire tourner les applications en ligne.
Tout se passe désormais dans la fenêtre du navigateur que ce soit de la messagerie instantanée, du
traitement de texte, de la localisation géographique par satellite, des réseaux sociaux, ou du
streaming, plus rien ne se passe au sein de logiciels dédiés. Mais pour cela, il faut une nouvelle
génération de navigateurs capables de traiter à la volée des pages Web de plus en plus complexes et
d’afficher toujours plus vite des pages animées, des vidéos, …
Avec IE 8, Microsoft espère rattraper ses concurrents. Les premiers tests de rapidité, réalisés sur la
version quasi définitive du logiciel ont montré les progrès de l’éditeur. Dans cette version assez
évoluée d’IE, on utilise dans les flux RSS de nouveaux composants « webslices » qui permettent de
visualiser rapidement les contenus dynamiques.
Dans cette même optique de faciliter la navigation, de la rendre plus fluide et rapide, IE8 intègre un
lot de raccourcis très pratiques appelé « accélérateurs ». Ceux-ci permettent d’accéder directement
à certaines options ou de faire des sauts directs vers d’autres pages (traducteurs, encyclopédie, ou
réseau social) en un simple clic sur le bouton contextuel de la souris. Ils couvrent tous les domaines
et sont personnalisables au niveau de IE Add on.
Toutefois ces progrès en termes de rapidité et de fluidité restent insuffisants pour dépasser la
concurrence. Microsoft met alors en avant les progrès réalisés en termes de sécurité et d’ergonomie.
IE8 a été promu le navigateur le mieux sécurisé par NSS labs. Côté sécurité, plusieurs mécanismes
ont été mis en place pour garantir un très haut niveau de sécurité et surtout assurer le respect de la
vie privé des utilisateurs.
Des onglets avec des mémoires isolées
Comme son prédécesseur IE7, Internet Explorer8 offre aussi aux internautes la possibilité de
navigation par onglets, mais cette fois-ci en prenant en considération l’aspect sécurité. En effet dans
IE8, les onglets s'exécutent sans qu’il n’y ait aucune interférence entre eux, ils utilisent chacun un
processus mémoire isolé. Du coup en cas de plantage, tous les onglets ouverts peuvent être
restaurés en réouverture de session IE. Le seul inconvénient de cette nouveauté est une
consommation plus importante des ressources système, mais l’apport en termes de sécurité en vaut
bien le cout.
Navigation privée sans trace
L’une des nouveautés majeure d’IE8 est que celui-ci donne aux internautes une multitude de moyens
pour protéger leur vie privée lorsqu’ils surfent sur le Net. IE8 leur permet de contrôler les
informations qu’ils laissent sur leur PC, mais aussi d’empêcher les sites qu’ils visitent de collecter des
informations à leur insu. Ainsi l’utilisateur peut ouvrir une session de navigation privée et pourra
surfer sur la toile sans laisser de traces sur les sites visités, ni cookies, ni fichiers Internet temporaires,
ni historique ou autre donnée qui pourraient révéler le contenu ou la nature des pages parcourues.
Rien de tout cela n’est conservé sur le disque dur du PC de l’utilisateur.
Accessible par le biais d'un nouveau menu Sécurité, ce mode de navigation une fois activé permet à
l’utilisateur d’échapper à la surveillance des sociétés de marketing avides de connaître leurs
habitudes de navigation.
33
Ce mode peut être aussi personnalisé et l’on peut choisir le degré de confidentialité désiré à partir du
bouton Paramétrages de filtrages InPrivate dans la barre d'état du navigateur. Pour les utilisateurs
distraits qui auraient oublié d’activer ce mode, IE8 permettra aussi de supprimer de manière très
sélective après coup les données stockées pendant leur navigation.
Le filtre SmartScreen
Parmi les mécanismes de sécurité intégrés dans IE8, le Filtre SmartScreen est un outil qui permet de
vérifier la légitimité des sites pour déterminer lesquels sont malveillants. Il protège l’utilisateur de
toute sorte d’endommagement que l’accès à ces sites pourrait engendrer.
En plus de la protection anti-phishing, le filtre SmartScreen s'attaque à la lutte anti-malware en
bénéficiant de la liste noire des sites d’exploits distribuant des logiciels malveillants. Il analyse aussi
les différents logiciels en se basant sur différentes autres technologies intégrées aux navigateurs
telles que Malicious Software Removal Tool, Windows Defender et Windows Live OneCare.
Cet outil alerte l’utilisateur en cas de danger et lui affiche une page spécifique pour le dissuader de
poursuivre ses opérations (consultation de site ou installation de logiciel).
Au-delà de SmartScreen d'autres fonctionnalités de sécurité seront présentes dans IE8 avec un filtre
XSS pour prévenir les attaques Cross Site Scripting, une communication mieux sécurisée avec les
iFrames, ou encore des modifications dans la manière dont les contrôles ActiveX sont manipulés.
Le filtre de script intersites (XSS)
Internet Explorer 8 est doté de la capacité de détecter les programmes malveillants sur les sites Web
compromis. Les développeurs d’IE 8 ont mis en place un filtre XSS qui permet de bloquer les attaques
intersites. Des attaques très récurrentes qui sont devenues une très grande menace en ligne. Ce filtre
assure ainsi la protection de l’utilisateur contre toute sorte de divulgation de renseignement ou de
piratage de cookie, d'identité et de comptes.
34
La prévention de l'exécution des données (PED)
Internet Explorer 8 active par défaut la prévention de l’exécution des données(PED), une nouvelle
fonction de sécurité qui empêche certains types de codes de s’exécuter dans l’espace mémoire,
prévenant ainsi de l’endommagement potentiellement causé par un virus ou un logiciel malveillant.
En effet IE 8 tire profit de la future norme Html5 et implémente une nouvelle fonctionnalité « Crossdocument messaging » permettant aux IFRAME de communiquer de manière plus sécurisée tout en
maintenant l’isolation des objets DOM entre eux. Cette dernière version utilise aussi pour désinfecter
le code HTML une nouvelle méthode appelée « toStaticHTML », qui filtre le code Html et désactive
automatiquement tout script potentiellement exécutable.
La barre d'adresse intelligente et l’historique
La barre de saisie des adresses Internet Explorer se veut désormais plus intuitive. Elle se montre
beaucoup plus intelligente que prévue, permet de faciliter la navigation, de la rendre immédiate en
s’appuyant sur l’historique de navigation. Elle suggère à l’utilisateur les correspondances
appropriées, pour lui permettre un accès au plus rapide vers le site désiré.
Par ailleurs, la barre d’adresse d’IE8 permet aussi de mieux déceler le nom de domaine au niveau de
l’adresse URL en le mettant en évidence(en bleu et gras) afin d’éviter toute ambiguïté pouvant être
générée par un site d’hameçonnage visant à exploiter une usurpation du nom de domaine pour
générer une attaque.
La restauration après crash
A l’instar des autres navigateurs concurrents (Firefox et Opera), Internet Explorer propose dans sa
dernière version un système de restauration. Il permet en cas de plantage de récupérer toutes les
sessions ouvertes par l’utilisateur pour que celui-ci ne perde pas son environnement de navigation.
35
Les autres navigateurs
Google – Chrome v 2.0
Présentation
Google est une société spécialisée dans les outils de recherches Internet, chats, e-mails et autres
projets collaboratifs. Multipliant ses offres et services à l’intention des Internautes, les équipes de
Google ont souhaité produire leur propre navigateur. Celui-ci devrait être innovant mais aussi
intégrer les meilleures fonctionnalités existantes.
D’apparence simple avec une interface épurée, Google Chrome a pour objectif de lancer les bases
d’un navigateur gérant beaucoup mieux les applications Web récentes tout en garantissant une
certaine rapidité de navigation. Par sa gestion individuelle des onglets, Chrome est en mesure
d’empêcher qu’un onglet contaminé ne bloque les autres. Ceci permet une meilleure protection face
aux sites à risques. Il embarque aussi un mode de navigation privée qui permet de garantir à
l’Internaute un certain niveau d’anonymat. Lorsque ce mode est activé, aucune donnée relative à la
session utilisateur ne doit être conservée sur la machine cliente. Le navigateur intègre notamment un
système de sécurisation permettant de vous prévenir quand vous accédez à un site de phishing, un
site susceptible d’installer des logiciels malveillants, ou tout autre site dangereux. Parmi ces
nouveautés, Chrome intègre aussi un moteur JavaScript plus puissant appelé « V8 ». Il devrait être
capable de faire tourner la prochaine génération d’applications Web que les navigateurs concurrents
ne supportent pas à l’heure actuelle.
Les équipes de Google reconnaissent la forte implication des communautés du logiciel libre qui ont
largement contribué au résultat obtenu. Ayant réutilisé de nombreux composants en provenance
d’Apple Webkit et de Mozilla Firefox, elles s’engagent à laisser leur code en Open Source.
La sandbox
Son but est de se prémunir contre l’installation intempestive des malwares, ainsi que de protéger
chaque onglet d’une possible contamination par les autres. Ainsi, chacun de ces processus a été
dépourvu de ses droits : ils peuvent donc calculer mais ne peuvent ni écrire de fichiers sur votre
disque dur, ni lire de fichiers depuis des espaces sensibles tels que vos documents ou votre bureau.
Théoriquement la sandbox est une prison permettant d’éviter à tout site malveillant de récupérer
vos informations personnelles, d’interdire les enregistrements d’évènements souris-clavier et
d’installer des exécutables comme porte dérobée. Cela implique que si une attaque est en cours dans
l’un de vos onglets, il suffit de le fermer pour qu’elle cesse. En principe, il n’y a ni d’impact sur les
autres onglets, ni sur les autres processus.
Elle repose sur un concept de permissions, identique à celui de Vista : le modèle de sécurité BIBA
garantissant l’intégrité des données. Pour cela il utilise les notions de classification et d’habilitation
avec les règles suivantes : l’utilisateur ne peut qu’écrire des données dont la classification est
inférieure ou égale à son habilitation et les données ne peuvent être lues que par des utilisateurs
ayant une habilitation inférieure ou égale à la classification des données.
L’exception provient de la gestion des plugins, certains d’entre eux s’exécutent à des niveaux de
permissions identiques voire supérieurs à celui du navigateur. Une majorité de plugins possède des
capacités qui ne respectent pas les standards publiques et ne peut être joués dans la sandbox. Les
équipes de développement travaillent donc avec les éditeurs de plugins pour réduire les privilèges
utilisés afin de réduire les vulnérabilités induites. Aussi, quand un plugin est combiné à des codes
Html et Javascript, le crash d’une partie entraine souvent le plantage de l’ensemble. Les équipes ont
36
dû travailler à extraire le code du processus associé au plugin et le rendu de la page. Il est maintenant
possible de jouer le reste de la page dans la sandbox même si le plugin ne peut l’être.
Les black lists
Pour faire face aux attaques, Chrome télécharge continuellement des listes de sites nuisibles : l’une
contre le phishing, l’autre contre les malwares. Ainsi, l’utilisateur est prévenu par un message
d’alerte quand il s’apprête à se rendre sur un tel site. Ce service est gratuit et disponible via l’API
publique. En ce qui concerne les malwares, le plus souvent les administrateurs de sites infectés
corrigent les failles une fois informés.
Les failles découvertes
Les démonstrations de la Blackhat 2008 ont prouvé que les versions antérieures à Chrome v 2.0
étaient vulnérables à 2 types d’attaques : l’exécution de code arbitraire à distance et l’atteinte à la
confidentialité des données. Les attaques exploitant certaines failles dans la gestion des évènements,
étaient réalisées par le biais de pages Web malveillantes spécialement conçues pour piéger les
Internautes. Le CERTA français recommande d’ailleurs l’application des patchs de sécurité datant de
juin 2009.
De même, les équipes d’IBM ont démontré que les versions précédentes à Chrome v 1.0 étaient
vulnérables à des attaques XSS, capables d’outrepasser les restrictions de la Same Policy Origin, sans
aucune interaction avec le client. Le principe était de combiner les vulnérabilités suivantes :
Le chargement d’URL arbitraires via le « CHROMEHTML URI »
<html>
<script>
document.location = 'chromehtml:"80 www.attacker.site.com';
</script>
</html>
L’exécution de code Javascript en ligne de commande
<html>
<script>
document.location = 'chromehtml:"80 javascript:eval('alert(\'JavaScript%20Code%20Executed\'); '));'
</script>
</html>
L’exécution de code Javascript sur le contexte d’un domaine arbitraire
<script>
setTimeout("alert(document.cookie);", 2000);
document.location.assign("http://demo.test.site/");
</script>
Enfin, il est possible d’exploiter les options de Chrome telles que l’énumération des fichiers locaux ou
autres dossiers. Le rapport d’IBM peut être consulté ici.
Les différentes mises à jour ont résolu ces failles de sécurité, toutefois Chrome doit encore faire ses
preuves. L’augmentation de ses utilisateurs induira des rapports d’erreurs plus conséquents et donc
une résolution des vulnérabilités plus rapide. Cependant, cette popularité attirera aussi des
attaquants supplémentaires.
37
Apple – Safari v 4.0
Présentation
Il s’agit du navigateur d’Apple, sa rapidité et la convivialité de son interface sont ses points forts. Ce
navigateur est allégé au maximum, il peut ainsi être intégré dans des environnements mobiles
comme les téléphones portables. Il est donc présent sur les produits phares d’Apple tels que l’iPhone
ou l’iPod Touch, apportant aux utilisateurs une simplicité de navigation et la rapidité d’accès à
l’information.
Les éléments de sécurité
Apple ne donne aucune information technique sur les solutions déployées par ses équipes de
développeurs garantissant la sécurité des utilisateurs de Safari. En revanche, la lecture de la
documentation marketing du navigateur nous apprend que celui-ci embarque un certain nombre de
protections :
Un filtrage des sites de phishing : en cas de visite d’un site suspect, le navigateur affiche un
message d’avertissement et bloque le chargement de la page consultée ;
Un filtrage des sites hébergeant des malwares : le navigateur est capable d’identifier les sites
malveillants avant même que vous ne les visitiez. Si le cas se présente, Safari vous notifie le
caractère suspect du site ;
Votre antivirus : lors du téléchargement de tout fichier, le navigateur sollicite l’intervention
de votre logiciel antivirus (module Windows Attachment Monitor). Celui-ci scanne alors les
fichiers à la recherche de virus ou malwares ;
Un mode de navigation privée : aucune donnée personnelle saisie n’est enregistrée ou
stockée dans le cache. L’historique de votre parcours sur le Web ne prend pas en compte les
sites que vous avez visités ;
Le blocage des pop-up : les publicités intempestives sont bloquées automatiquement ;
Les certificats Extended Validation : ils sont supportés par le navigateur, ce qui permet
d’identifier les sites Web et sociétés légitimes. Ils sont signalés par la coloration verte de leur
nom dans le champ d’adresse ;
Le blocage des cookies : certains d’entre eux espionnent la navigation de l’utilisateur. Afin de
protéger votre vie privée, Safari les neutralise et n’autorise que les cookies issus du domaine
visité ;
Les téléchargements « sécurisés » : le navigateur renseigne l’heure et la provenance de
chacun de vos téléchargements. A leur première ouverture, Mac OS X vous informe de leur
origine, vous permettant un ultime contrôle ;
Le chiffrement « sécurisé » : il permet de garantir la confidentialité des échanges mais aussi
leur intégrité. Ainsi, Safari supporte la majorité des protocoles de sécurité actuels : SSL v2 &
v3, TLS, le chiffrement SSL sur 40 et 128 bits et les applications java signées ;
Les protocoles d’authentification : le navigateur supporte les technologies d’authentification
normalisées, telles que l’authentification à signature unique Kerberos et les certificats X.509,
ainsi que des protocoles propriétaires tels que NTLM v2 ;
Le contrôle parental et son filtre personnalisé : le navigateur peut avoir recours au contrôle
parental de MAC OS X afin de déterminer la pertinence des sites avant leur chargement et le
cas échéant bloquer l’accès au site Internet. Il est d’ailleurs possible de customiser la liste des
sites autorisés ou interdits en passant par les préférences système. Il est aussi possible de
vérifier l’ensemble des sites visités via l’historique du navigateur ;
38
La prise en charge des proxy : le navigateur supporte et détecte les derniers protocoles de
proxy : la configuration automatique, le Ftp proxy, le Web proxy (Http & Https), le streaming
proxy (Rstp), les proxy de socket et les proxy Gopher ;
La mise à jour automatique
L’effacement des traces de navigation : historique, cookies, cache, téléchargements, mots de
passe, formulaires de saisie, …
Avec cet ensemble de protections, Safari revêt l’image d’un navigateur fiable et parfaitement
sécurisé. Cependant, l’absence de spécifications techniques et une lecture approfondie des
plaquettes commerciales soulèvent de nombreuses questions quant aux moyens réellement mis en
œuvre.
Les failles découvertes
Plusieurs brèches de sécurité on révélé les risques suivants : l’exécution de code arbitraire à distance,
l’injection de code indirecte, le déni de service à distance, le contournement de la politique de
sécurité. Selon le CERTA, il est indispensable de mettre à jour les versions de navigateurs qui sont
antérieures à Safari v4.0 (avis datant de Juin 2009). Ces vulnérabilités touchent l’ensemble des
plateformes Mac OS X, Windows XP et Vista.
Les vulnérabilités identifiées étaient les suivantes :
L’exécution automatique de code Javascript à partir de fichiers Html identifiés comme des
images ;
Le composant CoreGraphics vulnérable à plusieurs corruptions de mémoire, autorise
l’exécution de code arbitraire à distance ;
Le composant WebKit contient plusieurs failles de sécurité, rendant le navigateur vulnérable
aux attaques XSS et permettant aussi l’exécution de code arbitraire à distance.
Ces différentes brèches démontrent bien que Safari n’est pas moins vulnérable que les autres, face
aux attaques du navigateur.
Opera v 9.64
Présentation
De même que Safari, le navigateur Opéra est un navigateur dont les avantages sont la légèreté et la
convivialité de son interface. Il est notamment disponible sur les téléphones portables, les
Smartphones, les PDA mais aussi sur les plateformes de jeu… Des versions plus complètes
embarquent des outils de messagerie, de gestion des contacts, de messagerie instantanée, de
partage via BitTorrent.
La sécurité
Tout comme l’ensemble de ses concurrents, le navigateur d’Opera embarque différents mécanismes
de sécurité afin de protéger les utilisateurs :
Le chiffrement : Opera supporte les protocoles SSL v3, TLS et offre des tailles de clés de 256
bits : la plus haute sécurité actuellement disponible sur les navigateurs web ;
Le nettoyage des informations de navigation : données privées, historique des sites visités,
cache, formulaires de saisie…
Le contrôle des cookies : Opera vous permet de manager la gestion des cookies à partir de
rapports détaillés intégrant une recommandation sur l’action à mener ;
39
La barre de sécurité : le navigateur intègre une barre d’informations relatives aux
informations de sécurité disponibles pour le site visité ;
La protection contre le phishing et les malwares : le navigateur détecte automatiquement et
vous avertit sur les sites Web frauduleux. Pour le phishing, la protection se base sur les
informations dispensées par Netcraft et PhishTank. Pour les malwares, Opera fait appel à une
solution de Haute Secure ;
Les certificats Extended Validation : ces certificats délivrés sur des critères stricts, permettent
d’apporter des garanties supplémentaires sur la nature du site visité.
Les failles
Le CERTA remonte principalement un seul risque : l’exécution de code arbitraire. La vulnérabilité
provient d’un problème de gestion des adresses URI de type file:// dont la longueur n’est pas usuelle.
Elle permet à l’attaquant d’exécuter un code arbitraire suite à un débordement de buffer faisant
appel à un fichier Html spécialement construit. Exploiter cette vulnérabilité requiert la présence de
ce fichier sur la machine locale. La version 9.64 du navigateur apporte les solutions de gestion de
cette brèche.
La nouvelle plateforme
Avec « Opera Unite », le groupe Opera Software ASA souhaite révolutionner le Web. En effet, celle-ci
propose d’abandonner l’ancien modèle Client-Serveur, afin de profiter des ressources disponibles sur
les machines des Internautes. Ainsi le navigateur intègre un serveur Web et se transforme en
hébergeur de contenus disponibles sur Internet.
Concrètement, ce navigateur n’apporte aucun service réellement nouveau, mais il permet
d’embarquer plusieurs outils de partage sur une même plateforme. En revanche, ces services
impliquent de s’interroger sur les nouveaux enjeux de sécurité : la lutte contre le piratage, la copie
illégale, l’accès aux ressources du client, les conditions d’utilisation… Aussi, transformer l’ensemble
des machines clientes en serveurs Web, ne sera pas très profitable au développement durable.
40
Comparatif des navigateurs
L’avis général
Tous les principaux éditeurs ont livré dernièrement une nouvelle version stable de leur logiciel de
navigation. De cette compétition, c'est l'internaute qui est le vrai gagnant. Pour rappel, IE n'avait rien
proposé d'innovant depuis qu'il avait acquis sa position de quasi monopole. Mais suite à la
progression de Firefox, Microsoft avait consenti à livrer plus rapidement un IE7 apportant de réelles
améliorations. On notera donc que cette rude compétition est source d'innovations.
La tendance est au respect des standards même si certains navigateurs sont bien meilleurs que
d'autres. On se dirige aussi vers une sécurité accrue, qui est l'un des défis posés aux éditeurs. Les
anciennes versions étaient totalement dépourvues face aux tentatives de vol de données ou
d'injection de codes malveillants. Les versions actuelles s'efforcent de détecter les sites imposteurs
(phishing) en se référant à une blacklist d'URLs qui est alimentée par Microsoft ou Google. Cette
première réponse est loin d'être suffisante face à la réactivité des pirates. En attendant de nouvelles
solutions, il faut donc rester soupçonneux et ne pas hésiter à ajouter au navigateur des extensions
permettant de bloquer les contenus actifs.
La répartition des parts du marché des navigateurs Internet en début d’année 2009 se présente de la
manière suivante :
 Microsoft : IE 7,8 avec 66%
 Mozilla : Firefox 3 avec 23%
 Apple : Safari 3 avec 8%
 Google : Chrome avec 2%
 Opera : 1%
Firefox Version 3
Elle vérifie de façon plus stricte les certificats SSL et restitue plus clairement les informations. Tandis
que la version précédente du navigateur permettait d'outrepasser assez facilement les messages
signalant un certificat invalide, celle-ci interdit de fait l'affichage des pages concernées. Cette
solution renforce la sécurité des utilisateurs au détriment des sites amateurs qui utilisent des
certificats autosignés.
Firefox exige maintenant que les modules complémentaires soient capables de se mettre à jour de
façon sûre. De plus les applications trop anciennes non maintenues seront désactivées. Cette
décision est utilisée pour freiner la prolifération des modules de mauvaise qualité, mal entretenus
par leurs auteurs, pouvant porter atteinte à la sécurité et la réputation du navigateur.
Quelques extensions pour la sécurité de Firefox 3 :
-> AdBlockPlus : filtre simple pour supprimer les bannières publicitaires. Le module se base sur une
liste de serveurs de bandeaux, régulièrement actualisée.
-> Web Developpeur : propose une boîte à outils pour débugger des pages, éditer des CSS ou des
formulaires, désactiver des fonctions ou le script.
-> NoScript : filtre éliminant les programmes en JavaScript en se basant sur le nom de domaine ou
l'URL. Permet de se prémunir de certaines attaques à base de JavaScript.
-> Firebug : propose une fenêtre d'inspection de tous les éléments de la page visité : HTML, DOM,
CSS, scripts... Et en permet la modification.
41
IE Version 8
Est une version plus conforme aux standards du Web. Parmi les nouveautés, on retrouve un élément
de menu "Web Developper" regroupant des outils d'édition du code HTML, CSS et un débuggeur de
scripts. Ces nouveautés sont présentes pour contrer Firefox dont les extensions apportent des
fonctions équivalentes depuis longtemps.
Module de sécurité pour IE 8 :
-> Windows Defender : logiciel anti espion de Microsoft qui recherche et neutralise les programmes
publicitaires s'installant sans permission sur votre machine, espionnant votre comportement et vous
servant des publicités sur mesure.
Safari Version 3
Navigateur conçu à l'origine pour les utilisateurs de Macintosh, il a été décliné pour Windows lui
permettant d'augmenter son implantation. Sa stabilité est excellente si on en juge par sa résistance
au crash. Son moteur de rendu est le premier à atteindre 100% de réussite au test Acid 3. Le temps
de traitement est bien plus rapide qu’IE 8 mais moins que Firefox 3.
Safari propose via son site Pimpmysafari.com quelques extensions : automatisation de scripts,
débogage de JavaScript. Si la plupart sont gratuites, la majorité ne fonctionne que sous MAC.
Opera Version 9.5
Au départ payant, ce navigateur suit aujourd'hui la tendance du Web en devenant gratuit. Il est
surtout utilisé par un public féru d'informatique qui lui porte une grande estime. Depuis son origine,
il s'efforce de respecter les standards du Web. Il est surtout adapté aux petits PC mobiles, du fait de
sa capacité à afficher les sites sur de petits écrans et à sa faible consommation de mémoire.
Les fonctions d'Opera peuvent être étendues grâce à des widgets conçus pour ce navigateur et des
réglages appropriés : blocage des publicités, ...
Chrome
Imparfaite, encore indisponible sous Linux & Mac OS, cette bêta du premier navigateur de Google
paraît prometteuse par son efficacité et son architecture multitâche optimisée. Il faudra tout de
même attendre pour juger de son niveau de sécurisation. La première faille de sécurité a été révélée
par plusieurs experts et publiée sur Google Code. Elle est localisée dans la bibliothèque chrome.dll et
permet à des sites malveillants de crasher le navigateur simplement et de supprimer tous les onglets
ouverts. Le conseil est donc d'attendre une version finale validée avant de migrer vers Chrome.
42
Comparaison des vulnérabilités
Ces différents comparatifs sont issus du rapport Secunia de 2008. On remarque que Firefox regroupe
le plus grand nombre de vulnérabilités et un œil non averti pourrait interpréter que Firefox dispose
du plus mauvais niveau de sécurité. Cependant c’est oublier la politique de transparence des équipes
de Mozilla à communiquer sur les failles de sécurité. Cette politique n’est pas adoptée par l’ensemble
des éditeurs du marché, notamment Microsoft qui ne communique pas toujours sur les failles ou
vulnérabilités détectées en interne. En conclusion, on peut déduire que ce n’est pas parce que les
entreprises n’en parlent pas que les vulnérabilités sont inexistantes. Certaines on juste une culture
du secret plus poussée que d’autres. Cela se traduit dans le tableau (ci-dessous) des vulnérabilités
non résolues qui regroupe des mauvais élèves tels qu’Internet Explorer & Opera, et de meilleurs
élèves Firefox & Chrome. Ce qui recoupe notre première analyse, puisque seule une large
communication sur les failles de sécurité peut apporter une résolution rapide par une large
communauté de développeurs.
43
Les vulnérabilités associées aux plug-ins regroupent principalement des failles liées à la technologie
ActiveX, et quelques autres glissées parmi Java, QuickTime, Flash… On comprend le besoin
d’augmenter la sécurité des navigateurs face à ces outils à l’origine d’une grande partie des attaques.
Pour conclure, le schéma suivant représente la répartition des attaques en fonction de leur catégorie
et de leur répartition dans le temps. On remarque une nette progression des attaque XSS, un
maintien des attaques de type déni de service et une augmentation du vol d’informations sensibles…
44
Le Web 2.0 et ses nouvelles menaces
Introduction au Web 2.0
Aujourd'hui, nous assistons à la convergence des différents appareils ainsi que le mouvement vers
une véritable mobilité d’accès à Internet à partir des téléphones mobiles, des PDA et des ordinateurs
portables. Tout est relié par un réseau de connexions Internet sans fil. Une avancée très significative
qui multiplie encore et encore l’usage de la toile et qui nécessitera l’implémentation de nouveaux
services, tout en prenant en considération les enjeux sécuritaires qui doivent être traités en parallèle.
Le web2.0 est l’évolution actuelle des contenus et des langages disponibles sur le net, il marque une
étape majeure dans l’évolution de l internet, c’est un ensemble d’outils et d’usages qui enrichissent
l’expérience de l’utilisateur sur internet en s’appuyant sur de nouvelles technologies et en se basant
sur deux éléments clé :
 La participation des utilisateurs est indispensable : tout est conçu autour de l’internaute qui
devient la base du système, c’est un élément proactif qui participe, échange et partage des
données, d’où la notion des différents outils de publication dynamique qui sont apparus avec
le web2.0.
 La disponibilité des données, la facilité de transfert et de partage des données ou services. Le
WEB 2.0 permet aux internautes de surfer plus rapidement sur la toile et de pouvoir accéder
aux données stockées sur une application web2.0 quelque soit le lieu ou le moyen utilisé
pour se connecter à internet.
Le Web 2.O et les nouvelles technologies
Le web 2.0 est un cocktail d’une multitude de nouvelles technologies grâce auxquelles les nouvelles
applications deviennent dynamiques, plus rapides et plus fluides. Cependant, il crée de nouvelles
opportunités d’attaques. Les développeurs se retrouvent donc face à un dilemme entre la sécurité et
la convivialité. Pour pouvoir maintenir un équilibre entre ces deux aspects, il faut d’abord
comprendre toutes les failles de sécurité du web2.0 et pour cela posséder une connaissance basique
des différentes technologies utilisées s’avère indispensable. La figure suivante illustre l’architecture
Web 2.0 ainsi que les différents éléments que l’on abordera par la suite.
45
Les technologies coté client
Le web 2.0 contrairement à ses prédécesseurs utilise de nouveaux composants : Ajax et Flash, fondés
sur des codes JavaScripts. Ils rendent l’interface client beaucoup plus attractive et plus adaptées aux
différents moyens de connexions que ce soit des navigateurs Web, des PDA ou des téléphones
portables.
Ajax est une combinaison du JavaScript et du XML, permettant de faire évoluer une partie du
contenu de la page visionnée sans avoir à tout recharger. Il s agit d’une méthode de communication
asynchrone qui permet un meilleur service Internet, en termes de fraicheur et de rapidité, à
l’utilisateur final. En effet contrairement aux techniques ultérieures du web 1.0, le web 2.0 sollicite le
poste client et manipule les données qui y sont présentes grâce aux codes JavaScript et à partir
d’informations prises sur le serveur d’applications web. Ainsi la modification de la page web affichée
par le navigateur devient plus facile et plus rapide puisqu’elle ne fait pas appel à chaque fois au
serveur web.
Protocol et chaine de communication
Les applications Web2.0 utilisent le protocole Http comme support de plusieurs autres protocoles,
l’une des limitations de ceux-ci consiste dans le fait qu’ils ne permettent pas l’envoi de flux de
données entre le navigateur et le serveur web. Cette limitation a été dépassée grâce à l’utilisation de
l’Ajax.
L’utilisation de protocoles XML est d’un très grand apport pour l’architecture Web2.0 et elle garantit
une communication plus simple entre les différents niveaux de l’architecture. En effet SOAP, XMLRPC, et REST sont des protocoles primordiaux dans la couche protocolaire du Web 2.0. Le protocole
XML-RPC est généralement utilisé pour faire des appels à distance au système d’exploitation tout en
utilisant comme support le protocole HTTP. SOAP a un rôle similaire à celui de XML-RPC et il est très
populaire puisqu’il supporte les services Web SOA sous un format XML. Le troisième protocole
supporté par Http est REST (Representational State Transfer), c’est une nouvelle architecture
d’application web qui utilise des structures XML pour permettre au client de communiquer avec le
serveur et vice versa.
Les structures de données sur Internet
Le web1.0 utilisait de simple méthode Http « get » et « post » pour réaliser les échanges entre le
navigateur web et le serveur web. Toutefois avec l’introduction d’Ajax et d’autres technologies, le
web2.0 échange de nouvelles structures telles que Java Script Object Notation(JSON), Really Simple
Syndication(RSS) et Java Script-Array…
L’environnement applicatif
Web 2.0 est basé sur une plateforme orientée service SOA. Il s’agit d’un ensemble de services
destinés à être utilisés par le navigateur ou par d’autres applications web et qui ont pour but
principal d’assurer les communications entre les différentes applications.
Le Web 2.0 et les failles de sécurité
Le nouvel engouement pour le web2.0 pose de nouvelles problématiques de sécurité qui doivent
être prises au sérieux par les RSSI et cela en analysant de manière approfondie les différents risques
et menaces qui s’imposent à chaque niveau de l’architecture web2.0.
Les attaques du Web 1.0 s’appuyaient sur la prise d’empreinte et la manipulation des champs cachés,
toutefois celles concernant le Web2.0 se focalisent plutôt autour du Scripting omniprésent dans le
moteur Ajax. Elles exploitent les failles relatives à l’insertion de code.
46
L’injection de code ( Html, XML, …)
Les tags Html comme pour les objets DOM au niveau d’un navigateur Web peuvent être manipulés
dynamiquement, ainsi certains peuvent être injectés au niveau des applications Web afin de
permettre à un attaquant d’atteindre un résultat désiré. Ces tags Html peuvent représenter une
menace critique pour l’utilisateur final.
Manipulation de code ( JavaScript, …)
Le langage JavaScript est un élément clé des applications Web2.0, toutefois celui-ci permet d’accéder
au contenu des objets DOM et de le manipuler. C’est une faille qui peut être exploitée afin de
générer une attaque.
Cross site Scripting
Comme elle a déjà été bien détaillée dans ce document, c’est une technique d’attaques applicatives
très efficace. Il suffit d’insérer du code soit dans le flux JavaScript coté client, soit dans le flux XML
inséré dans les objets DOM. Cette attaque est fondée sur une faille du serveur ou de l’application
Web. Il se peut aussi que l’attaquant utilise une application pour transmettre du code malveillant
généralement sous la forme d’un script à un autre utilisateur.
Cross site Request Forgery
Les attaques CRSF également appelées « Session Riding » reposent sur la simplicité du protocole Http
et dans sa facilité à rejouer des requêtes de type get et post. Elle part d’un serveur Web qui envoie
une requête vers un client victime, en se faisant passer pour un autre individu. Cette attaque est
considérée dangereuse parce qu’elle exploite le navigateur client qui est préalablement autorisé à
accéder aux sites et applications Web. L’attaquant récupère par la suite les droits dont bénéficie
l’utilisateur authentifié en conservant les cookies de session et les données identifiant le client
légitime présent sur le navigateur infecté. Il peut par la suite usurper l’identité de l’utilisateur
légitime afin de mener des attaques contre les sites concernés.
Les principaux mécanismes de sécurité sont inefficaces face à cette attaque. Cela est principalement
dû au partage de la mémoire, de la base des cookies et des fichiers temporaires par toutes les
navigations en cours.
Les navigateurs Web récents implémentent des mécanismes de sécurité évolués limitant le risque de
ce type d’attaque notamment la Same Origin Policy, un mécanisme déjà traité dans ce document, qui
sert comme moyen de prévention face au problème de contamination interzone.
Dans la pratique, il existe un outil CSRF proxy développé par HSC, un simulateur qui permet d’émuler
un serveur web générant des pages hostiles vers le navigateur d’un client. Ces pages sont capables
de se servir du navigateur client comme d’un relais pour attaquer un réseau interne d’entreprise.
47
Conclusion
Au cours de ce rapport, nous avons pu rencontrer de nombreuses méthodes permettant de
s’attaquer au navigateur Web. Ainsi, les failles proviennent bien souvent de ce que les navigateurs
combinent plusieurs technologies et font interagir des types de contenus différents n’ayant pas été
conçus pour une telle association. Les attaquants ne manquent donc pas d’imagination et les
vulnérabilités apparaissent de manière continue.
Face à la recrudescence de ces attaques, les éditeurs multiplient leurs efforts et ont pour la plupart
proposé dernièrement une nouvelle version de leur produit. Ces sorties sont le résultat d’initiatives
menées par les équipes de recherche et développement dont les objectifs en matière de sécurités
ont été boostés. La majorité des éditeurs ont donc apportés des changements significatifs sur leur
navigateur en modifiant leur modèle de gestion de la sécurité.
Parmi ces nouvelles versions, de nombreux concepts ont été repris par l’ensemble des navigateurs :
la Same Policy Origin, le concept de zones, les filtres anti phishing ou anti malware… Mais il faut aussi
saluer les avancées telles que la Sandbox de Google Chrome ou encore le concept de gestion
individuelle des onglets. Dans chacune de ces initiatives il y a de bonnes idées mais il serait
intéressant de toutes les combiner afin d’obtenir un navigateur plus sûr.
Le problème est que pour des soucis de budgets, les nouvelles versions repartent souvent de la
précédente. Mais partir d’un produit existant pour le sécuriser et le doter de nouveaux concepts est
rarement sans risque. Dans la conception il faudrait repartir de zéro et prendre en compte
l’ensemble des mécanismes actuellement performants, afin de mener un projet réfléchi et de ne pas
bricoler une solution apportant de nouvelles failles. Par exemple, les équipes de Chrome se sont
basées sur un cahier des charges intégrant les problématiques de sécurité. Ainsi les nouveaux
concepts tels la Sandbox ont été introduits dès l’origine dans le produit.
Suite à cette initiative de Google, Microsoft a pu apprécier la qualité de la Sandbox et l’isolement des
processus liés à chaque onglet. Les équipes de développement Microsoft ont alors défini le concept
d’une architecture positionnée entre le navigateur et le système d’exploitation : le projet Gazelle.
Cette nouvelle architecture augmente le niveau de sécurité et le contrôle de chacune des ressources
du navigateur. Ainsi, c’est le noyau au cœur de l’application qui est responsable de la gestion des
communications entre les différents composants du navigateur.
Les chercheurs ont pu évaluer leur projet de recherche sur de petits sites Internet et il s’avère que
même si les performances ne sont pas encore satisfaisantes, leur navigateur tiendrait ses promesses
pour un usage courant.
48
Bibliographie
Attaques
http://en.wikipedia.org/wiki/Browser_exploit
http://www.mozilla.org/projects/security/components/sectalk/slide3.xml
http://en.wikipedia.org/wiki/Cross_Zone_Scripting
http://en.wikipedia.org/wiki/Cross-site_scripting
Firefox
http://www.mozilla.org/docs/#security
http://www.mozilla.org/projects/security/components/
https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript
http://www.mozilla.org/projects/security/security-bugs-policy.html
http://www.mozilla.org/security/known-vulnerabilities/
Internet Explorer
http://www.microsoft.com/downloads/details.aspx?FamilyID=fc8025c9-22a0-44ae-9931-951b3bc05f6c&displaylang=fr
http://www.generation-nt.com/test-presentation-ie8-internet-explorer-8-navigateur-web-dossier-article-227821-4.html
http://www.techradar.com/news/internet/how-to-keep-your-surfing-habits-completely-secret-600118?artc_pg=2
http://www.generation-nt.com/s/ie8+internet+explorer+smartscreen+phishing+malware/?or
http://www.pcinpact.com/actu/news/44624-internet-explorer-microsoft-securite-ie8.htm
http://navsec.blogspot.com/2009/05/ie8-aussi-veut-que-vos-habitudes.html
Chrome
http://www.google.com/chrome/intl/fr/why.html
http://www.google.fr/chrome/intl/fr/features.html?hl=fr
http://www.google.com/googlebooks/chrome/small_00.html
http://aviv.raffon.net/2008/09/03/GoogleMule.aspx
http://www.certa.ssi.gouv.fr/site/CERTA-2009-AVI-231/CERTA-2009-AVI-231.html
http://blog.watchfire.com/wfblog/2009/04/google-chrome-universal-xss-vulnerability-.html
http://blog.watchfire.com/files/google-chrome-advisory.doc
SAFARI
http://www.apple.com/fr/safari/what-is.html
http://www.apple.com/fr/safari/features.html
http://www.certa.ssi.gouv.fr/site/CERTA-2009-AVI-223/CERTA-2009-AVI-223.html
OPERA
http://tempsreel.nouvelobs.com/actualites/medias/multimedia/20090616.OBS0743/opera_veut_revolutionner_le_web_a
vec_opera_unite.html
http://www.opera.com/browser/security/
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ALE-014/
Microsoft Gazelle
http://research.microsoft.com/pubs/79655/gazelle.pdf
49

Rapport Sécurité Navigateurs 2009

Transcription

Documents pareils

Comment extraire de la musique d`une video de you tube et la

Technologies du Web Correction de l`examen

Le cabinet SOULIER propose un espace intranet / extranet

FORMATION EN TRADUCTION À DISTANCE Programme de

Fiche-conseils sur la cybersécurité destinée aux consommateurs

Configuration requise pour un fonctionnement optimal

Webformation ECF Procédure Cookies Elève

Procédure d`installation et d`activation de licence : Télécharger la

ABCD Internet

Les navigateurs web