PDF document, 1.54 MB - Enisa

Document de synthèse
Sécurité et protection de la vie privée sur le Web 2.0
Décembre 08
À propos de l'ENISA
L‟Agence européenne chargée de la sécurité des réseaux et de l‟information
(ENISA) a été créée dans le but de promouvoir le fonctionnement du marché
intérieur. L‟ENISA constitue un pôle d‟excellence pour les États membres de
l‟Union et les institutions européennes dans le domaine de la sécurité des
réseaux et de l‟information, elle dispense conseils et recommandations et diffuse
des informations concernant les pratiques d'excellence. De plus, l‟agence facilite
les contacts entre les institutions européennes, les États membres et les acteurs
du secteur privé et de l‟industrie.
Avertissement juridique
La présente publication présente les avis et interprétations des auteurs et rédacteurs, sauf
indication contraire. Cette publication ne doit pas être interprétée comme une action de l‟ENISA ou
des organes de l‟ENISA, sauf dans ses aspects adoptés conformément au règlement (CE) 460/2004
relatif à l‟ENISA. Les informations qu‟elle contient n‟étant pas nécessairement les plus récentes,
elle peut faire l‟objet d‟actualisations. Les sources de tiers sont citées dans le respect des règles en
vigueur. L‟ENISA n‟assume aucune responsabilité quant au contenu des sources externes, y
compris les sites internet externes référencés dans la présente publication. Celle-ci poursuit des
objectifs exclusivement éducatifs et informatifs. Ni l‟ENISA ni aucune personne agissant en son
nom n‟est responsable de l‟utilisation qui pourrait être faite des informations contenues dans cette
publication. La reproduction est autorisée, moyennant mention de la source.
© Agence européenne chargée de la sécurité des réseaux et de l‟information (ENISA), 2008
Collaborateurs
Le présent document a été établi par un rédacteur de l'ENISA sur la base d'informations et
de commentaires d'un groupe de personnes sélectionnées pour leur expertise dans le
domaine, y compris des experts du secteur, du milieu universitaire et des gouvernements.
Le contenu a été collecté sur des sites Wiki ainsi que par voie de publipostage et de
conférences téléphoniques. Ce document ne doit pas être considéré comme représentant les
opinions d'une quelconque société ou organisation.
Liste des collaborateurs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Suresh N Chari, IBM, USA
Andy Cirillo, Depaul University, USA
Simon Grehan, National Centre for Technology in Education, Irlande
Michael Hart, Stony Brook University, USA
Rob Johnson, Stony Brook University, USA
Ajit Jaokar, Futuretext, R.-U.
Jesús Jiménez Cordente, ISDEFE, S.A, Espagne
Robert Pajak, Interia, Pologne
Corin Pitcher, Depaul University, USA
Robert Rachwald, Fortify Software, USA
Zulfikar Ramzan, Symantec
Thomas Roessler, W3C
Paul Thompson, Dartmouth University, R.-U.
Daniele Vitali, Reply, Italie
Andreas Wiegenstein, VirtualForge, Allemagne
Rédacteur: Giles Hogben, ENISA (Agence européenne chargée de la sécurité des réseaux et de l‟information)
Contacts
Pour toute requête à caractère général concernant le présent document de synthèse, veuillez utiliser les
adresses suivantes. Courriel: [email protected]. Internet: http://www.enisa.europa.eu/
Résumé
Le Web 2.0 – contenu généré par l‟utilisateur, interfaces utilisateur enrichies et services dynamiques et
coopératifs – a engendré une génération de nouveaux logiciels malveillants extrêmement virulents, baptisés
«Malware 2.0». La principale motivation de la présente étude consiste à établir le lien entre le Web 2.0 et
l'essor des contaminations par des programmes malveillants de type «drive-by», qui s'installent à l'insu de
l'utilisateur, sans que la moindre manipulation de sa part ne soit nécessaire. Pour donner une idée de la
menace que représentent ces logiciels, un rapport Scansafe analysant les tendances en matière de malware a
révélé que les risques posés par les sites compromis avaient augmenté de 407 % sur une période d‟un an
clôturée en mai 2008.
L'une des principales causes de la vulnérabilité du Web 2.0 réside dans l'inadéquation des structures d'accès
et d'autorisation mises en œuvre dans ce type d'environnement. Ce rapport met particulièrement en lumière
les problèmes des cadres politiques régissant la répartition des prérogatives entre applications web. Ces
cadres sont axés sur la politique «de la même origine», qui compartimente les applications web provenant de
domaines différents, et les cas où cette politique est soit délibérément relâchée, soit contournée à des fins
malveillantes. Les problèmes relatifs aux structures d'accès et d'autorisation résultent souvent de la difficulté
de trouver un équilibre entre le besoin de laisser suffisamment de liberté au fonctionnement des applications
Web 2.0 et l‟impératif de garantir un niveau de sécurité approprié.
Le Web 2.0 a aussi révolutionné la manière de gérer les connaissances et l'information. Une page
comporte du contenu, voire du code exécutable provenant de sources multiples, notamment des
utilisateurs, et l'information est susceptible d'être syndiquée (par exemple grâce aux fils de syndication
RSS) et modifiée à maintes reprises par rapport à sa forme initiale. En particulier:
•
Les possibilités accrues de fournir du contenu offrent autant d'occasions d'injecter du code malveillant,
source de nombreuses failles de type cross-site scripting, une faiblesse importante exploitée par les
programmes malveillants 2.0. Ce phénomène est exacerbé par la brièveté des cycles de développement et par
le manque, voire l'absence, de formation des programmeurs aux aspects de sécurité.
•
La fiabilité de l'information est dès lors plus difficile à établir, ce qui facilite la promotion d'informations
frauduleuses à des fins délictueuses (p. ex. distorsion des cours de Bourse à la faveur d'escroqueries de type
«pump and dump»).
Les failles énumérées dans le présent document sont extrêmement graves en raison des dommages
potentiels qu'elles occasionnent du fait de l'usurpation d'identité, de l'extorsion par des botnets (nous
décrivons une attaque orchestrée par des botnets (réseaux zombies) commandés par une application Web
2.0.), de la perte financière, de la violation de la vie privée et de l'atteinte à la réputation.
La technologie est capable de répondre à un grand nombre des problèmes les plus immédiats. Cependant,
l'élimination des risques plus systémiques requiert une approche globale de la sécurité, associant les
individus, les processus et la technologie. Parmi les éléments de cette approche, citons:
•
la politique publique, par exemple incitants en faveur du développement sécurisé tels que des plans
de certification légers et le financement de mesures pilotes;
•
la recherche, par exemple : convivialité de TLS/SSL, moyens respectant la vie privée pour instaurer la
confiance en l'information dans les environnements Web 2.0 et modèles de sécurité Javascript avancés;
•
les campagnes de sensibilisation, par exemple : durée de vie des données sur la Toile, recours à une
authentification renforcée dans certains scénarios Web 2.0 et inefficacité de la vérification de l'âge et des
plans de classification du contenu sur le Web 2.0;
•
la normalisation, par exemple : le développement accru de cadres d'autorisation et de contrôle d'accès
en vue d'améliorer la sécurité en cette matière, normes respectant la vie privée et permettant d'identifier la
provenance et le pedigree de l'information;
•
les mesures prises par les fournisseurs d‟accès, par exemple l‟amélioration des mesures
d'authentification et l‟utilisation du chiffrement;
•
les initiatives en matière de développement sécurisé – processus de développement sécurisés pour le
Web 2.0 et outils pour faciliter les processus comportant des fonctions de sécurité intégrées pour les IDE et
les API, la mise en œuvre d‟outils d‟identification puissants;
Synthèse des risques
Accès et autorisation
Répartition du contrôle entre applications - La politique de la même origine, c'est-à-dire
le compartimentage des applications provenant de noms de domaines différents, est la
principale méthode de contrôle d'accès entre applications web de fournisseurs différents. Par
nature, les applications Web 2.0 se jouent des frontières entre domaines. Le Web 2.0 a donc
élaboré de nombreuses techniques pour contourner cette politique, à des fins légitimes ou non (comme dans
le cas des attaques CSRF).
Privilèges excessifs - De nombreux services Web 2.0 invitent les utilisateurs à déléguer leurs coordonnées
d‟accès, par exemple des comptes de messagerie électronique ou des comptes bancaires. Généralement,
pour accéder à un service, les utilisateurs sont contraints d'abandonner le niveau de privilège le plus élevé,
par exemple celui octroyant un accès illimité et permanent à toutes les fonctionnalités de leur compte de
messagerie et non un accès limité dans le temps à leur carnet d'adresses. L'absence d'une granularité plus
fine des autorisations empêche d'utiliser pleinement de telles applications et expose ceux qui les emploient à
de sérieux risques.
Contrôle distribué - Les applications Web 2.0 telles que les applications web composites et les flux
peuvent être utilisées dans le cadre d'un système de contrôle distribué (p. ex. un robot exploitant les
billets de blogs).
Mode sandbox insuffisant - Les fonctionnalités du mode sandbox, en particulier celles offertes par la balise
HTML «Iframe», sont souvent insuffisantes et ouvrent la porte à la communication illicite interdomaine.
Authentification faible - L'authentification faible facilite le détournement des coordonnées de comptes sur le
Web 2.0.
Risques inhérents à la sécurité de l'information pour les mineurs - Les mineurs sont exposés à du
contenu inapproprié sur le Web 2.0. En cause: l'échec des techniques de vérification de l'âge ou des systèmes
de classification de contenu.
Problèmes inhérents à la convivialité de l'authentification serveur - Les utilisateurs ne tiennent pas
compte des messages d'erreur des certificats SSL entre le domaine serveur et le domaine certifié, laissant la
voie libre au hameçonnage et aux attaques de type «man-in-the-middle».
Problèmes inhérents au processus de développement - Les compétences des développeurs, la
complexité des interfaces API et la brièveté des cycles de développement au sein du Web 2.0 sont autant de
facteurs qui renforcent la vulnérabilité des applications du Web 2.0. Le cross-site scripting (XSS), l'une des
failles les plus connues, est imputable à la mauvaise validation des entrées utilisateur. C'est un bel exemple
de faille due à des processus de développement défaillants.
Spécification inadéquate des politiques Les garanties en matière de sécurité et de
respect de la vie privée sont mentionnées
avec précision, ce qui rend difficile de créer
des systèmes présentant un niveau de
garantie déterminé.
Exposition des méthodes lors des
migrations - Plusieurs kits de ressources
convertissent automatiquement les
applications serveur en applications Ajax
Web 2.0. Ceci peut avoir pour conséquence
l‟exposition de fonctionnalités restreintes
pendant l‟exposition.
Gestion des connaissances et de l'information
Provenance/pedigree frauduleux - La désinformation se propage facilement par
l‟entremise des flux RSS, des billets de blogs et des réseaux sociaux, qui offrent peu d‟indices de confiance
aux utilisateurs. Ce phénomène est lourd de conséquences, comme la manipulation des cours boursiers et la
commande de botnets via les flux RSS.
Vulnérabilités des systèmes de connaissances collaboratifs - Généralement, il est difficile, voire
impossible, d‟établir la fiabilité, l‟intégrité ou la provenance d‟affirmations formulées dans des systèmes
d‟écriture collaborative tels que les articles Wiki. Les conséquences peuvent être désastreuses. Ainsi, une
enquête a révélé que seulement 25 % des internautes à la recherche de conseils médicaux vérifiaient
couramment la source et la date de l‟information trouvée pour évaluer sa qualité.
Attaque de métadonnées - Les failles dans les métadonnées, telles que le format des métadonnées
médias ID3, sont le talon d‟Achille des applications Web 2.0.
Menaces vis-à-vis de la confidentialité spécifiques au Web 2.0 - L‟enquête de l‟ENISA (1) a révélé que
l‟usurpation ou l‟usage abusif de données à caractère personnel était la première inquiétude citée par les
utilisateurs finals du Web 2.0. En matière de confidentialité, les problèmes concernent le marquage
inconsidéré d‟images, le marketing comportemental et la divulgation de secrets professionnels.
Problèmes inhérents aux conditions de service - On attend souvent des fournisseurs d‟accès Web 2.0
qu‟ils interviennent en cas de contenu inapproprié créé par les utilisateurs. Ce faisant, ils renoncent
cependant aux protections juridiques dont jouissent les «simples transporteurs» (également connus comme
les exploitants de réseaux de communication), ce qui pose un dilemme cornélien à de nombreux
fournisseurs.
Faible usage du protocole TLS/SSL - De nombreux fournisseurs transfèrent des informations très
sensibles, y compris des mots de passe, sans les crypter ni authentifier le fournisseur de services.
Problèmes concernant l’utilisateur final
Problèmes liés aux connaissances du public - Parmi les problèmes rencontrés, citons la suppression de
données, la confiance aveugle dans des informations erronées ou non fondées, et la signification des
messages SSL/TLS dans les IU des navigateurs.
Manque de contexte de l’interface utilisateur - Les utilisateurs se fondent habituellement sur le nom
ou l‟URI (identifiant uniforme de ressource) du site internet pour lui faire confiance. Or, les applications Web
2.0 sont dépourvues de contexte comparable sur lequel fonder sa confiance.
Attaques automatisées - Une grave faille du Web 2.0 réside dans l‟incapacité à détecter si un système
est commandé par un être humain ou non, car de nombreuses interfaces sont accessibles au public, ce qui
ouvre la voie à la surexploitation de ressources limitées. Un point faible important réside dans les
techniques CAPTCHA.
Vulnérabilités générales des logiciels et des scripts
Failles des dispositifs basés sur le web - Les failles du Web 2.0 peuvent donner lieu à des attaques
perpétrées contre l‟infrastructure réseau, p. ex. le pharming à l‟aide d‟applications Web 2.0.
Failles du plug-in du navigateur - Ces modules en accroissement rapide forment souvent le maillon le
plus faible du modèle de sécurité des navigateurs.
Failles de JSON - On a identifié plusieurs failles importantes qui utilisent JSON, un format léger servant
au transfert des données Javascript couramment utilisées dans un contexte Web 2.0.
Synthèses de recommandations
Recommandations concernant les politiques publiques
•
Incitants politiques en faveur de pratiques de développement sécurisées telles que la
certification légère, les dispenses de déclaration et le financement de mesures pilotes. Ces
mesures sont nécessaires pour faire face aux nombreuses failles de type cross-site scripting,
dues principalement à une pratique de développement déficiente.
•
Aborder/analyser les craintes des fournisseurs Web 2.0 concernant les conflits entre l‟exigence d‟une
intervention dans le contenu et la volonté de conserver le statut de «simple transporteur» ou d‟«exploitant de
télécommunications» (USA). Les fournisseurs du Web 2.0 considèrent cet aspect comme un problème grave,
car le contenu généré par l‟utilisateur est une composante considérable.
•
Encourager le débat public et intergouvernemental sur la politique à mener vis-à-vis du marketing
comportemental (p. ex. Groupe de travail Article 29).
Pistes de recherche
Nous recommandons que des recherches sur les aspects suivants soient financées par l‟industrie et les
gouvernements:
•
convivialité des méthodes d‟authentification des fournisseurs (p. ex. TLS/SSL) et des méthodes de
cryptage des données Web 2.0;
•
convivialité améliorée des mécanismes renforcés d‟authentification de l‟utilisateur (p. ex. mots de
passe à usage unique);
•
pilotage et évaluation de l‟utilisation de mécanismes renforcés d‟authentification dans les scénarios
Web 2.0;
•
protection contre l‟abus des ressources limitées (p. ex. CAPTCHA);
•
infrastructure de confiance recourant aux réseaux sociaux (p. ex. confiance et réputation clés);
•
moyens respectueux de la vie privée permettant d‟établir la provenance de l‟information;
•
modèles de sécurité Javascript avancés;
•
modèles et contrats de licence pour les données à caractère personnel; et
•
critères de mesure et cadres de test (analyse de code, test d‟intrusion) pour la sécurité et la
confidentialité dans les applications Web 2.0.
Sensibilisation
Ce chapitre aborde les problématiques qui, selon nous, sont les plus importantes à évoquer dans les
campagnes de sensibilisation au Web 2.0. Par exemple la durée de vie des données sur la Toile, les
modalités et les motifs d‟utilisation des fonctionnalités de confidentialité dans les applications Web 2.0,
l‟interprétation des signes et erreurs TLS/SSL dans les navigateurs et (à l‟intention des développeurs) les
menaces pour la sécurité et les pratiques de développement sécurisées.
Recommandations concernant la normalisation
•
Développer et promouvoir davantage les spécifications émergentes (contrôle d‟accès W3C pour les
requêtes intersites, OASIS XACML, oAuth, HTML 5, OpenID, Cardspace et Liberty), pour constituer, en
particulier, un cadre d‟autorisation et d‟accès complet et normalisé pour les applications Web 2.0.
•
Déployer une interprétation cohérente des messages de sécurité dans les environnements de
navigation.
•
Élaborer des normes pour déterminer la provenance de l‟information, sans porter atteinte à la vie
privée.
Aspects propres aux fournisseurs
•
Standardiser le déploiement de mécanismes renforcés d‟authentification dans les environnements Web
2.0.
•
Utiliser des mesures d‟authentification adaptées aux données auxquelles on accède (p. ex. identifiant
et vérification de l‟état du compte à l‟aide d‟un mot de passe, mais, pour les opérations financières,
réauthentification à l‟aide d‟un jeton de mot de passe à usage unique).
•
Utiliser le cryptage TLS/SSL en cas de transfert de données sensibles.
Aspects propres aux développeurs/éditeurs de navigateurs
•
Initiatives de développement sécurisé: processus de développement sécurisé pour le Web 2.0,
formation et outils de promotion de ces processus et de la sécurité dès la conception, ainsi que fonctionnalités
de sécurité intégrées dans les IDE et les API.
•
Utilisation de techniques et de technologies existantes pour l‟authentification forte anonyme.
Sécurité et confidentialité du Web
2.0
Public
Ce document s‟adresse aux décideurs des entreprises et du monde politique, ainsi qu‟aux fournisseurs
d‟applications Web 2.0. Il vise à dresser une vue d‟ensemble des principaux risques et menaces pour la
sécurité des utilisateurs du Web 2.0., et, aspect plus important, il formule des recommandations quant aux
mesures à prendre et aux meilleures pratiques propres à atténuer ces risques. Il a aussi pour objet de
sensibiliser aux implications juridiques et sociales des nouvelles évolutions en matière de menaces articulées
sur le web.
Enquête auprès des utilisateurs finals
Parallèlement à cette étude, nous avons réalisé une enquête auprès de 1 500 utilisateurs finals des sites et
applications Web 2.0, cf. (1). Tout au long de ce document, nous évoquons certains de ces résultats, quand ils
viennent étayer notre propos. Cependant, nous conseillons au lecteur de prendre connaissance des résultats
de l‟enquête dans leur intégralité. Ceux-ci viendront compléter avantageusement les conclusions exposées ciaprès.
1 Délimitation du domaine étudié
A titre de base de travail et pour l‟analyse des menaces pour la sécurité, nous définissons le Web 2.0
comme englobant les caractéristiques suivantes:
•
applications articulées sur navigateur web enrichies comprenant des applications Flash et AJAX
(Asynchronous Javascript XML);
•
contenu web généré par l‟utilisateur: contenu qui est généré à l‟aide d‟une application articulée sur un
navigateur au lieu d‟être chargé directement sur un serveur web. Par rapport au contenu généré directement
par le fournisseur de services, ce type de contenu fait souvent l‟objet de régimes radicalement différents ou
moins bien définis en termes de sécurité et de réglementation. Diffusé en une multitude d‟exemplaires, le
contenu généré par l‟utilisateur est référencé et historicisé. En pratique, il est donc pratiquement impossible
de supprimer l‟information;
•
code côté client, widgets de communautés, code défini par l‟utilisateur, logiciels de communautés,
Ajax, IFrames, etc.;
•
services dynamiques coopératifs dont la fonctionnalité et le contenu sont issus de sources, juridictions
et entités juridiques différentes. Exemples: applications web composites, services web et flux RSS à
composition dynamique (OpenSocial, Google Mashups, etc.).
Remarque: dans ce document, nous mettons l‟accent sur les risques spécifiques au Web 2.0 plutôt que
sur les risques génériques pour la sécurité de l‟information (p. ex. usurpation d‟identité, pharming,
hameçonnage, courrier indésirable), sauf s‟il s‟agit d‟une variante propre au Web 2.0.
2 Introduction
Les applications Web 2.0 (Flickr, YouTube, Digg, BlogSpot, Facebook et Wikipedia) ont fait
l‟objet de beaucoup de battage médiatique et de controverses, mais peu de personnes
nieraient que l‟on assiste actuellement à l‟émergence d‟une nouvelle vague distincte et
inquiétante: «Malware 2.0». Comme le démontre ce document, les failles que recèlent les
applications Web 2.0, dont le cross-site scripting, ont largement contribué à l‟avènement du
Malware 2.0. Pour donner une idée de l‟ampleur des attaques de Malware 2.0, il convient de
se référer au rapport Scansafe Web STAT, qui analyse les tendances en matière de logiciels malveillants et
qui révèle que, de mai 2007 à mai 2008:
•
le volume des menaces auxquelles les internautes sont confrontés a augmenté de 220 %;
•
le risque d‟exposition à des attaques et des sites web compromis a augmenté de 407 %;
•
en mai 2008, 68 % de l‟exposition aux logiciels internet malveillants étaient imputables à des sites
compromis (2).
Sophos a cité Mal/Iframe (la transmission de logiciels malveillants au travers de failles d‟IFrame sur les
pages internet) parmi les cinq principaux vecteurs de malveillance (3). Les chercheurs de Google ont
récemment passé au crible le contenu de plusieurs milliards d‟URL stockées dans le cache du moteur de
recherche. Ils ont découvert qu‟environ 450 000 URL lançaient avec succès l‟installation automatique de
code malveillant par le téléchargement de type «drive-by download» (4).
La contamination par des logiciels malveillants est de plus en plus le fait de vecteurs automatiques (« driveby »). Il suffit que l‟utilisateur visite une page internet pour que son ordinateur soit contaminé. Les auteurs
des attaques intègrent de plus en plus leurs attaques depuis des pages web fiables, souvent en exploitant les
failles décrites dans le présent document. En mai 2008 par exemple, des cybercriminels ont réussi à intégrer
des scripts malveillants sur le site Nature.com, qui reçoit, selon les estimations, 877 000 visiteurs par mois.
L‟ampleur du marché noir des contaminations par «drive-by download» illustre sa capacité à infecter les
ordinateurs des utilisateurs par des programmes malveillants. Des entreprises proposent désormais des
forfaits pour un nombre déterminé d‟infections de pages web perpétrées à travers des failles Iframe (5).
En plus d‟offrir des opportunités d‟attaques malveillantes, le Web 2.0 a révolutionné les modalités de gestion
des connaissances et de l'information. Au chapitre [3], nous décrivons la nouvelle donne en termes de
modèles architecturaux. Le principal glissement paradigmatique s‟est traduit par l‟édition collaborative et la
syndication. Dans les scénarios Web 2.0, on constate fréquemment:
•
qu‟une page contient du contenu, voire du code exécutable, émanant de sources multiples;
•
que des particuliers sont susceptibles d‟être à l‟origine de l‟information et du code exécutable;
•
qu‟il est souvent possible de remonter jusqu‟à ces individus et de leur faire assumer la responsabilité
de leurs actes répréhensibles;
•
que la confiance en l‟information s‟instaure grâce aux votes des utilisateurs et aux systèmes de
réputation plutôt que sur la base des marques ou de la PKI;
•
que l‟information peut être syndiquée (par exemple flux RSS) et modifiée à de nombreuses reprises à
partir de son point d‟origine, ce qui complique la traçabilité de sa provenance et de son pedigree. Les
principales failles de sécurité résultant de ce glissement paradigmatique sont les suivantes:
•
Les utilisateurs peuvent intégrer du contenu, voire du code exécutable, dans les ressources internet.
Conjugué à la rapidité des cycles de développement et à la validation médiocre des saisies de l‟utilisateur qui
en résulte, ce phénomène est à l‟origine de nombreuses failles (en particulier dans le domaine du cross-site
scripting – XSS [5.4.3]).
•
Problèmes liés à la fragmentation du contrôle entre applications Web 2.0 de manière à garantir à la
fois une fonctionnalité et une sécurité adéquates. Traditionnellement, la politique de la «même origine» a
protégé les applications web en les empêchant d‟accéder à des sources non autorisées, mais des applications
multiples ou «widgets» exécutées dans un navigateur unique ont souvent besoin de communiquer à travers
les frontières des domaines et les développeurs sont donc contraints de contourner les restrictions d‟accès.
Par ailleurs, étant donné que cette politique comporte
1
Terme employé par Kaspersky labs sur http://www.viruslist.com/en/analysis?pubid=204791987
des lacunes multiples et qu‟il n‟existe bien souvent aucune autre base pour protéger
des ressources sensibles, les applications sont généralement dépourvues de moyens
de protection des ressources lorsqu‟elles en ont besoin.
•
Étant donné la difficulté de retrouver le «pedigree de l‟information», c‟est-à-dire le problème de la
fiabilité des sources, il est nettement plus facile de promouvoir l‟information frauduleuse à des fins
2
commerciales (p. ex. «astroturfing» ) ou délictueuses (p. ex. distorsion des cours de la Bourse dans le cadre
d‟attaques «pump and dump»).
•
En raison d‟une modification des modèles d‟entreprise, les recettes sont plus souvent issues du
marketing comportemental, basé sur des informations personnelles des particuliers participant à la création de
contenu.
•
Le traitement des données s‟effectue de manière croissante entre homologues plutôt que par C2B. Il
n‟est donc pas soumis aux dispositions régissant la protection des données et nettement plus difficile à réguler
de quelque manière que ce soit (du moins en Europe).
•
Les métadonnées, qui permettent le traitement du contenu, jouent un rôle nettement plus important,
les attaques orchestrées sur les systèmes de métadonnées ont dès lors davantage d‟impact lorsqu‟elles
contaminent les sources d‟information et intègrent des programmes malveillants dans une syntaxe mal
formée.
•
Les mécanismes de syndication peuvent être utilisés comme moyen de contrôle couplé et distribué de
manière extrêmement flottante à des fins délictueuses.
Ces nouvelles failles sont très importantes, non seulement en raison de leur prévalence grandissante, mais
aussi en raison des dégâts potentiels qu‟elles peuvent occasionner et de l‟incapacité à remonter jusqu‟à leurs
auteurs. Parmi les répercussions les plus notables, citons l‟installation d‟espiogiciels affectés à l‟usurpation
d‟identité, l‟utilisation de programmes malveillants à des fins d‟extorsion par l‟entremise de réseaux zombies
(Nous décrivons une attaque Web 2.0 où des botnets sont installés et pilotés par des applications Web 2.0
[5.5.1.2].), les pertes financières, la violation de la vie privée et l‟atteinte à la réputation.
Pour atténuer ces risques, nous recommandons des initiatives dans le domaine de la technologie, de la
recherche, du développement et de la standardisation, mais nous soulignons également que la
responsabilité d‟un grand nombre de failles n‟est pas imputable à une seule technologie ou à un seul
groupe de personnes. Le problème requiert une approche globale, impliquant à la fois les individus, les
processus et la technologie. Parmi les éléments d‟une telle approche, soulignons:
•
la politique publique, p. ex. des incitants en faveur du développement sécurisé tels que des
procédures de certification légère et le financement de mesures pilotes;
•
les initiatives de recherche comme la convivialité de TLS/SSL, des moyens respectant la vie privée
pour instaurer la confiance envers l'information dans les environnements Web 2.0 et des modèles de sécurité
Javascript avancés;
•
les campagnes de sensibilisation concernant par exemple la durée de vie des données sur la Toile, les
atouts d‟une authentification renforcée dans certains scénarios Web 2.0 et le piètre taux de réussite de la
vérification de l'âge et des plans de classification du contenu dans les environnements Web 2.0;
•
initiatives de standardisation: par exemple le développement accru de cadres d'autorisation et de
contrôle d'accès en vue d'améliorer la sécurité en cette matière, nous recommandons aussi l‟élaboration de
normes permettant d'identifier la provenance de l'information dans le respect de la vie privée;
•
les mesures prises par les fournisseurs, comme l‟amélioration des mesures d'authentification et
l‟usage du cryptage; et
•
les initiatives en matière de développement sécurisé - processus de développement sécurisé pour le
Web 2.0 et outils auxiliaires pour faciliter de tels processus, y compris des fonctionnalités de sécurité
intégrées pour environnements de développement intégré (IDE) et interfaces de programmation (API). Nous
recommandons également une mise en œuvre élargie des outils d‟authentification anonymes.
2
http://en.wikipedia.org/wiki/Astroturfing
3 Modèles architecturaux Web 2.0
Le Web 2.0 se distingue par un ensemble de nouveaux schémas architecturaux qui soustendent son fonctionnement. Il est utile, en analysant les implications en termes de sécurité,
de passer en revue ces schémas, quand on sait que bon nombre des risques sont introduits
par des modifications de l‟architecture de la Toile.
3.1.1 Syndication de l’information
Par le biais de mécanismes de syndication tels que les flux RSS, l‟information transite par des hôtes, éditeurs
et formats avant de parvenir chez l‟utilisateur final. Comme nous le montrerons ci-après, ceci rend la fiabilité
de l‟information plus difficile à établir et facilite l‟introduction d‟informations frauduleuses dans un système.
3.1.2 Écriture collaborative
L‟information, qui a les apparences d‟une source unique ou d‟un article, est modifiée
par une foule d‟utilisateurs (éventuellement anonymes et impossibles à identifier). L‟exemple le plus
connu est Wikipedia.
3.1.3 Widgets intégrés
Une page web unique comporte des applications Javascript ou Ajax de multiples origines. Pour s‟exécuter,
chacune d‟elles peut avoir besoin de communiquer avec plusieurs serveurs ou d‟autres widgets présents sur la
page. Des exemples de ces widgets sont présents dans les réseaux sociaux tels que Facebook et MySpace. La
publicité en ligne en est un autre exemple, étant donné que les messages publicitaires sont généralement
fournis par une tierce partie, mais doivent tenir compte d‟autres informations contenues sur la page pour
personnaliser les annonces. Souvent, les widgets sont développés avec une durée de vie limitée (p. ex. les
annonces Flash complexes).
3.1.5. Délégation de droits d’autorisation
Les applications web 2.0 qui agrègent d‟autres services nécessitent
souvent une autorisation pour accéder à des informations sensibles.
Un exemple classique est la délégation de l‟autorisation à accéder à
un carnet d‟adresses de courrier électronique pour une application de réseau
social. Un autre exemple est un service qui agrège différents services bancaires
sur internet sur une seule page.
4 Scénarios applicatifs typiques du Web 2.0 et leurs
caractéristiques en matière de sécurité
4.1.1 Applications web composites (mashups)
Les mashups, ou applications web composites, composent de nouveaux services internet en associant les
données et les composants d‟applications web existantes. Lorsque les services sous-jacents requièrent une
authentification de l‟utilisateur, l‟utilisateur de mashup doit lui accorder l‟accès à son (ses) compte(s) sousjacent(s). Considérons par exemple un mashup qui lit l‟information figurant dans l‟en-tête de tous les courriers
indésirables envoyés à un compte d‟utilisateur de messagerie web de Yahoo et qui cartographie l‟origine
géographique de chaque message à l‟aide de Google maps. Pour utiliser ce système, l‟utilisateur doit
communiquer son mot de passe de messagerie Yahoo au système de mashup (et espérer que le logiciel en
question se comporte comme escompté).
Chicagocrime.org (6) est un exemple de mashup de la première heure bien connu. Il permet à l‟internaute
d‟effectuer des recherches dans la base de données des actes criminels signalés à Chicago, de visualiser le
lieu où ils ont été commis, de filtrer les résultats par site, type de délit, quartier et date, et d‟afficher les
coordonnées du délit sur la carte. Ce moteur de recherche est surtout utilisé par les personnes désireuses
d‟acquérir un bien dans une zone donnée.
Relevons que les réseaux de publicité en ligne peuvent aussi été qualifiés de mashups, dans la mesure où
ils intègrent des données issues de nombreuses sources et fournissent un service exploitant ces
informations sur une page unique.
4.1.2 Politique de la même origine – Exemple de scénario
La politique de la même origine est une caractéristique prédominante de la plupart des scénarios Web 2.0.
C‟est la pierre angulaire de la sécurité des navigateurs. Elle évite qu‟un document ou script chargé depuis une
origine donnée ne manipule les propriétés d‟un document issu d‟un autre site d‟origine ou ne communique
avec ce dernier. Dans ce cas, le terme origine se définit par rapport au nom de domaine complet, au port et
au protocole du site hébergeant le document. Le tableau ci-dessous illustre la procédure que suivrait la
politique de la même origine pour traiter une manipulation de document par un script issu de
http://www.example1.com/exampledirectory1/page.html.
URL cible
Résultat
Motif Protocole différent Port
http://www.example1.com/exampledirectory2/
page.html
http://www.example1.com/exampledirectory1/
exampledirectory2/page.html
https://www.example1.com/exampledirectory1
/page.html
http://www.example1.com:81/exampledirector
y1/page.html
http://host2.example1.com/exampledirectory1/
page.html
Succès
Succès
Échec
Échec
Échec
différent Hôte différent
La politique de la même origine est une des seules fonctionnalités d‟un navigateur
assurant une séparation du contrôle entre différents propriétaires d‟applications; en
d‟autres termes, une application ne peut pas prendre le contrôle d‟une autre à des
fins malveillantes. Examinons à présent un exemple classique de problème susceptible de survenir en
l‟absence de cette politique ; prenons un système de navigation par onglets: l‟utilisateur a ouvert une
application de banque par internet dans un onglet, et une page prise en charge par un pirate informatique,
dans un autre. Si la page malveillante était capable de contrôler le contenu et les opérations effectuées sur la
page de la banque par internet, elle pourrait réaliser un transfert de fonds vers un compte bancaire arbitraire
(même en cas d‟utilisation de mots de passe uniques) par la simple substitution d‟un numéro de compte
bancaire dans une requête POST.
Par ailleurs, il existe des situations importantes dans lesquelles la politique de la même origine doit être
assouplie pour permettre le fonctionnement des applications web. Les requêtes POST sont un exemple
important des cas dans lesquels un assouplissement de la politique de la même origine est nécessaire. Pour
offrir suffisamment de souplesse aux applications qui traitent des données au format HTML, les navigateurs
ne comportent pas de contrôles intégrés interdisant l‟envoi de requêtes POST interdomaines. En revanche,
cette option conceptuelle importante a donné lieu à des failles, exploitées par les attaques CSRF
[5.3.1.1.1.1].
4.1.3 Principes de confidentialité sur les réseaux sociaux
Les utilisateurs doivent souvent définir des préférences, comme les personnes habilitées à marquer des
photos avec leur profil, les amis autorisés ou non à accéder aux informations du profil (options désormais
offertes par Facebook, par exemple). Les utilisateurs doivent être capables d‟exporter leurs profils ET leurs
préférences en matière de confidentialité. Ceci nécessite de disposer de données de profil et de politiques de
contrôle d‟accès portables, pouvant voyager avec elles. Le scénario suivant est caractéristique :
•
John crée un profil sur un réseau social (RS) chez le fournisseur n°1. Il saisit son nom, sa date de
naissance, ses hobbies, son lieu de travail, etc.
•
Il verrouille son profil pour en interdire l‟accès public.
•
John définit des préférences plus précises en matière d‟affichage: seuls ses amis pourront visualiser
ses données de téléphone mobile, mais pas son ex-femme. Puis, SOIT
•
John souhaite rejoindre un autre fournisseur de réseau social ; il crée alors pour ce faire un compte
chez le fournisseur n°2.
•
John exporte son profil RS du fournisseur n°1 vers le fournisseur n°2.
•
John exporte ses préférences en matière de confidentialité définies sur son profil RS du fournisseur
n°1 vers le fournisseur n° 2 OU une application logicielle de réseau social sur un autre compte que John a déjà
configuré pour utiliser les données de son profil,
•
un service web indépendant de Facebook (exploitant par exemple OpenSocial) veut organiser une fête
en envoyant un message texte aux amis d‟Albert.
•
Il contacte Facebook et demande à connaître les amis de son réseau et leurs numéros de téléphone
respectifs.
•
Ceux-ci sont communiqués dans le
respect des préférences définies par les
personnes auxquelles les données se
rapportent.
•
L‟application envoie les invitations.
4.1.4 Gestion des finances personnelles en ligne
L‟agrégation de comptes permet à un utilisateur final de visualiser les détails des
transactions et des soldes de différents comptes. Les données peuvent être saisies par
l‟utilisateur, téléchargées depuis l‟établissement assurant la gestion du compte ou auprès
d‟un intermédiaire. Mint – internet banking aggregation (7) est un fournisseur de services
en ligne d‟agrégation de comptes (aux USA), un équivalent en ligne du logiciel de
comptabilité de bureau. Ce type d‟application est important du point de vue de la sécurité,
car elle suppose la délégation de droits d‟autorisation pour accéder à des données
financières très sensibles.
4.1.5 Logiciels d’entreprise et applications bureautiques basées sur
navigateur
Il est désormais possible d‟obtenir des « applications de bureau dans un navigateur » offrant la totalité de la
suite standard d‟applications d‟entreprise à travers la navigation sur internet. Google Apps (8) en est un bon
exemple. Il propose un tableur et un traitement de texte pour créer des documents institutionnels dans le
navigateur, une messagerie électronique hébergée, une messagerie instantanée pilotée à travers le
navigateur et un calendrier. Les entreprises commencent aussi à externaliser des fonctionnalités centrales
vers des services web, comme le suivi des leads, des contacts, des commandes, etc. y compris la gestion des
salaires. À l‟avenir, une société pourra potentiellement sous-traiter tous ses services informatiques, à
l‟exception de son infrastructure réseau et de sa maintenance matérielle. Une caractéristique importante est
que la suite applicative arbore l‟image de marque de l‟entreprise, tandis que les données sont généralement
hébergées dans un dépôt centralisé fourni par le fournisseur d‟accès. Généralement, l‟entreprise n‟a pas
contractuellement le droit de vérifier les mesures de sécurité.
4.1.6 Écriture collaborative – sites Wiki
Les sites Wiki sont des bases de connaissances collaboratives qui compilent des contenus fournis par des
internautes anonymes et des rédacteurs enregistrés. En général, il convient de souligner que les sites Wiki
appliquent les principes éthiques du code source libre (open source) préconisé par l‟Union européenne, en
fournissant un accès aisé aux contributeurs et aux consommateurs de connaissances. Ils encouragent le
partage d‟information où que l‟on se trouve et indépendamment du milieu socioéconomique.
Au-delà des aspects de qualité de service globale requis de tous les sites internet, les sites Wiki présentent de
nouvelles contraintes en matière de sécurité et d‟intégrité. Leur intégrité sémantique est cruciale pour leur
réussite et doit être prise en compte pour autoriser l‟accès aux collaborateurs. Wikipedia par exemple vise à
être une encyclopédie libre que (presque) tout le monde peut modifier. Outre la prouesse de fournir des
millions d‟articles, ceux-ci doivent se conformer à des normes garantes de leur objectivité, de leur authenticité
et de leur pertinence. Cela doit empêcher des utilisateurs de créer des articles fallacieux, en ajoutant du texte
non pertinent ou en exprimant leurs opinions personnelles, ce qui est contraire aux conditions de service.
On distingue trois grandes approches:
•
droits de modification illimités: si la plupart des visiteurs sont animés de bonnes intentions, certains
ne le sont pas et cette politique peut favoriser un vandalisme endémique;
•
procédures de modification restrictives et bureaucratiques: chaque fois qu‟une modification est
apportée, elle est examinée et discutée sous tous ses aspects, et ce dans le cadre d‟un processus
hiérarchique. Cette approche est fastidieuse et a motivé la défection de rédacteurs très actifs;
•
agents autonomes: les scripts peuvent annuler des modifications ou envoyer des notifications aux
rédacteurs humains quand des modifications ont été apportées. Bien qu‟ils soient abondamment mis en
œuvre, ces agents effectuent en général des opérations qui se limitent à la mise en concordance des
expressions régulières.
4.1.7 Blogs et microblogs
Les blogs, c'est-à-dire la publication régulière de contenu généré par l‟utilisateur,
généralement géré par un individu et comportant des commentaires, la description d‟événements ou d‟autre
matériel tel que des images ou des vidéos sont déjà bien connus et requièrent peu d‟explications. Le
microblogage est cultivé sur des sites tels que Twitter, Jaiku, Twitxr et Pownce, variantes du réseau social qui
publie des messages courts, où les internautes relatent leur quotidien ou publient des photos de l‟endroit ou
de la situation où ils se trouvent. La popularité de ces applications va grandissant, tout comme la possibilité
de poster ces messages depuis n‟importe quel système (navigateur, téléphone mobile, MI, etc.).
Les contenus des microblogs tendent à comporter des publications et des images prises en public, souvent
à l‟insu de tiers (non consentants). Le recours à des appareils mobiles est en outre de nature à augmenter
la quantité de données de localisation disponibles. La protection et l‟utilisation adéquate des informations
personnelles, temporelles et géographiques constituent dès lors un problème de sécurité important.
4.1.8 Métadonnées – Marquage et folksonomies
Marquage d’image - Le marquage est une fonctionnalité très prisée sur les réseaux sociaux et les sites de
partage de photos, les utilisateurs ont la possibilité de marquer les images avec des noms ou des liens vers
des pages de profil sur les réseaux communautaires. Ils peuvent marquer des images eux-mêmes et, aspect
plus crucial, également d‟autrui. Les contrats de licence utilisateur et les conditions d‟utilisation précisent que
le marquage est « opt out », c'est-à-dire que si une personne refuse d‟être marquée, elle doit faire une
demande expresse au marqueur (qu‟elle peut ne pas connaître). Généralement, un utilisateur charge une
image et la marque avec des métadonnées incluant les noms, les liens vers la page de profil voire l‟adresse de
courrier électronique des personnes qui y figurent.
Dans ce domaine, l‟intégration de logiciels de reconnaissance faciale dans les outils de téléchargement
d‟images constitue une évolution majeure. Ces programmes utilisent la reconnaissance faciale et
l‟apprentissage automatique pour marquer les photos automatiquement, après une période de « formation »
pendant laquelle l‟utilisateur «apprend» au logiciel à identifier les visages qui reviennent le plus souvent dans
la photothèque (9). Comme cela est expliqué en détail dans Security Issues and Recommendations for Online
Social Networks (10), les implications pour le respect de la vie privée sont importantes. Le déploiement à
grande échelle d‟une fonctionnalité de ce type va entraîner une augmentation substantielle de la quantité de
de marquages appliqués à des images.
Flux RSS - Ces fichiers fournissent des métadonnées sur le contenu web récemment mis à jour, ce qui
permet donc aux utilisateurs d‟agréger des sources multiples dans un seul lecteur, qui affiche
instantanément des synthèses de nouveau contenu sans que l‟utilisateur ait à vérifier les mises à jour.
Métadonnées médias (fichiers ID3) - Les métadonnées médias fournissent des informations sur les
médias intégrés dans les applications Web 2.0.
Folksonomies et nuages de mots-clés - Les utilisateurs créent des ensembles de métadonnées
communautaires auxquels les membres de la communauté peuvent contribuer. Les nuages de mots-clés
représentent visuellement les relations entre les catégories de contenu dont relève un élément de
contenu.
4.1.9 Tâches distribuées non automatisables
L‟un des usages des nouveaux paradigmes architecturaux consiste à exploiter la puissance de nombreux
utilisateurs distribués pour réaliser des tâches qui ne peuvent être aisément automatisées. Cet usage peut
servir des fins professionnelles légitimes. Mechanical Turk (11) en est un bon exemple. Ces processus
peuvent être aussi détournés à des fins délictueuses, comme pour déjouer des CAPTCHA en ayant recours à
une base d‟utilisateurs distribuée, soit en leur payant une somme modique pour chaque CAPTCHA déjoué,
soit en les incitant à saisir le texte du CAPTCHA (12) (13).
5 Risques principaux
Ce chapitre décrit les principaux risques du Web 2.0 pour la confidentialité et la sécurité.
Nous mettons l‟accent sur les risques spécifiques au Web 2.0 plutôt que sur les risques
génériques pour la sécurité de l‟information (p. ex. usurpation d‟identité, pharming), sauf s‟il
existe une variante propre au Web 2.0. (p. ex. failles dans le contrôle d‟accès) ou si le risque
est accru ou modifié par certaines fonctionnalités du Web 2.0 (p. ex. attaques
automatisées). Nous avons suivi une méthodologie classique d‟évaluation du risque.
L‟analyse des risques se subdivise en actifs (objet de la protection), menaces (répercussion négative
potentielle) et failles (lacunes techniques ou systémiques qui engendrent le risque).
5.1 Actifs
Les actifs à risque dans les scénarios Web 2.0 se répartissent en un petit nombre de catégories simples.
•
Informations privées – peuvent être usurpées et utilisées à des fins de harcèlement, d‟envoi de
courrier indésirable ou de diffamation d‟une personne.
•
Actifs financiers – peuvent être détournés via la banque par internet ou les portails de commerce
électronique.
•
Réputation d‟une entreprise ou d‟un individu – peut être compromise.
•
Secrets professionnels – peuvent être dérobés, ce qui entraîne des pertes financières et des
dommages pour la marque.
•
Propriété intellectuelle – peut être volée.
•
Ressources informatiques et réseau – peuvent être consommées, ce qui entraîne un déni de service.
•
Sécurité physique – peut être compromise, p. ex. si un attaquant peut découvrir les coordonnées
physiques d‟une personne.
5.2 Menaces
Les menaces sont des dommages potentiels que peuvent subir les actifs en raison des failles énumérées cidessous. Étant donné qu‟elles ne sont généralement pas spécifiques au Web 2.0, nous ne les abordons que
brièvement pour illustrer les conséquences que peuvent avoir les failles si l‟on n‟y remédie pas. Les menaces
et conséquences typiques sont les suivantes:
•
installation de réseaux zombies pratiquant l‟extorsion en exploitant les privilèges d‟une autre
application;
•
pertes financières dues au «drive-by pharming», à l‟installation de programmes malveillants,
d‟espiogiciels, ou à d‟autres failles;
•
déni ou atteinte à la réputation ou création d‟identités alternatives en vue d‟influencer la réputation,
comme les célèbres attaques perpétrées à l‟encontre du système de réputation d‟eBay à l‟aide d‟un robot en
vue de créer des milliers de faux comptes (14) ou d‟un site de critiques cinématographiques, à l‟aide de faux
comptes visant à altérer la popularité d‟un film qui va sortir;
•
harcèlement à l‟aide de comptes faiblement authentifiés, p. ex. Twitter refuse de respecter les
conditions de service (15);
•
menaces inhérentes à la vérification de l‟âge de l‟internaute, p. ex. intimidation ou harcèlement sexuel
d‟enfants après avoir obtenu leurs coordonnées;
•
courrier indésirable émanant de sites de réseaux sociaux ou commentaire non sollicité sur des blogs;
•
dissimulation de l‟origine d‟une attaque plus grave en utilisant une victime innocente;
•
occupation des ressources de l‟utilisateur ou de l‟entreprise, p. ex. données de stockage dans le
compte de l‟utilisateur, déni de service, etc.;
•
propagation d‟informations fallacieuses et trompeuses, conduisant notamment à une fraude boursière
ou à une erreur de diagnostic médical; et
•
dans les scénarios bancaires, les données inexactes peuvent donner lieu à l‟application d‟intérêts de
retard à des utilisateurs (qui ne se rendent même pas compte qu‟ils ont été débités).
5.3 Failles
5.3.1 Accès, authentification, autorisation
Cette catégorie de risques concerne les failles qui permettent un accès non autorisé aux applications et
aux données.
5.3.1.1 Problématique de la politique de la même origine
La politique de la même origine est l‟une des pierres angulaires de la cybersécurité. En résumé, elle empêche
qu‟un document ou script téléchargé à partir d‟un point d‟origine ne manipule les propriétés d‟un document
téléchargé depuis un autre site d‟origine doté d‟un nom de domaine, d‟un port et d‟un protocole ou ne
communique avec ce dernier (cf. [4.1.2] pour de plus amples informations). Sur le Web 2.0 toutefois, l‟usage
courant de widgets intégrés émanant de tiers (cf. [3.1.3]) et «l‟hybridation» de sources de données disparates
font qu‟une application web unique, exécutée dans un navigateur par exemple, doit souvent coordonner des
opérations entre des codes exécutables fournis par des domaines multiples. Inversement, le code exécutable
fourni par un domaine unique est souvent contrôlé par de multiples parties qui ne se connaissent pas et ne
bénéficient d‟aucune confiance. En conséquence, dans de nombreuses applications Web 2.0, la politique de la
même origine est considérée comme un obstacle à contourner.
Les développeurs de navigateurs ont souvent dû prendre une décision conceptuelle délibérée, à savoir
relâcher la politique de la même origine dans certaines situations, afin de répondre à la nécessité fréquente
de la communication interdomaine dans les applications web (même avant l‟avènement du Web 2.0, cf.
requêtes POST décrites au point [4.1.2]).
En conséquence, il existe de nombreuses techniques permettant de court-circuiter la politique de la même
origine ou d‟exploiter son relâchement délibéré, à des fins tant légitimes (par exemple en utilisant des proxy
Ajax, Flash, JSON, balises de script, etc.) que délictueuses. Pour http://a.com/sample.html, un canevas de
programmation courant est d‟avoir du code qui ajoute DOM (Document Object Model), une balise de script
comme celle-ci:
<script src="http://b.com/data.js?callback=cb&amp;param=foo"></script>
Un script est chargé depuis b.com et exécuté sur a.com. Il est ensuite escompté qu‟il appelle la fonction cb
et transmette les données récupérées à cette fonction. Il est frappant de constater que le contrôle
d‟exécution passe au fournisseur de données (b.com) pour qu‟il exerce un contrôle complet sur
l‟application web qui s‟exécute sur a.com/sample.html (16).
La présence de telles lacunes a pour corollaire que même si le comportement souhaité est de respecter la
politique de la même origine, on ne peut pas s‟y fier pour prémunir une application contre un accès non
autorisé. Actuellement, des travaux sont encore en cours en vue d‟élaborer un cadre de stratégie technique
cohérent afin de préciser les conditions dans lesquelles il est permis de relâcher la politique de la même
origine et de garantir une mise en œuvre cohérente et sécurisée de cette stratégie.
5.3.1.1.1.1 Exemple de violation de la même origine: CSRF (Cross-site Request Forgery)
Le CSRF (également appelé sea-surfing) est un type de faille courant, qui exploite les faiblesses dans le
traitement des requêtes HTTP (habituellement POST) émanant d‟autres domaines. Une attaque CSRF oblige le
navigateur connecté d‟une victime à envoyer une requête pré-authentifiée à une application web vulnérable,
qui, à son tour, contraint le navigateur de la victime à exécuter un acte hostile pour le compte de l‟attaquant.
Le CSRF peut être aussi puissant que l‟application web à laquelle il s‟attaque et il ne s‟agit généralement pas
d‟une attaque pouvant être détectée par le client demandeur, étant donné qu‟elle exploite une fonctionnalité
légitime et nécessaire de l‟application client (p. ex. envoi d‟une requête POST par une application de tiers). Un
exemple spécifique de ce procédé est l‟attaque contre Gmail (un correctif a depuis été fourni) (17). Lors de
cette attaque, la victime visite une page sous un onglet de son navigateur tout en étant connectée à Gmail
sous un autre onglet. Au moment de l‟exécution, la page effectue une requête HTTP POST à une des
interfaces de Gmail et injecte un filtre de messagerie dans la liste de filtres de la victime. Ce filtre recherche
simplement les courriels avec pièces jointes et les transfère à une adresse e-mail choisie par l‟attaquant. Ce
filtre transférera automatiquement tous les courriels, existants et futurs, répondant aux critères de la règle.
Remarque: il s‟agit d‟un exemple d‟une catégorie plus générale de problèmes de type
«confused deputy» (18).
5.3.1.1.1.2 Exemple de violation de la même origine – stratégies Flash Cross Domain
Le module Flash d‟Adobe permet expressément aux développeurs d‟assouplir le déploiement
de la politique de la même origine à l‟aide d‟un fichier de régulation. En soi, il ne s‟agit PAS
véritablement d‟une faille, dès lors qu‟on est en présence d‟un effort délibéré de fournir un
cadre de stratégie clairement balisé, définissant les cas où la politique de la même origine
peut être relâchée. Le fichier de régulation s‟installe côté serveur en plaçant un fichier texte
unique nommé crossdomain.xml dans le répertoire racine du domaine hébergeant les
services web auxquels les animations Flash sont susceptibles d‟avoir accès. Le fichier contient des règles
mentionnant les domaines ou les adresses IP qui peuvent émettre des requêtes via ce serveur. (N.B. il ne
couvre pas l‟accès, par les fichiers Flash, au DOM de la page où l‟animation Flash est intégrée). Dans cet
exemple, la faille réside dans le fait que ces règles permettent aussi l‟usage de caractères génériques (*), une
technique qui autorise l‟exécution de n’importe quelle requête interdomaine vis-à-vis de contenu fourni par ce
serveur. Les serveurs web qui publient des fichiers crossdomain.xml contenant des caractères génériques sont
vulnérables aux attaques, comme on peut le lire dans The Dangers of Cross-Domain Ajax with Flash (19).
L‟approche de développement commune de « comment le faire fonctionner ? » a pour corollaire que les
fichiers de régulation à caractère générique sont très courants. Aspect plus important encore, dans un
contexte d‟accès interdomaine illimité (c'est-à-dire quand crossdomain.xml comporte un caractère générique),
la politique de la même origine du navigateur peut être contournée en téléchargeant un petit fichier SWF
(Flash) en tant que proxy XmlHttpRequest.
5.3.1.1.1.3 Réseaux de publicité en ligne
Il est aussi fréquent que les réseaux de publicité en ligne déploient diverses techniques pour contourner la
politique de la même origine. Ces techniques sont les suivantes:
En-tête référant HTTP - Ces en-têtes, accessibles à n‟importe quelle ressource intégrée, révèlent l‟URL
complète de la page dans laquelle la publicité est intégrée, ce qui permet aux annonceurs de pister les
internautes voire d‟extraire des informations à caractère personnel à partir de variables URL (technique du
mouchard - web bugging).
Interception chez le fournisseur d’accès - Des services émergents tels que Phorm (20)
interceptent et ajoutent des publicités en fonction du contenu.
Utilisation de plug-ins de navigateur - Certains plug-ins ne sont pas aussi stricts que le navigateur
maître quand il s‟agit d‟appliquer la politique de la même origine. Ainsi, Adobe Flash autorise les fichiers de
régulation interdomaine qui permettent aux annonceurs de contourner cette politique.
5.3.1.2 Privilèges excessifs
De nombreux services Web 2.0 invitent les utilisateurs à leur déléguer l‟utilisation des coordonnées d‟accès,
par exemple des comptes de messagerie électronique, des comptes bancaires, etc. Ces services sont si
souvent coercitifs que certains internautes sont enclins à abandonner toute prudence pour en bénéficier, bien
que la majorité soit réticente à le faire par crainte pour la sécurité. Une enquête de l‟ENISA a révélé que plus
de 70 % des utilisateurs finals n‟étaient pas disposés à recourir à de tels mécanismes de délégation et que la
majorité ne ferait pas appel à un service de gestion financière en ligne (qui consolide plusieurs comptes) pour
des motifs apparentés (1). C‟est un choix très rationnel, car ces services n‟offrent aux utilisateurs qu‟un seul
niveau de privilège. Dès lors, pour toute délégation, les utilisateurs doivent abandonner le niveau de privilège
le plus élevé (p ex. accès illimité et permanent à toutes les fonctionnalités de leur compte de messagerie
électronique plutôt qu‟un accès limité dans le temps à leur répertoire). En outre, ce mécanisme peut avoir des
effets en cascade surprenants; un utilisateur final qui fournit ses informations de compte Google à un service
d‟agrégation de courrier électronique pourrait aussi autoriser l‟accès à d‟autres informations, telles que ses
documents Google. Pour la majorité des utilisateurs, ces implications sont cependant difficiles à prévoir.
L‟emploi de coordonnées uniques liables conduit aussi à une perte des informations par leur pistage en tant
qu‟identifiant unique. Cela multiplie aussi la vulnérabilité de tous les services auxquels les coordonnées
donnent accès. Par exemple, les agrégateurs de réseaux sociaux réduisent la sécurité de ces sites, car un
mot de passe unique donne accès à de multiples banques de données personnelles. La sécurité est assurée
conformément au niveau de service le plus faible.
L‟incapacité à fournir une autorisation et un contrôle d‟accès limités à fine granularité
aux applications Web 2.0 constitue donc une faille très grave.
Parmi les autres problèmes notables liés à la séparation du contrôle, citons la possibilité d‟utiliser les
applications Web 2.0 dans les mashups dans le cadre d‟un système de contrôle distribué (c'est-à-dire un robot
exploitant les billets de blogs).
5.3.1.3 Sandboxing insuffisant
Les fonctionnalités de sandboxing offertes par la balise HTML „IFrame‟ sont souvent insuffisantes. Plusieurs
fonctions des Iframe permettent en particulier la communication interdomaine.
•
Les contrôles de formulaire au sein des Iframe sont accessibles à la page qui intègre l‟Iframe, même si
elle provient d‟un domaine différent.
•
Les Iframe peuvent engendrer de nouveaux contextes de navigation, des boîtes de dialogue modales
et des alertes sur d‟autres domaines.
•
Les Iframe peuvent naviguer dans d‟autres contextes de navigation.
Pour en savoir plus sur ces attaques, cf. Cross-Domain Communication with IFrames (21).
5.3.1.4 Authentification faible
L‟authentification faible et l‟existence de services anonymes facilitent l‟usage d‟outils Web 2.0 qui
détournent les informations de compte (avec toutes les menaces que cela comporte) dans le but d‟usurper
l‟identité de personnes et de publier des messages «en leur nom» (usurpation d‟identité) pour harceler,
injurier ou dénigrer autrui. L‟impact est encore accru par la complexité de la procédure d‟effacement des
informations publiées et par le manque de rigueur des conditions de service.
Authentification de l’utilisateur
Le formulaire web identifiant/mot de passe est la méthode d‟authentification standard de l‟utilisateur. Il
s‟agit d‟une méthode d‟authentification très peu sûre, et ce pour plusieurs raisons:
•
Les mots de passe sont faciles à deviner et sont généralement transmis en clair (et sont donc sujets à
l‟écoute électronique et aux agissements des logiciels espions).
•
Si un utilisateur réutilise son mot de passe sur plusieurs sites, un initié malveillant sur un site pourra
usurper son identité sur d‟autres sites.
•
Les utilisateurs ne sont pas sous le couvert de l‟anonymat.
•
Les utilisateurs sont formés à saisir leurs mots de passe dans des formulaires web potentiellement non
sécurisés au lieu de les saisir dans une boîte de dialogue «mot de passe» protégée au niveau du système
d‟exploitation.
•
Les procédures de récupération de mot de passe sont souvent faibles.
•
Il n‟est pas rare qu‟un même service combine plusieurs bases utilisateur présentant des niveaux de
sécurité différents (dont certains sont très faibles), tandis que des fonctionnalités d‟authentification et de
sécurité renforcées s‟appliquent à quiconque ouvre un nouveau compte. L‟utilisateur final existant a donc un
faux sentiment de sécurité. Les comptes existants sont par exemple habilités à changer leurs mots de passe
après avoir répondu à une question de sécurité faible, tandis que les comptes récents sont autorisés à
retrouver le mot de passe au moyen d‟une adresse de courriel secondaire ET après avoir répondu à des
questions de sécurité renforcée.
En outre, les schémas d‟authentification bifactorielle, plus sécurisés, ne sont pas suffisamment arrivés à
maturité pour être modularisables. De nombreux utilisateurs transportent un nombre inacceptable de jetons
encombrants. Ils sont par conséquent réticents à l‟idée d‟accepter de nouveaux jetons d‟autres fournisseurs.
Il est désormais nécessaire de mettre à disposition un schéma d‟authentification bifactorielle pouvant
partager un jeton unique (de préférence au format carte de crédit) entre plusieurs fournisseurs. Les jetons
tels que les mots de passe à usage unique et les cartes à puce ne sont pas non plus suffisamment bien
intégrés dans les API et l‟infrastructure.
Les cookies de session sont un autre domaine dans lequel l‟authentification peut être faible. L‟utilisation
de nombres séquentiels facilement prévisibles est un exemple de faille de ce type.
Authentification du serveur
Le mode standard d‟authentification d‟un serveur est le certificat SSL/TLS. Il est source de
failles multiples, tant pour les utilisateurs que pour les FAI. Par exemple:
•
Les utilisateurs passent outre les erreurs de certificat SSL, ce qui permet aux
attaques «man-in-the-middle» de faire main basse sur leurs mots de passe.
•
Les utilisateurs ne remarquent pas les coquilles et autres anomalies dans les noms
de domaine, ce qui ouvre la voie aux hameçonnages.
Les problèmes d‟authentification serveur jouent aussi un rôle dans certaines failles dans la politique de la
même origine [cf. 5.3.1.1]. Cette politique repose sur l‟adresse internet attribuée par le résolveur DNS, mais
l‟accès réseau recourt en fin de compte aux adresses IP. Lorsque le navigateur lance le téléchargement de
contenu réseau, le nom d‟hôte est d‟abord résolu par le système DNS et ensuite, la demande est envoyée à
l‟adresse IP, qui définit la destination finale. Cependant, l‟origine du contenu, aux fins d‟évaluer la politique de
la même origine, sera toujours déterminée par le nom d‟hôte DNS et la politique de la même origine ne
fonctionne correctement que quand il n‟y a pas non-correspondance entre les noms d‟hôte DNS et les
adresses IP. Malheureusement, les systèmes DNS actuellement utilisés sont vulnérables à certaines attaques
connues, comme l‟empoisonnement de cache DNS (cf. Common Vulnerabilities and Exposures (22)). Dès lors,
en orchestrant une des attaques bien connues sur les DNS, un attaquant peut contourner la politique de la
même origine.
Une fois qu‟un attaquant a exploité une des failles susmentionnées dans la politique de la même origine, il a
accès sans limite au DOM (Document Object Model) du contenu compromis, voire aux documents protégés
par SSL. Ceci est dû au fait que le SSL protège le contenu sur la couche de transport et ne s‟applique pas
aux éléments DOM une fois qu‟il est exécuté dans le navigateur.
Pour contrer les attaques DNS, il faut authentifier les documents via une connexion protégée par SSL.
Cependant, il existe des situations où l‟attaquant contourne la politique de la même origine en dépit du
certificat SSL. Prenons l‟exemple suivant : supposons que le navigateur télécharge un document A à partir de
https://example1.com:443. Le modèle de sécurité du navigateur octroie à un autre document le privilège d‟y
accéder via le Document Object Model, si le document requérant a aussi été téléchargé via une connexion
HTTPS au départ du domaine example1.com au port 443. À ce stade, il importe que le certificat serveur SSL
soit valide, ceci signifie qu‟il a été émis par un tiers de confiance pour le domaine example1.com. Comme
indiqué au point [5.3.1.4], l‟utilisateur moyen ne vérifie pas de manière appropriée les certificats serveur. Il
risque donc d‟accepter un certificat non valide (par exemple émis pour baddomain.com par un tiers qui n‟est
pas de confiance) et l‟attaquant peut alors accéder sans limité au document A. (Pour en savoir plus, cf.
Dynamic Pharming Attacks and Locked Same-origin (23).)
Le détournement des scripts soulève un autre problème. Prenons l‟exemple donné au point [5.3.1.1].
Supposons que le document A de https://example1.com:443 télécharge le script <script src=
“http://b.com/data.js?callback=cb&amp;param=foo”>. L‟objectif de la balise de script est de télécharger le
script data.js sur b.com. Le problème est que l‟attaquant peut remplacer data.js par un script malveillant, car
il est déclenché via un canal non authentifié. L‟attaquant peut ainsi injecter un code de script arbitraire dans
le contexte de sécurité https://example1.com:443, et ce à l‟insu de l‟utilisateur. En fait, cette attaque peut
être considérée comme une attaque par canal auxiliaire qui consiste, pour le pirate, à injecter, dans une
session de communication SSL valide, un code de script malveillant en ligne. (Pour en savoir plus, cf. Beware
of Finer-Grained Origins (24).)
5.3.1.5 Vérification de l’âge
De nombreux services demandent à vérifier l‟âge de l‟internaute avant de lui permettre d‟accéder à certaines
ressources, il s‟agit d‟une procédure légale dans de nombreuses juridictions. Toutes les solutions
actuellement disponibles présentent d‟importantes failles non résolues, par exemple (par ordre croissant
d‟importance):
•
Les accords donnés d‟un simple clic, où l‟internaute est invité à déclarer qu‟il a plus de 18 ans,
n‟obligent pas le visiteur à transmettre des informations sensibles pouvant faire l‟objet d‟un abus ou d‟un
détournement, mais ils sont facilement contournables, car l‟honnêteté de l‟utilisateur est la seule garantie
contre les fausses déclarations. D‟un autre côté, toute autre solution viable pour s‟assurer de l‟âge des
requérants enfreindrait leur droit au respect de la vie privée.
•
Les comptes de messagerie électronique émis à la naissance par l‟Administration peuvent être utilisés
pour vérifier l‟âge. Néanmoins, ils peuvent faire l‟objet d‟hameçonnage ou les mots de passe peuvent être
délégués, ce qui peut être source de conséquences encore plus graves.
•
La détention de cartes d‟identité nationales électroniques (cartes à puce) émises par l‟État est prouvée
à l‟aide d‟un code PIN ou d‟un mot de passe. Cependant, ceux-ci peuvent être délégués (l‟expérience des
cartes de crédit montre que les citoyens sont prêts à divulguer des jetons, même très sensibles). De même,
ils révèlent souvent bien plus que des données à caractère personnel sur l‟individu que le simple fait d‟être ou
non majeur.
Remarquez qu‟il est plus aisé de vérifier qu‟une personne a plus de 18 ans que de contrôler si elle a moins de
18 ans, étant donné qu‟il y a un grand nombre de situations nécessitant de prouver qu‟une personne est
majeure et un certain nombre de documents (permis de conduire) qui ne sont accessibles qu‟aux personnes
ayant atteint un certain âge. Les principaux critères d‟une solution vraiment fiable de vérification de l‟âge
sont les suivants:
1. Procédure d‟enregistrement avalisée par l‟Administration – L‟enregistrement et l‟inscription doivent être
confiés à du personnel de confiance, qui n‟a aucune motivation commerciale pour frauder.
2. Preuve solide de la détention – Personne d‟autre, hormis la personne qui a émis le jeton ou le secret, ne
devrait pouvoir l‟utiliser. Les mots de passe offrent une solution, mais les individus (surtout les mineurs)
sont prompts à révéler leur jeton et leur mot de passe à autrui. Une solution partielle consiste à recourir à
la divulgation de données plus sensibles pour décourager les gens de déléguer leur mot de passe. Par
exemple, l‟utilisation d‟une adresse de courrier électronique sécurisée émise à la naissance a l‟effet
escompté, car la délégation d‟un mot de passe permettrait d‟accéder au courrier de l‟utilisateur.
Néanmoins, les conséquences sont plus graves si le mot de passe est divulgué.
3. Peu coûteux – Il est possible d‟installer des lecteurs d‟empreintes digitales sur chaque touche d‟un clavier
pour vérifier qui tape, mais leur coût est prohibitif (et ils constituent une grave intrusion dans la sphère
privée).
4. Pratique – Pour contourner les restrictions d‟âge, une solution consisterait à priver les utilisateurs de
connexion internet à domicile et à les obliger à utiliser des espaces de travail agréés pour accéder à
Internet, mais cette solution est malaisée.
5. Non intrusif – Le port de scanneurs d‟ondes cérébrales ou de balises RFID sur la main pourrait être
efficace, mais serait très intrusif.
Malheureusement, aucune solution ne satisfait actuellement à toutes ces exigences. Quoi qu‟il en soit,
l‟enquête de l‟ENISA (1) a révélé que 50 % seulement des utilisateurs du Web 2.0 étaient d‟avis que les
mécanismes de vérification de l‟âge n‟étaient pas dignes de confiance. Pour de plus amples informations, cf.
la recommandation sur la sensibilisation [6.1.3].
5.3.1.6 Filtrage de contenu
Un problème connexe (autre garde-fou pour protéger les mineurs) est que les logiciels de filtrage de contenu
sont moins efficaces dans les environnements Web 2.0 car le contenu est moins prévisible et dépend de la
culture du contenu généré par l‟utilisateur, qui peut évoluer rapidement. Des études telles que Safer Internet
(25) ont mis ce problème en lumière. La moitié des 23 filtres testés en 2006 et en 2007 ont amélioré leurs
fonctionnalités de filtrage de contenu sexuel. Malheureusement, huit éditeurs ont obtenu une note inférieure
à celle de l’année précédente sur le plan du contenu sexuel (uniquement pornographique), en partie parce
que nos scénarios d’essai comportaient du contenu Web 2.0, plus difficile à filtrer. Néanmoins, de nombreux
utilisateurs font confiance à ces mécanismes dans un contexte Web 2.0, l‟enquête de l‟ENISA a ainsi révélé
que 24 % seulement des utilisateurs avaient déclaré ne pas se fier à ce type d‟outils dans un environnement
Web 2.0.
5.4 Problèmes inhérents au processus de
développement
Cette catégorie de risques a trait aux caractéristiques des processus de développement qui
ont une incidence sur les applications Web 2.0.
5.4.1 Développement côté client – API complexes
De plus en plus, les applications Web 2.0 transposent des fonctionnalités capitales pour la sécurité chez le
client. Quand une application composite (mashup) traite des données de différentes sources de confiance dans
le navigateur, ce code côté client devient vital pour la sécurité. Les compétences de codage des développeurs,
conjuguées à la complexité des API, sont sans commune mesure face à la difficulté de la tâche. Dans ce
domaine, les widgets interactifs, qui se servent des technologies web comme environnement de
développement d‟applications locales (et capitales pour la sécurité!), sont révélateurs de la qualité du code.
Pour des exemples de failles dues à cette piètre qualité de code dans les widgets, on consultera Widgets –
Web Vulnerabilities for All (26), Web Application Security Issues (27) et 24C3 lightning talk (28).
5.4.2 Brièveté des cycles de développement
Dans le marché extrêmement concurrentiel et en mutation rapide où évoluent les applications Web 2.0, la
plupart de ces dernières ont des cycles de développement très brefs. Ceci signifie que la sécurité est souvent
négligée (évaluation des failles inexistante ou inadéquate, et documentation manquante ou incomplète
(énième version bêta etc.)). En fait, les utilisateurs finals deviennent les nouveaux bêta-testeurs. Même dans
les sociétés web «sensibilisées à la sécurité», les widgets sont souvent développés en un temps record et avec
un budget restreint. Les tiers fournisseurs de widgets ne vérifient presque jamais la sécurité.
5.4.3 Exemple: cross-site scripting (XSS)
Le cross-site scripting (abrégé XSS) est sans doute la catégorie de faille de sécurité la plus largement
diffusée, associée à des applications Web 2. et l‟un des principaux vecteurs d‟attaques malveillantes émanant
de sources Web 2.0. Les failles XSS surviennent quand une application s‟empare de données fournies par
l‟utilisateur et les envoie à un navigateur sans d‟abord valider ou encoder ce contenu. En d‟autres termes,
ces failles sont imputables aux mauvaises pratiques de développement, bien qu‟elles puissent être déjouées
dans une certaine mesure par des IDE plus intelligentes ou par une meilleure gestion des types de contenu
dans les langages de script.
Le XSS permet aux attaquants d‟exécuter un script dans le navigateur de la victime, qui peut détourner des
sessions utilisateur, défigurer des sites web et introduire des vers. Le XSS connaît de nombreuses variantes,
mais nous le décrivons ci-dessus à l‟aide d‟un scénario simple, à titre d‟illustration. Pour d‟autres exemples et
de plus amples informations, cf. XSS Attack Information (29).
5.4.3.1 Exemple simple de XSS
Un exemple classique de XSS dans un contexte Web 2.0 est celui où la séquence d‟échappement des crochets
«<» (employés pour ouvrir et fermer les balises) n‟est pas correcte. Si une application Web 2.0 permet aux
utilisateurs de saisir des commentaires sur une page où la séquence d‟échappement des caractères «<» et
«>» n‟est pas correcte, n‟importe quel utilisateur peut entrer un commentaire contenant une balise <SCRIPT>
(intégrant un Javascript arbitraire), qui est ensuite exécuté dans le navigateur de la plupart des visiteurs de la
page comportant ces commentaires. Un script de ce type peut effectuer toutes sortes d‟actes malveillants,
comme la création d‟un Iframe caché qui construit une URL reprenant des paramètres de requête contenant
des informations pompées sur la page parente, puis attribue le «src» du Iframe à une URL sur un serveur
commandé par l‟attaquant. Il peut donc voler des informations sur une autre page ou sous un autre onglet du
navigateur, dans l‟environnement de l‟utilisateur.
5.4.4 Mention inadéquate des garanties et des déclarations sur la sécurité
et le respect de la vie privée
Il est rare que les applications web ou les intermédiaires (applications composites ou portails)
mentionnent de manière formelle ou précise les garanties en matière de sécurité et de respect de la vie
privée. En conséquence:
•
Pour les responsables du déploiement système, il est difficile d‟être certains
que leurs systèmes répondent aux garanties de sécurité mentionnées, en particulier
quand le code est conservé et que de nouvelles fonctionnalités sont ajoutées.
•
Les développeurs qui assemblent des applications web et doivent partir d‟hypothèses concernant les
garanties de sécurité peuvent être contraints de vérifier manuellement des politiques formulées de manière
informelle. Ces politiques peuvent être difficiles à interpréter et sujettes à modification.
•
Les utilisateurs finals ignorent souvent qu‟il y a violation de leur droit au respect de la vie privée, ou
que des informations insuffisantes, ou insuffisamment claires, sont fournies concernant les pratiques de
manipulation de données.
Par exemple, quand le service Facebook Beacon a été lancé, les spécifications concernant la collecte des
données et les pratiques de republication étaient au départ inadéquates (30).
Un problème de sécurité connexe pour les widgets est que leur propriétaire et développeur ignore où le
widget sera fourni, dans quel contexte et sur quels sites. Il s‟agit d‟un problème potentiel de gestion de
marque: parfois, des widgets de marque sont fournis dans un contexte inapproprié.
5.4.5 Exposition des méthodes lors des migrations
Plusieurs kits de ressources convertissent automatiquement les applications côté serveur en applications AJAX
de type Web 2.0. Dans ce cas, les applications côté serveur sont invariablement assorties de fonctionnalités
dites «méthodes privées», à savoir des caractéristiques du code auxquelles on ne devrait pas accéder depuis
l‟extérieur. Il existe plusieurs kits qui convertissent automatiquement les applications côté serveur en
applications dynamiques client-serveur (p. ex. utilisant AJAX), voir Google web toolkit (31), Direct Web
Remoting – Client-Server AJAX Framework (32) et ASP.NET AJAX (33). Les procédés de conversion
automatique qui transposent du code en l‟absence de politique assistée par un être humain pour protéger les
méthodes privées peuvent, par inadvertance, exposer des données et méthodes sensibles, avec les
conséquences nuisibles que cela comporte. Ce risque est exacerbé par le fait que certaines structures (p. ex.
Direct Web Remoting (32)) fournissent une liste publique téléchargeable des méthodes disponibles.
5.5 Gestion des connaissances et de l'information
Cette catégorie de risques a trait aux problèmes inhérents à la provenance et à l‟intégrité des
informations, de même qu‟à la gestion des données personnelles dans des environnements Web
2.0.
5.5.1 Pedigree/provenance frauduleux
Du fait de l‟emploi du modèle de syndication décrit au point [3.1.1], ainsi que de la présence d‟intermédiaires
tels que des applications de partage de liens, des applications composites, des portails ou encore proxys de
publicité ou de surveillance des FAI), force est de constater que l‟information est souvent traitée, restituée et
modifiée à de multiples étapes avant d‟être finalement affichée sur l‟écran de l‟utilisateur final. En l‟absence de
mécanismes de non-répudiation et de vérification de l‟intégrité dans les mises à jour des publications, des
billets de blogs et des données sociales, la désinformation se diffuse et se propage facilement, souvent avec
de graves conséquences à la clé. En outre, les utilisateurs finals n‟ont pas recours aux méthodes appropriées
pour déterminer l‟authenticité du contenu. L‟enquête de l‟ENISA a révélé que la plupart des internautes
faisaient simplement confiance au contenu dès lors qu‟il se répétait sur plusieurs URL sur la Toile (1). On
dénombre plusieurs types d‟attaques graves qui exploitent l‟incapacité à établir la provenance et le pedigree
réels de l‟information.
5.5.1.1 Exemple 1: manipulation des cours de Bourse
Les fausses rumeurs propagées via les applications Web 2.0 ont servi à manipuler les cours de Bourse dans
le but de réaliser des plus-values. Social Investing and Pump-and-Dump 2.0 (34) décrit comment un soidisant logiciel social d‟investissement a été détourné pour gonfler les cours boursiers et Could Digg be used
for Suns stock manipulation? (35) explique comment les favoris sociaux peuvent servir à manipuler des
cotations boursières. Des distorsions de cours peuvent aussi se produire à la faveur d‟attaques moins
systématiques, par exemple le cours de l‟action Apple Computer a dévissé quand le blog technologique
Engadget a publié une prétendue «note interne» (mensongère) mentionnant un retard significatif de la
commercialisation du téléphone portable iPhone tant attendu (36).
5.5.1.2 Exemple 2: pilotage de botnets via les applications web
composites
Les botnets, c'est-à-dire des réseaux de millions de microgiciels installés par des
programmes malveillants sur les ordinateurs des utilisateurs, servent à pratiquer l‟extorsion
(généralement financière) – pour en savoir plus, cf. Botnets – the silent threat (37). Les
botnets sont habituellement commandés par des canaux tels que IRC (Internet relay chat) ;
cependant, des chercheurs en sécurité ont récemment découvert que des attaques
exploitaient des fonctionnalités du Web 2.0, comme les billets de blog et les messages
électroniques vers des interfaces RSS, pour commander les botnets. L‟emploi de tels canaux pour piloter et
maîtriser les botnets rend beaucoup plus difficile de remonter jusqu‟à l‟auteur de l‟attaque, et, en raison de la
nature ouverte de l‟architecture des applications composites, les interfaces de commande sont très difficiles à
fermer. Les applications composites sont parfaitement adaptées aux systèmes massivement distribués dotés
de structures de commande dont il est impossible de retrouver la trace et donc susceptibles de favoriser un
éventail d‟attaques connexes (pour en savoir plus, cf. Use of Web 2.0 technologies to control botnets (38) et
With Web 2.0, a new breed of malware evolves (39)).
5.5.2 Failles des systèmes de connaissances collaboratifs
La faille la plus caractéristique des bases de connaissances collaboratives réside dans leur mécanisme
d‟édition. Par défaut, les articles publiés sur un site Wiki octroient des privilèges «d‟écriture» aux
utilisateurs, anonymes ou enregistrés. Généralement très rudimentaire, le contrôle d‟accès se subdivise
en trois catégories:
•
modifiable par tous,
•
uniquement modifiable par les utilisateurs enregistrés,
•
uniquement modifiable par les rédacteurs.
Il est généralement malaisé voire impossible de déterminer la fiabilité, l‟intégrité et la provenance des
affirmations formulées. Par exemple, il n‟y a aucune validation de l‟identité de l‟utilisateur, aucune signature
n‟est disponible pour le contenu. Les systèmes de réputation ne sont pas utilisés et s‟ils le sont, les failles
(collusion, blanchiment, Sybil attacks, etc.) ne sont généralement pas évoquées. Pour en savoir plus, cf.
Reputation-based systems: a security analysis (40).
5.5.2.1 Exemple: données médicales
Le manque de fiabilité de l‟information peut avoir de graves conséquences. Par exemple, 25 % seulement
des utilisateurs interrogés dans le cadre de l‟enquête Online Health Search 2006 (41), qui recherchent
régulièrement des conseils médicaux sur l‟Internet, vérifient la source et la date des informations trouvées
pour juger de leur qualité. Des outils tels que Wikiscanner (42), qui pistent les FAI sources des articles
rédigés de manière collaborative, indiquent que l‟introduction délibérée de contenus erronés et de
désinformation sont fréquents.
5.5.3 Attaques des métadonnées
•
L‟emploi de formats de métadonnées tels que ID3 (pour les fichiers MP3), RSS et autres métadonnées
RDF, est crucial pour le fonctionnement des applications Web 2.0. Les métadonnées recèlent plusieurs failles
de sécurité importantes.
•
Pour les métadonnées, l‟infrastructure de confiance et d‟intégrité est pratiquement inexistante. Les
ontologies, les nuages de mots-clés et les schémas peuvent souvent être trafiqués ou remplacés pour fournir
des informations complémentaires à un attaquant via des inférences involontaires (43). On rencontre aussi de
graves problèmes avec les signatures numériques pour les données au format RDF telles que les ontologies et
RDF, ce qui signifie que les outils de signatures numériques par RDF sont donc inexistants (44).
•
Il n‟existe pas de méthode standardisée permettant d‟ajouter des informations de provenance à la
plupart des formats de métadonnées. Cela engendre bon nombre des failles dans la gestion des connaissances
décrites ci-dessus, p. ex. celles inhérentes à la syndication.
•
L‟usage abusif de métadonnées est souvent à l‟origine d‟hameçonnages, car il peut servir à tromper
l‟utilisateur sur l‟origine de la ressource web, p. ex. un lien erroné associé à une image.
•
Les métadonnées cachées dans les pages et sources Web 2.0 peuvent
divulguer des informations privées, comme l‟illustre le cas de Wikiscanner (42), ainsi
que des métadonnées dissimulées dans des documents. Pour en savoir plus, cf.
Microsoft Word’s Hidden Tags Reveal Once-Anonymous Peer Reviewers (46) et Psst! Your Metadata is
Showing! (47). Les métadonnées sont souvent la source d‟une syntaxe mal formée, ce qui conduit à un
dépassement de tampon. Il existe des milliers d‟exemples de telles failles, à titre d‟exemple, citons CVE-20080065 (45). Pour d‟autres exemples concernant les médias du web, , cf. Exposing Vulnerabilities in Web
Software (48).
•
Bien qu‟il ne s‟agisse pas de métadonnées au sens strict, les Codecs, un format binaire utilisé pour
assurer l‟interopérabilité des formats d‟affichage des médias, constituent une autre catégorie importante de
compléments destinés aux médias Web 2.0. qui recèlent des failles considérables, dont certaines sont aussi
décrites dans (48).
5.5.4 Violation de la vie privée
Selon l‟enquête de l‟ENISA (1), l‟usurpation ou l‟usage abusif des données à caractère personnel était
l‟inquiétude première citée par les utilisateurs finals du Web 2.0. Cela souligne l‟importance du maintien des
droits fondamentaux au respect de la vie privée, de l‟anonymat et de l‟autodétermination informationnelle
inscrits notamment dans la Convention européenne des Droits de l‟Homme (article 8) (49) et dans la
législation européenne sur la protection des données, telle que la directive 95/46/CE (50).
5.5.4.1 Marquage et recherche d’images
La publication et le marquage d‟images ou de rapports par des particuliers est un problème grandissant, les
internautes publiant des images sans le consentement du sujet. Ce problème est exacerbé par l‟intégration
des logiciels de reconnaissance faciale dans les applications standard de partage de photos comme Google
Picasa (9), ce qui entraîne une croissance exponentielle du nombre de marquages sur les photos, avec
comme corollaire qu‟elles sont faciles à trouver et à relier. Ce phénomène a de graves implications pour la
confidentialité, d‟autant que les contrats de licence utilisateur en vertu desquels ces applications sont
distribuées stipulent que le marquage est «opt-out» (c‟est-à-dire que si vous n‟approuvez pas le fait que
quelqu‟un a marqué une image, vous devez expressément demander à l‟éditeur de supprimer le marquage).
En fait, l‟enquête de l‟ENISA (1) a révélé qu‟un nombre significatif d‟utilisateurs étaient adversaires du
marquage d‟image dans différentes situations: 60 % sont mécontents quand un collègue marque une photo
sur un profil de réseau social et 44 % se déclarent contrariés quand un ami fait de même. Ces logiciels
pourraient aussi être utilisés pour lier des profils anonymes à des données personnelles en associant des
images similaires.
La publication d‟images par des particuliers est prise au sérieux par les gouvernements. Ainsi, la Pologne au
parlement un projet de loi (août 2008) portant création d‟un nouveau code pénal comportant un article qui
instaure une peine de 3 mois à 3 ans d‟emprisonnement pour diffusion d‟images pornographiques d‟une
personne sans son consentement et une sanction allant d‟une amende à 2 ans d‟emprisonnement pour la
diffusion d‟images de personnes nues sans autorisation.
5.5.4.2 Marketing comportemental
Le marketing comportemental est une source de revenu très courante dans les applications Web 2.0, le
contenu et l‟échange de données personnelles étant souvent la principale proposition de valeur. L‟activité
des sociétés de marketing repose généralement sur l‟hypothèse selon laquelle tout élément qui ne
comporte pas de champs de données personnelles explicites, comme le nom, l‟adresse, l‟adresse de
courrier électronique ou la date de naissance, n‟est pas une donnée à caractère personnel et n‟est donc pas
soumis à la législation sur la protection des données.
Nous relevons qu‟un tel postulat est extrêmement contestable si l‟on se réfère à la définition des données à
caractère personnel donnée par le Groupe de travail Article 29 (51), qui stipule que l‟adresse IP peut être
considérée comme une donnée à caractère personnel. Le problème de la définition des données réellement
anonymes est nettement plus complexe. Les informations relatives aux hobbies, aux amis et aux critères de
recherche, etc. peuvent être très personnalisées et permettre d‟identifier un individu au même titre que son
nom, son adresse ou sa date de naissance. En outre, leur connaissance par un tiers peut avoir des
conséquences négatives sur la vie privée ou la situation économique et/ou valoir une exclusion discriminatoire
de certains services. On en arrive à une situation où certains fournisseurs traitent des données qui, en réalité,
sont des données qui revêtent un caractère éminemment personnel (par le simple fait d‟être spécifiques à un
individu et donc permettant de l‟identifier), mais qui, techniquement, ne sont pas soumises à la loi sur la
protection des données. Ce problème est au cœur du débat sur le marketing comportemental.
En outre, 7 % seulement des utilisateurs interrogés par l‟ENISA estiment que cette forme de
marketing constitue une évolution positive parce qu‟elle augmente la pertinence du
marketing, tandis que 23 % pensent qu‟elle devrait être illégale et que 28 % l‟acceptent
parce qu‟ils la jugent nécessaire au fonctionnement du service, sans être pour autant
satisfaits de la pratique (1).
5.5.4.3 Autres problèmes inhérents à la confidentialité
•
Contrôle par inférence - Outre la possibilité d‟inférer des liens entre profils à partir
d‟images marquées, une autre menace réside dans l‟aptitude à établir des inférences entre plusieurs instances
de données distribuées, aucune d‟elles prise isolément ne permettant une identification personnelle.
•
Divulgation de données personnelles très sensibles sur les réseaux sociaux et les blogs - De nombreux
utilisateurs n‟ont conscience ni de la taille ni de la nature potentielles du groupe qui a accès aux billets publiés
sur les réseaux sociaux. Ce point est abordé en détail dans Security Issues and Recommendations for Online
Social Networks (10).
•
Rétention et rémanence des données - Les utilisateurs du Web 2.0 publient habituellement des
données sur un grand nombre de sites gérés par des particuliers (p. ex. blogs, profils RS), c'est-à-dire dans
une configuration très distribuée qui complique fortement la rectification ou la suppression des
communications. Autre facteur qui complique encore la suppression des données: leur réplication d‟un site à
l‟autre, c'est-à-dire qu‟un site internet extrait des données d‟un autre, qui les republie à son tour suivant un
modèle architectural décrit au point [3.1.1].
•
Fuite de secrets institutionnels par l‟entremise de logiciels d‟entreprise non sûrs exécutés dans un
navigateur - le risque de fuite de données associé à l‟utilisation de logiciels d‟entreprise articulés sur un
navigateur est bien connu. Dans ce contexte, les deux failles principales sont l‟insécurité de l‟environnement
du navigateur que nous avons mise en exergue au point [5.3] et la possibilité de transfert et de stockage des
données institutionnelles dans un centre de données web.
5.5.5 Problèmes inhérents aux conditions de service
Depuis que les services Web 2.0 hébergent du contenu généré par l‟utilisateur, les FAI sont souvent mis sous
pression pour exercer une surveillance (censure) sur ce contenu. Par exemple, les fournisseurs peuvent
intervenir pour l‟une des raisons suivantes:
•
Un utilisateur a publié du contenu inapproprié ou illégal.
•
Un utilisateur a publié du matériel protégé par droit d‟auteur.
•
Un utilisateur a diffamé autrui ou a publié des informations privées sur son compte.
•
Un utilisateur a tenu des propos critiques à l‟égard du fournisseur d‟accès, ou
•
Un utilisateur a exprimé des commentaires hors de propos sur un forum.
Certaines de ces interventions peuvent être initiées par d‟autres utilisateurs, par exemple quand un
fournisseur d‟accès supprime du contenu soumis à droit d‟auteur à la demande du titulaire du droit en
question, mais d‟autres peuvent être mises en œuvre par le fournisseur d‟accès, par exemple la suppression
de déclarations critiques à son encontre. De même, certaines de ces mesures sont acceptables; d‟autres
sont clairement constitutives d‟une violation des droits des utilisateurs.
De nombreux utilisateurs attendent des FAI qu‟ils filtrent les courriers indésirables et autres contenus, mais en
endossant le rôle de gendarme, les fournisseurs renoncent aux protections légales dont ils jouissent en tant
que « simples transporteurs », avec un grand nombre de conflits d‟intérêt pour corollaire.
Ceci est considéré comme un problème particulièrement important pour les fournisseurs du web 2.0 en raison
du fait que le contenu est largement établi par les utilisateurs et des risques élevés pour les finances et la
marque, résultant des incidents.
5.5.6 Faible usage du protocole TLS/SSL
De nombreux fournisseurs d‟accès transfèrent des informations très sensibles (y compris des mots de passe
donnant accès à des informations complémentaires) entre client et serveur, et ce sans les crypter ou sans
authentifier le fournisseur de services à l‟aide de mécanismes standard de type TLS.
Un des principaux obstacles à l‟utilisation généralisée du TLS est son manque de
convivialité. Les utilisateurs éprouvent souvent des difficultés à décoder les
informations fournies sur les certificats, et en particulier les messages d‟erreur
générés par des certificats non vérifiés, quand ils ne sont pas simplement noyés sous la pléthore de
messages.
5.6 Problèmes inhérents à l’utilisateur final
Cette catégorie de failles a trait à l‟utilisation des environnements Web 2.0 et à la compréhension des
aspects de sécurité par les utilisateurs finals.
5.6.1 Problèmes de sensibilisation du public
Le manque de sensibilisation du public aux problèmes suivants sape la sécurité et les comportements
d‟internautes sûrs sur internet dans les environnements Web 2.0. Pour obtenir la liste complète des
problèmes à aborder dans les campagnes de sensibilisation, cf. The new users’ guide: How to raise
information security awareness (52).
•
Données difficiles à supprimer – Les utilisateurs n‟apprécient pas qu‟il soit difficile de supprimer toutes
les traces de ces informations en raison de la réplication des données d‟un site à l‟autre, par exemple quand
un site internet extrait des données d‟un autre site, puis les republie.
•
Public – Comme précisé en (10), les utilisateurs de réseaux sociaux sont rarement conscients de
l‟ampleur et de la nature du public pour lequel le contenu est disponible.
•
Les utilisateurs (individus, entreprises ou pouvoirs publics) ont tendance à croire et à dupliquer les
informations fallacieuses ou non vérifiées que des tiers malveillants ou animés d‟intentions commerciales
publient sur la Toile, y compris sur des sites de réseau social.
•
Les utilisateurs ne mesurent pas ou ne cernent pas totalement les divers mécanismes de sécurité déjà
en place sur les sites web, comme les certificats SSL/TLS ou les CAPTCHA (53).
5.6.2 Manque de contexte de l’interface utilisateur
Les utilisateurs ont coutume de faire confiance aux sites sur la base de leur nom ou du nom de la société
dans le champ URL. S‟ils font confiance à l‟URL, ils interagiront librement sur le site. Avec de nombreuses
technologies Web 2.0, soit il n‟y a pas de contexte comparable sur lequel l‟utilisateur peut fonder sa
confiance ou, s‟il y a un contexte, il peut être trompeur.
Exemples
•
Les portails, les applications composites, les IFrame, etc., intègrent du contenu de sources multiples
sur une même page [cf. chapitre 3]. L‟utilisateur peut avoir coutume de fournir des informations sensibles sur
d‟autres pages du site en question (p. ex. Yahoo Stores) et persister même quand le fournisseur de services
généralisés présente du contenu d‟une source à laquelle l‟utilisateur serait autrement peu enclin à se fier.
•
De nombreux sites généralistes proposent une zone «Commentaires» que les utilisateurs anonymes
peuvent utiliser pour ajouter leur propre contenu sur la page principale. De nombreux utilisateurs parcourent
rapidement les longs articles et peuvent aisément prendre par erreur un commentaire bien formulé pour un
paragraphe de l‟article principal. Cela peut permettre aux auteurs de courrier indésirable et aux annonceurs
de conférer à leur contenu l‟autorité ou le cachet d‟un site plus réputé.
Ce type de faille est imputable à l‟absence de normes de conception visuelle bien établies pour indiquer que le
contenu n‟est pas aussi fiable que celui du site primaire ou inversement, au fait que l‟on se fie excessivement
à l‟utilisateur pour arrêter des décisions relativement à la confiance.
5.6.3 Attaques automatisées (se faire passer pour un utilisateur
final)
La difficulté de savoir si un système est ou non contrôlé par un être humain constitue une
faille importante du Web 2.0. La capacité d‟automatiser un processus dont on croit
généralement qu‟il est piloté par un être humain peut permettre aux attaquants d‟abuser de
la confiance et de court-circuiter les contrôles visant à prévenir l‟accès par des attaques de
force. Exemples d‟attaques de ce type:
1. L‟un des principaux remparts contre une automatisation indésirable est un CAPTCHA - une image contenant
du texte qui a été rendu difficile à lire par un programme informatique, mais qui est lisible avec une relative
facilité par un être humain. Il est employé pour protéger les systèmes (comme la messagerie et la création de
comptes) qui ne devraient pas être automatisables.
Différentes attaques de haut vol sur les CAPTCHA ont mis en lumière la vulnérabilité de ces systèmes. À titre
d‟exemples, cf. Yahoo’s CAPTCHA Security Reportedly Broken (54) et Spammers crack Gmail CAPTCHAs (55).
L‟aptitude à déjouer un CAPTCHA (ou toute autre technique anti-automatisation comme le filtrage) ouvre la
voie au courrier indésirable , aux Sybil attacks sur les systèmes de réputation (40) ainsi qu‟à l‟infiltration des
réseaux sociaux, sans oublier la collecte des données personnelles. Ainsi, Friendbot (56) permet de créer des
«amis» automatiques sur MySpace, ce qui permet au contrôleur d‟envoyer du courrier indésirable, de collecter
des données personnelles. Les tendances futures pourraient inclure des outils permettant d‟automatiser la
création de profils en ligne sur des ensembles de données distribués (blogs, forums, etc.) à des fins de fraude
ou d‟avantage politique – cf. Investigating individuals and organisations using open source intelligence (57).
2. L‟ingénierie sociale par l‟entremise d‟agents de «chat» autonomes où les internautes parlent à un robot
comme s‟il s‟agissait d‟un véritable être humain et divulguent des informations sensibles (58) (59).
3. L‟automatisation qui a recours à des humains pour résoudre des CAPTCHA dans le cadre d‟une attaque.
5.7 Failles générales des logiciels et des scripts
Ce chapitre a trait aux failles logicielles (à l‟exception du contrôle d‟accès et de l‟autorisation). Nous
n‟abordons pas les failles génériques des infrastructures telles que les réseaux et les serveurs web, qui
portent atteinte à des applications Web 2.0 de la même façon qu‟une application web quelconque.
5.7.1 Failles de périphériques ayant des capacités web
Un grand nombre de périphériques sont compatibles avec les fonctionnalités web et font réagir de facto des
serveurs web, même s‟il est possible que nous ne les considérions pas comme tels. Les routeurs haut débit
domestiques en font partie. Étant donné qu‟ils sont compatibles web, le risque existe que ces périphériques
soient vulnérables aux attaques orchestrées sur le Web 2.0 telles que les attaques CSRF. Un autre type
d‟attaque découvert dans cet ordre d‟idées est le drive-by pharming (61). Dans une attaque de ce type, un
attaquant peut intégrer un élément de code HTML spécifique dans une page web (voire un message
électronique). Une fois logé dans l‟ordinateur de la victime, le code se connecte subrepticement à son routeur
domestique haut débit et modifie ses paramètres DNS. L‟attaquant peut soit définir un DNS totalement
différent de celui que la victime utilisait auparavant, soit simplement modifier des correspondances
hôte/adresse IP spécifiques (du type de celles associées à la banque de la victime). Cette menace a été
réellement observée sur le terrain. Dans un cas précis, des victimes mexicaines ont été visées: leur modèle de
routeur était associé à un modèle fourni par un grand FAI mexicain. La requête HTTP de l‟attaquant soumise
au routeur de la victime a modifié la correspondance hôte/adresse IP d‟une grande banque mexicaine.
Une autre catégorie intéressante de faille spécifique au Web 2.0 portant atteinte à l‟infrastructure est la
possibilité de scannage des ports via XMLHttpRequest (XHR). Online port scanner (62) propose par exemple
un service licite, à consentement obligatoire, de test des failles intégrant un test de scannage de port XHR en
ligne.
5.7.2 Failles du plug-in de navigateur
Les navigateurs web ont dû fréquemment résister au choc d‟attaques sur le web. De
manière caractéristique, les attaquants essaient d‟exploiter une ou plusieurs failles d‟un navigateur pour en
faire un vecteur de transmission de programmes malveillants sur l‟ordinateur de la victime (sous la forme de
drive-by download). Néanmoins, les attaques à l‟encontre des navigateurs tendent maintenant à tomber en
désuétude et sont à présent supplantées par les attaques sur leurs plug-ins. Constamment en quête d‟une
expérience de navigation enrichie, les utilisateurs sont toujours plus nombreux à installer des plug-ins à
succès dans leur navigateur.
Pour mettre cette problématique en perspective,
soulignons que, selon le volume XIII du Symantec
Internet Security Threat Report (63), on recensait au
second semestre 2007, 88
failles dans les navigateurs Mozilla, 22 dans
Safari, 18 dans Internet Explorer et 12 dans Opera.
Au cours des six mois précédents, on avait
dénombré 39 failles dans Internet Explorer, 34 dans
Mozilla, 25 dans Safari et 7 dans Opera. Toutefois,
Symantec a documenté 239 failles dans les plug-ins
de navigateur au cours des six derniers mois
de 2007, contre 237 au premier semestre. Durant le
second semestre 2007, 79 % de ces failles ont
touché des composants ActiveX, contre 89 % au
premier semestre. Ces statistiques révèlent
clairement que les failles dans les plug-ins de
navigateur devancent de loin les vulnérabilités
classiques rencontrées dans les navigateurs. Un
exemple de faille de plug-in est décrit au point
[5.7.2].
5.7.3 Failles de JSON
JSON (JavaScript Object Notation) est un format léger d‟échange de données objets Javascript entre client et
serveur. JSON recèle plusieurs failles importantes. Elles se répartissent en deux groupes.
1
Attaques exploitant le fait que les requêtes JSON peuvent être incluses dans des balises SCRIPT qui
contournent la politique de la même origine et permettent d‟extraire des données à partir d‟objets. Une
requête peut ainsi être soumise à Javascript depuis un nom de domaine arbitraire et les résultats des objets
inspecteurs qui sont renvoyés peuvent être transmis à un domaine arbitraire. Ceci permet a un cybercriminel
de demander des données personnelles à propos d‟un client arbitraire (demande de client d‟une page web
malveillante) puis de les envoyer à un serveur web attaquant, à l‟aide, par exemple, d‟une XMLHttpRequest.
Cette faille a été exploitée en 2006 lors d‟une attaque ayant permis le vol de contacts Gmail (64). Autre
exemple: CVE-2008-1318, une attaque perpétrée contre Mediawiki (65). Il s‟agit d‟une faille particulièrement
virulente pour les applications installées sur un intranet d‟entreprise, qui peut perdre des données si,
d‟aventure, un utilisateur venait à consulter un site pernicieux.
2
Attaques exploitant le fait que les objets JSON s‟exécutent parfois directement sur le client sans
validation à l‟aide de la fonction eval(). Cette pratique s‟effectue à des fins légitimes pour charger une plage
en mémoire, mais un attaquant peut intégrer du code malveillant dans la demande/réponse JSON, en plus
d‟un constructeur de plages.
6 Recommandations et contre-mesures
Dans ce chapitre, nous formulons des recommandations en vue d‟atténuer les risques
exposés au chapitre précédent. Pour établir une corrélation avec les failles, chaque
recommandation fait référence aux failles auxquelles elle vise à remédier.
6.1.1 Recommandations concernant les politiques
gouvernementales
6.1. 1. 1 Incitants politiques
• En vue de répondre aux problèmes évoqués au point [PROBLÈMES INHÉRENTS AU PROCESSUS DE
DÉVELOPPEMENT], les gouvernements devraient proposer des incitants politiques en faveur de pratiques de
développement sécurisées. Des incitants envisageables pourraient être, par exemple:
• Certification légère – Les régimes de certification de sécurité standard (cf. Information Security
Certifications (66)) tels que ISO 27001 et Common Criteria sont trop onéreux et fastidieux pour être
transposés dans les petites entreprises, qui sont souvent au cœur du développement applicatif Web 2.0.
Des versions «certification légère», allégées et donc moins coûteuses, des régimes de certification de
sécurité, accessibles aux micro-entreprises ou aux PME, conviennent tout spécialement pour favoriser de
meilleures pratiques en matière de sécurité parmi les fournisseurs du Web 2.0.
• Dispenses de déclaration – Un autre modèle utile en termes d‟incitants politiques est la loi fédérale
suisse relative à la protection des données, qui définit des critères de certification volontaires et motive les
entreprises à s‟y conformer en les dispensant d‟établir des rapports coûteux.
• Financement de mesures pilotes intégrant des fonctionnalités de sécurité dans les applications Web
2.0. Le projet STORK (67) est un exemple de mesure pilote déjà en vigueur.
•
Pour répondre aux enjeux soulevés au point [PROBLÈMES INHÉRENTS AUX CONDITIONS DE
SERVICE]: les gouvernements devraient prêter attention et répondre aux préoccupations des fournisseurs du
Web 2.0 quant aux obligations conflictuelles engendrées par la législation relative au statut de «simple
transporteur» ou d‟«exploitant de communications». Pour remplir les conditions de simple transporteur
d‟informations, les FAI ne doivent pas s‟immiscer, de quelque manière que ce soit, dans le contenu fourni.
L‟incertitude est dès lors de mise parmi les fournisseurs, quant au moment et à la manière de pratiquer tout
filtrage de contenu. Ce critère est particulièrement pertinent dans un environnement Web 2.0, car le contenu
généré par l‟utilisateur en est une forte composante. Les fournisseurs Web 2.0 devraient donc tirer parti d‟une
initiative publique visant à clarifier cette ambiguïté.
•
Marketing comportemental – cf. faille [MARKETING COMPORTEMENTAL]: les organes tels que la
Commission européenne, les commissions ITRE et LIBE du Parlement européen et le Groupe de Travail Article
29 sur la protection des données encouragent le débat public et intergouvernemental sur l‟équilibre approprié
dans les applications Web 2.0 entre, d‟une part, l‟identification par les stratèges de marketing, l‟application de
la loi et les particuliers, et, d‟autre part, le respect de la vie privée et de l‟anonymat des utilisateurs finals.
Veuillez noter que le chapitre suivant, consacré aux pistes de recherche, concerne aussi les gouvernements.
6.1.2 Pistes de recherche
[Failles concernées: toutes]
Nous recommandons que les sujets de recherche suivants soient financés par le secteur et les
pouvoirs publics.
• Convivialité de TLS/SSL – cf. faille [FAIBLE USAGE DU PROTOCOLE TLS/SSL]: comme décrit au point
[5.5.6], l‟usage du protocole TLS/SSL et du chiffrement des données transférées vers des applications Web
2.0 n‟est pas suffisamment répandu. Ces recherches sont nécessaires pour répandre l‟usage du chiffrement de
bout en bout et améliorer l‟authentification du fournisseur dans les applications Web 2.0.
• Convivialité des mécanismes d‟authentification renforcée (p. ex. mots de passe uniques) – cf. faille
[AUTHENTIFICATION FAIBLE]: l‟authentification renforcée contribue à protéger les données sensibles de
l‟utilisateur et devrait donc être encouragée dans certains contextes. (Remarquons qu‟elle n‟est appropriée
que s‟il faut protéger des données sensibles.) Un des obstacles les plus importants à sa large adoption est la
charge qu‟il fait peser sur l‟utilisateur. Si l‟authentification forte doit devenir l‟alternative pratique sur le Web
2.0, il convient de remédier à plusieurs problèmes:
• Il n‟est pas pratique d‟avoir un jeton physique différent pour chaque service. Il convient d‟étudier des
moyens de partager les jetons entre des services multiples qui ne partagent pas nécessairement les
mêmes données utilisateur.
• Les utilisateurs sont noyés sous le flot actuel d‟expériences utilisateur (p. ex. systèmes articulés sur
téléphones portables, porte-clés, jetons factoriels pour formulaire de carte de crédit, etc.). Des études
sont nécessaires s‟agissant des moyens de standardiser l‟expérience utilisateur en matière
d‟authentification forte.
• Des projets financés par l‟UE devraient diriger et évaluer l‟usage de mécanismes d‟authentification
renforcés (OTP, cartes à puce, mots de passe par texto, etc.) dans les environnements Web 2.0 en vue de
favoriser les environnements d‟authentification renforcés. Citons le projet STORK, financé par l‟UE, qui
prévoit déjà de piloter une application de chat plus sécurisée (cf. faille [AUTHENTIFICATION FAIBLE]).
• Protection contre l‟abus des ressources limitées: les applications du Web 2.0 doivent offrir des
interfaces publiques ouvertes pour la saisie et l‟échange de contenu généré par l‟utilisateur, la création de
compte, etc. Celles-ci sont souvent détournées à des fins non autorisées et malveillantes telles que le
courrier indésirable (cf. [5.6.3]). Les technologies de type CAPTCHA, qui limitent l‟utilisation de ces
ressources aux schémas légitimes (p. ex. humains uniquement), constituent une grave faiblesse des
environnements Web 2.0, qui doit être le sujet d‟études (cf. faille [ATTAQUES AUTOMATISÉES – SE FAIRE
PASSER POUR UN UTILISATEUR FINAL]).
• Infrastructure de confiance recourant aux réseaux sociaux: les réseaux sociaux présentent un
potentiel considérable pour la collecte d‟informations sur ce qui est digne de confiance grâce à de
nouveaux modes de détermination de la fiabilité. Les réseaux sociaux pourraient par exemple servir à
créer une approbation à clé publique très modulaire sur le modèle du web-of-trust (68). Le degré de
confiance cumulé, traduit dans les scores de réputation récoltés sur les réseaux sociaux, peut aussi
permettre de filtrer le contenu et d‟authentifier des déclarations.
• Moyens d‟établir la provenance de l‟information – cf. failles [GESTION DES CONNAISSANCES ET DE
L'INFORMATION]: pour limiter les risques énumérés au point [5.5], il convient d‟étudier les mécanismes
de traçabilité et d‟évaluation du pedigree et de la fiabilité des sources d‟information. Les critères
spécifiques au Web 2.0 d‟une telle norme inclueraient:
• respect de la vie privée et souhait éventuel de la source de garder l‟anonymat – On a critiqué des
efforts engagés dans un domaine connexe pour avoir ignoré cet aspect, cf. référence (69);
• capacité à retracer des versions similaires et leur morphologie; et
• critères de confiance envers le contenu (p. ex. fondés sur la topologie web);
• modèles de sécurité avancés pour ECMAScript – cf. faille [FAILLES GÉNÉRALES DES LOGICIELS ET
DES SCRIPTS]. Javascript est à l‟origine de nombreuses failles [5.7]. De nombreuses initiatives existent
déjà (par exemple Caja (70)) et si nous ne privilégions pas une initiative en particulier, nous tenons à
souligner l‟importance des recherches dans ce domaine.
• modèles et contrats de licence pour les données à caractère personnel – cf. failles [VIOLATIONS DE LA
VIE PRIVÉE]: toute initiative accroissant les droits des utilisateurs finals sur l‟utilisation et la réutilisation
de leurs données ou de tout contenu généré par leurs soins doit être encouragée. Il y a actuellement peu
de mécanismes juridiques ou contractuels pour régir l‟usage non commercial des données d‟un particulier,
bien que ces scénarios soient porteurs de plusieurs menaces graves.
• critères de mesure et cadres de test (analyse de code, test d‟intrusion) pour des applications Web 2.0
sûres et respectueuses de la vie privée: des recherches sont nécessaires dans ce domaine en vue
d‟encourager et de favoriser des pratiques de développement sécurisées (cf. faille [PROBLÈMES
INHÉRENTS AU PROCESSUS DE DÉVELOPPEMENT]).
6.1.3 Sensibilisation
La sensibilisation est une contre-mesure très importante face à bon nombre des menaces
décrites sommairement ci-dessus. Des informations complémentaires sur la manière de
conduire des campagnes figurent dans The new users’ guide: How to raise information
security awareness (71). En général, il est important d‟employer des méthodes contextuelles
en matière de sensibilisation. Par exemple, quand l‟utilisateur se connecte, un lien pourrait
s‟afficher avec un vidéogramme expliquant comment débusquer une falsification de compte
ou détaillant les avantages des méthodes d‟authentification renforcée. Lors de la création de
contenu généré par l‟utilisateur, un lien pourrait fournir des explications aisément compréhensibles à propos
des droits de propriété intellectuelle de l‟utilisateur. Ce chapitre aborde les aspects que nous considérons
comme les plus importants à mettre en exergue dans les campagnes de sensibilisation au Web 2.0.
•
Durée de vie des données sur la Toile – le fait que même s‟il peut être facilement supprimé (cas peu
courant), le contenu généré par l‟utilisateur subsiste dans des caches, des bases de données principales, des
archives, etc. L‟enquête de l‟ENISA (1) a révélé qu‟un pourcentage significatif (59 %) d‟utilisateurs avaient
souhaité supprimer des données après les avoir fournies, et que la moitié d‟entre eux avaient même sollicité
le fournisseur d‟accès pour les épauler dans cette tâche.
•
Données qui peuvent être révélées par les résultats de recherche dans un contexte Web 2.0 (par
exemple : données de profil exposées dans les réseaux sociaux).
•
Utilisation du contrôle d‟accès – comment utiliser les fonctionnalités de confidentialité et autres
fonctions de contrôle dans les applications Web 2.0.
•
Promotion de l‟usage des directives de Net-étiquette sur le Web 2.0 (p. ex. Get Safe Online Guidelines
(72) ou dans un contexte institutionnel (73)).
•
Atouts et utilisation de méthodes d‟authentification renforcées et alternatives à l‟identifiant/mot de
passe.
•
Tous les utilisateurs doivent être sensibilisés au fait que les mécanismes de vérification de l‟âge sont
actuellement peu performants et que, dans ces conditions, il ne faut pas faire trop confiance à l‟âge prétendu
des autres utilisateurs.
•
Il faut apprendre aux mineurs à identifier les comportements inappropriés et à y faire face. Voici une
proposition de liste de contrôle :
• Ne communique jamais tes coordonnées physiques de contact.
• N‟accepte jamais de te rendre à un rendez-vous fixé avec une personne que tu as rencontrée en ligne,
surtout sans en parler au préalable à un adulte.
• Ne réponds pas à des propos inappropriés (intimidants, obscènes ou injurieux) et parles-en à un
adulte.
• Ne communique jamais ton mot de passe ou ton identifiant.
• Sache que d‟autres personnes peuvent donner des informations inexactes à propos de leur véritable
identité.
•
Les parents et les enseignants devraient être avertis des risques susmentionnés afin de mieux
protéger les enfants. Les médias devraient diffuser ces informations dès lors que de nombreux parents
n‟utilisent pas les applications Web 2.0.
•
En particulier, les parents devraient être informés des risques qu‟il y a à se fier aux mécanismes de
vérification de l‟âge pour protéger les enfants ainsi que de la nécessité absolue de surveiller de manière non
automatisée leur utilisation du Web 2.0.
•
– cf. faille [VÉRIFICATION DE L‟ÂGE].
•
Parents et enseignants devraient être sensibilisés aux risques qu‟il y a à se fier aux outils de filtrage
de contenu – cf. faille [FILTRAGE DE CONTENU].
•
Risques inhérents à la protection des données à caractère personnel – Ceuxci sont décrits de manière plus approfondie au point [5.5.4] et dans Security Issues
and Recommendations for Online Social Networks (10).
•
Technologies de protection de la vie privée – Alternatives disponibles et leurs fonctionnalités. Pour en
savoir plus, lire Privacy and Identity Management for Europe (74).
•
Interprétation des signes et erreurs des certificats TLS/SSL dans les navigateurs. Par exemple, la
signification des messages d‟erreur de type «certificat arrivé à expiration», «certificat non émis pour ce
serveur web», etc. (cf. faille [FAIBLE USAGE DU PROTOCOLE TLS/SSL]).
•
Les développeurs d‟applications Web 2.0 et les éditeurs de navigateurs devraient être sensibilisés aux
menaces pour la sécurité et aux pratiques de développement sécurisées.
6.1.4 Normalisation
• Il convient de développer et de promouvoir davantage les spécifications émergentes comme W3C‟s Access
Control for Cross-Site Requests (75), OASIS XACML (76), oAuth (77), OpenID (78), Cardspace (79), Liberty
(80), HTML 5 (81), etc., qui tendent à optimiser la séparation du contrôle, le contrôle d‟accès ainsi que les
fonctionnalités d‟autorisation dans les applications web. Les initiatives suivantes sont à mettre en œuvre
d‟urgence:
•
Cadre complet pour définir des stratégies régissant le transfert de données et l‟accès aux appels de
fonction entre applications web et widgets: il est très important d‟inclure les plug-ins dans ce cadre – cf. faille
[PROBLÉMATIQUE DE LA POLITIQUE DE LA MÊME ORIGINE] – et de favoriser les stratégies par défaut
appropriées.
•
Une structure d‟autorisation précise permettant, en particulier, la délégation d‟accès dans les
applications Web 2.0 – cf. faille [PRIVILÈGES EXCESSIFS]:
• pour une durée limitée,
• à des champs limités,
• à un individu donné,
• avec traçabilité en cas d‟abus (tout en respectant la vie privée).
(Il est possible que XACML puisse remplir cette fonction, mais son adoption dans les environnements
Web 2.0 n‟est pas très répandue).
• Interprétation cohérente des avertissements de sécurité dans les navigateurs – Des travaux ont déjà
été réalisés sur la question dans Web Security Context: User Interface Guidelines (82).
• Provenance et pedigree de l‟information respectueux de la vie privée – cf. failles: [GESTION DES
CONNAISSANCES ET DE L'INFORMATION] – Si les signatures numériques permettent aujourd‟hui d‟établir
dans une certaine mesure le pedigree et la provenance de l‟information, elles ne sont pas adaptées au
contenu Web 2.0, et ce pour les raisons suivantes:
•
elles se fondent sur une PKI qui n‟est pas en place;
•
elles effectuent généralement une authentification forte de l‟auteur;
•
elles reposent sur la canonicalisation du contenu, qui peut se révéler difficile dans le cas du contenu
web 2.0 lié.
Des standards émergents existent en matière de provenance de l‟information tels que The EU
Provenance Project (83), mais rien n‟existe dans le contexte du Web 2.0. Les critères seraient
similaires à ceux décrits au point [6.1.2]. Dans ce domaine de la standardisation, nous rappelons qu‟il
faut aborder les risques pour la confidentialité, c'est-à-dire le respect de la vie privée et l‟éventuel
souhait de la source de rester anonyme.
6.1.5 Enjeux propres aux fournisseurs
• Standardiser et consolider le déploiement de mécanismes d‟authentification renforcée le cas échéant (cf.
faille [AUTHENTIFICATION FAIBLE]).
•
Utiliser les mesures d‟authentification adaptées aux données auxquelles on accède:
p. ex. identifiant et vérification de l‟état du compte à l‟aide d‟un simple mot de passe, mais,
pour les opérations financières, réauthentification à l‟aide d‟un jeton de mot de passe à
usage unique (cf. faille [AUTHENTIFICATION FAIBLE]).
•
Utiliser le chiffrement TLS/SSL lors du transfert de données sensibles telles que les
mots de passe et les données à caractère personnel (cf. faille [FAIBLE USAGE DU
PROTOCOLE TLS/SSL]).
6.1.6 Problèmes propres aux développeurs/éditeurs de
navigateurs
On recense déjà un ensemble important de meilleures pratiques de développement et de descriptions des
pièges courants. Aussi, au lieu de réinventer la roue, nous invitons le lecteur à consulter les exemples
suivants: The OWASP Guide to Building Secure Web Applications (84), Learn to Work Safely with Web 2.0
(85) et Security Survival Tips for the Web 2.0 World (86). Cependant, nous recommandons certaines
initiatives plus générales pour limiter les risques engendrés par un développement déficient:
•
Développer et encourager les processus de développement sécurisé pour le Web 2.0: dans tous les
domaines du développement logiciel, l‟expérience récente a montré que l‟on ne peut améliorer la sécurité du
code qu‟en déployant une approche globale, à tous les stades du développement, p. ex. en dispensant dès la
conception des formations à la sécurisation, à la modélisation des menaces, à l‟examen critique de code et
aux tests d‟intrusion.
•
Fournir des fonctionnalités intégrées aux IDE pour faciliter le développement sécurisé: les
environnements de développement (p. ex. Google Mashup Editor, Eclipse, CodeGear IDE, Komodo IDE) mis en
œuvre pour créer des applications Web 2.0 devraient intégrer des défauts, des modèles de code et des
astuces pour aider le développement sécurisé (cf. faille [PROBLÈMES INHÉRENTS AU PROCESSUS DE
DÉVELOPPEMENT]).
•
Fonctionnalités de sécurité des API: il faudra intégrer, dès la conception, des fonctionnalités et des
modèles de sécurité (p. ex. fonctionnalités de contrôle d‟accès) dans les API (jQuery, script.aculo.us, dojo)
destinées aux applications Web 2.0 (cf. faille [PROBLÈMES INHÉRENTS AU PROCESSUS DE
DÉVELOPPEMENT]).
•
Authentification forte anonyme: traditionnellement, on oppose l‟authentification forte à l‟anonymat,
car elle lie un identifiant à une revendication formulée à son sujet dans une foule de contextes différents, ce
qui augmente la traçabilité des actes d‟un utilisateur. Les certificats employés dans les contextes
d‟authentification contiennent habituellement un ensemble de champs fixes (nom, date de naissance, numéro
d‟ID, etc.), qui sont toujours divulgués à chaque événement d‟authentification, quels que soient les besoins
réels du service. Des technologies d‟authentification respectueuses de la vie privée existent néanmoins. Citons
Credentica (87) et Idemix (88), toutes deux garantes d‟une authentification respectueuse de la vie privée. Ces
technologies offrent une authentification forte, conjuguée à l‟impossibilité d‟établir un lien entre transactions
et à la divulgation sélective des attributs. Néanmoins, à ce jour, très peu de services utilisent cette
technologie. Il faut donc consentir beaucoup d‟efforts en termes de développement et se fonder sur des
prototypes développés dans le cadre de projets tels que PRIME (89), pour les intégrer avec succès dans les
applications Web 2.0. Des efforts sont nécessaires pour les rendre utilisables et intelligibles par les utilisateurs
(cf. faille [AUTHENTIFICATION FAIBLE, VIOLATION DE LA VIE PRIVÉE]).
6.2 Conclusions
Dans l‟ensemble, le Web 2.0 est une évolution technologique et sociale très positive, qui crée de nombreuses
opportunités, à la fois pour les entreprises et pour les particuliers. En donnant accès au savoir,
indépendamment du lieu et du milieu socioéconomique, il fait sienne l‟éthique du code source prônée par
l‟Union européenne. Il a renforcé l‟efficacité en permettant d‟accéder, par navigateur interposé, à des
fonctionnalités applicatives qui étaient anciennement confinées au bureau et à un grand nombre de
possibilités d‟interaction sociale inespérées auparavant.
Son essor rapide a cependant engendré de nombreuses menaces pour la sécurité et a généré des failles
auxquelles on ne s‟est pas encore attelé. En adoptant un train de mesures exhaustif permettant aux
gouvernements, aux fournisseurs d‟accès, aux organismes de standardisation et aux développeurs d‟y
remédier, il sera possible de réduire de manière significative les menaces que représentent la vague actuelle
de Malware 2.0 afin de concrétiser les pleins bénéfices de cette nouvelle technologie.
Web 2.0 Security and Privacy
7
AJAX
API
Blog
Botnet
CAPTCHA
Codec
CSRF
CVE
DNS
DOM
Drive-by
ECMAScript
EULA
Exploitant de
télécommunication
s
FOAF
Folksonomie
GET
Hôte
HTTP
Asynchronous JavaScript and XML (paradigme de développement web)
Application Programming Interface - interface de programmation
d‟applications (bibliothèques de code)
Bloc-notes – site web présentant régulièrement des commentaires, des
descriptions d‟événements, etc.
Grand réseau d‟ordinateurs compromis, utilisés pour créer et envoyer du
courrier indésirable, des virus ou pour saturer un réseau de messages dans
le cadre d‟une attaque par déni de service.
Completely Automated Public Turing test to tell Computers and Humans
Apart (test public de Turing complètement automatique ayant pour but de
différencier les humains des ordinateurs) - Test permettant de s‟assurer
qu‟une réponse n‟est pas générée par un ordinateur.
Métadonnée spécifiant comment encoder et/ou décoder un flux de données
numériques, notamment vidéo ou audio.
Cross-site request forgery
Common vulnerabilities exposure – base de données répertoriant les failles
de sécurité de notoriété publique
Domain Name System – service qui établit des corrélations entre les noms de
domaine ou d‟hôte, d‟une part, et les adresses IP, d‟autre part.
Document Object Model
Contaminations malveillantes – ne nécessitant ni intervention ni
connaissances humaines
Langage de script standardisé par Ecma International dans le cadre de la
spécification ECMA-262 – plus communément appelé «applications web»
End-user licence agreement – Accord de licence d‟utilisateur final
Terme décrivant le statut juridique d‟un fournisseur d‟accès internet qui
fournit uniquement des services de transfert de données sans intervenir dans
le contenu fourni (la nature même de l‟intervention est sujette à débat)
Friend of a Friend – ontologie lisible par un ordinateur, décrivant des
personnes, leurs activités et leurs rapports à d‟autres personnes et objets.
FOAF permet à des groupes d‟individus de décrire des réseaux sociaux sans
devoir recourir à une base de données centralisée.
Création et gestion collaboratives de balises en vue d‟annoter et de
cataloguer du contenu
Type de requête HTTP
Dans le contexte du présent document, partie d‟une URL précédant le nom
de domaine, p. ex. http://host.example.com
Hypertext transfer protocol
Abréviations et termes fréquemment employés
Web 2.0 Security and Privacy
IDE
Integrated Development Environment – logiciel utilisé pour assister le
développement
IFrame
Élément HTML permettant l‟intégration d‟un document HTML dans un autre
IRC
Internet relay chat
ISP
Fournisseur d‟accès internet
JSON
JavaScript Object Notation – format de transfert de données léger pour
Javascript
Logiciel malveillant installé sur un ordinateur sans l‟accord de son
propriétaire
Malware
Mashup
Application web combinant les données et les services de plusieurs sources
Microblog
Forme de blog présentant de courts messages d‟actualité ou des médias
comme des photos ou des clips audio
Représentation visuelle de balises générées par l‟utilisateur, servant à décrire
le contenu de sites web. L‟importance d‟une balise est définie par sa taille ou
sa couleur de police.
Nuage de motsclés
PKI
Public Key Infrastructure – Infrastructure à clé publique
Plug-in
Complément d‟un navigateur
PME
Petites et moyennes entreprises
POST
Type de requête HTTP utilisée pour envoyer des formulaires
QoS
Qualité de service
RDF
Resource Description Framework – format de métadonnées et de web
sémantique
RFID
Radio frequency identifier – balises d‟identification sans fil
Robot
Programme informatique s‟exécutant en toute autonomie, sans intervention
humaine, faisant partie d‟un botnet ou réseau de zombies
RS
Réseau social
RSS
Really Simple Syndication – format de syndication
Sandboxing
Suppression des fonctions de contrôle d‟un composant système pour bloquer
l‟accès au reste du système et éviter qu‟il ne soit vulnérable à l‟attaque de ce
composant
Terme décrivant le statut juridique d‟un fournisseur d‟accès internet qui
fournit uniquement des services de transfert de données sans intervenir dans
le contenu fourni (la nature même de l‟intervention est sujette à débat)
Simple
transporteur
SOP
Same-origin policy – politique de la même origine
SSL
Secure Sockets Layer – protocole d‟authentification et de chiffrement de
serveur
Acronyme employé pour désigner un format de fichier Flash – acronyme de
«Shockwave Flash»
SWF
Syndication
TLS
Publication de matériel à l‟intention d‟utilisateurs multiples d‟autre contenu –
couramment employée en association avec les flux RSS qui fournissent un
résumé du contenu nouvellement ajouté
Transport Layer Security – protocole d‟authentification et de chiffrement de
serveur – successeur du SSL
TOU
Terms of use – Conditions d‟utilisation
Widget
Application portable qui peut être installée et exécutée sur n‟importe quelle
page web distincte – les widgets prennent souvent la forme d‟outils
s‟affichant à l‟écran (horloges, cours de la Bourse, arrivées de vol, météo,
etc.)
Page ou ensemble de pages web qui permettent à quiconque y accède
d‟ajouter du contenu ou de le modifier, à l‟aide d‟un langage de balisage
simplifié
Wiki
xFolk
Format ouvert dédié à la publication de listes de favoris
XHR
XML Http Request – Fonction de script employée pour transférer, par voie
asynchrone, des données entre un serveur web et un navigateur à la requête
HTTP initiale dans laquelle elle est retournée
XML
Extensible Mark-up Language (spécification W3C)
XSS
Cross-site scripting (attaque)
8 Références et liens
Toutes les ressources web ont été vérifiées en novembre 2008.
1. ENISA Survey of end-user attitudes to security-related issues among Web 2.0 users.
http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_survey_web2.pdf
2. Scansafe Security Brief.
http://www.scansafe.com/threat_center/threat_alerts/stat_security_brief.
3. http://www.sophos.com/security/top-10/.
4. http://www.usenix.org/event/hotbots07/tech/full_papers/provos/provos.pdf.
5. IFrameDollars.biz. http://www.informationweek.com/news/security/vulnerabilities/
showArticle.jhtml?articleID=163700819.
6. Chicago Crime Mashup. http://chicago.everyblock.com/crime/.
7. Mint – internet banking aggregation. http://www.mint.com/.
8. Google Apps. http://www.google.com/a/help/intl/en/index.html.
9. Picasa Refresh Facial Recognition Software. http://www.techcrunch.com/2008/09/02/picasa-refresh-bringsfacial-recognition/.
10. ENISA. Security Issues and Recommendations for Online Social Networks. 2007.
http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_pp_social_networks.pdf.
11. Amazon Mechanical Turk Beta. http://www.mturk.com/.
12. Google‟s CAPTCHA busted in recent spammer tactics.
http://securitylabs.websense.com/content/Blogs/2919.aspx.
13. Spammers Using Porn to Break Captchas.
http://www.schneier.com/blog/archives/2007/11/spammers_using.html.
14. Keizer, G. New Bot-Powered eBay Scam Uncovered.
http://www.techweb.com/wire/security/showArticle.jhtml?articleID=191600603.
15. Twitter refuses to uphold terms of service. 5 2008. http://arielwaldman.com/2008/05/22/twitter-refusesto-uphold-terms-of-service/.
16. Roessler, Thomas. XDR API Security Impact, W3C mailing list post.
http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0068.html.
17. Gmail CSRF exploit. http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/.
18. The Confused Deputy. Hardy, Operating Systems Review, Vol 4, 22, 1988.
19. Shiflett, Chris. The Dangers of Cross-Domain Ajax with Flash. http://shiflett.org/blog/2006/sep/thedangers-of-cross-domain-ajax-with-flash
20. Phorm – online marketing tool. http://www.phorm.com/.
21. Mahemoff, M. Cross-Domain Communication with IFrames. 2008. http://softwareas.com/cross-domaincommunication-with-iframes.
22. (CVE), Common Vulnerabilities and Exposures. CVE-2008-1447 DNS Insufficient Socket Entropy
Vulnerability or the Kaminsky bug. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447.
23. Chris Karlof, J.D. Tygar, David Wagner, Umesh Shankar. Dynamic Pharming Attacks and Locked
Same-origin. 2007. http://www.cs.berkeley.edu/~daw/papers/pharming-ccs07.pdf.
24. Collin Jackson, Adam Barth. Beware of Finer-Grained Origins. Web 2.0
Security and Privacy (W2SP 2008). 2008.
http://crypto.stanford.edu/websec/origins/fgo.pdf.
25. Safer Internet, Protecting Our Children on the Internet using Content Filtering and Parental Control
Techniques. 2007. Page 8. The filtering solutions we benchmarked cannot sufficiently distinguish
innocent from harmful content in these highly dynamic environments. http://www.sipbench.eu/Reports2007/SIP%20Bench%202007%20%20Synthesis%20Report.pdf.
1. Widgets – Web Vulnerabilities for All. http://www.w3.org/2008/Talks/0425-devtrack-tlr/slides.pdf.
2. Web Application Security Issues. http://www.w3.org/2008/Talks/0424-w3ctrack-tlr/0424-w3ctrack-tlr.pdf.
3. 24C3 lightning talk (video). http://youtube.com/watch?v=G7wcfu367T4.
4. XSS Attack information. http://www.xssed.com/.
5.
„Privacy Policy – Third Party Advertising‟ – applying to Facebook Beacon (HTML). Retrieved on 2007-1204. http://www.facebook.com/policy.php.
6. Google web toolkit. http://code.google.com/webtoolkit/.
7. Direct Web Remoting – Client-Server AJAX Framework. http://directwebremoting.org/.
8.
ASP.NET AJAX. http://www.asp.net/ajax/.
9. Social Investing and Pump-and-Dump 2.0. http://www.jacksonfound.com/2008/04/01/social-investingand-pump-and-dump-20/.
10. Could Digg be used for Sun stock manipulation.
http://siliconvalleysleuth.co.uk/2006/03/digg_is_used_fo.html.
11. Welcome to the era of gullibility 2.0 – stocks tumble on Engadget blog post.
http://news.cnet.com/Welcome-to-the-era-of-gullibility-2.0/2100-1025_3-6185075.html.
12. Botnets – the siilent threat. http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_pp_botnets.pdf.
13. Use of Web 2.0 technologies to control botnets.
http://www.owasp.org/images/0/02/OWASP_Day_Belgium_2007-pdp.ppt.
14. With Web 2.0, a new breed of malware evolves.
http://www.computerworld.com.au/index.php/id;850210034.
15. ENISA. Reputation-based systems:a security analysis.
http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_pp_reputation_based_system.pdf.
16. Online Health Search 2006. http://www.pewinternet.org/pdfs/PIP_Online_Health_2006.pdf.
17. Wikiscanner. http://wikiscanner.virgil.gr/.
18. Web data and application security. http://www.cse.sc.edu/~farkas/csce813-2006/lectures/csce813lect30.ppt.
19. Jeremy J. Carroll, HP Labs, Bristol. Signing RDF Graphs. 2003.
http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf.
20. Winamp metadata vulnerability. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0065.
21. Microsoft Word‟s Hidden Tags Reveal Once-Anonymous Peer Reviewers. 2006.
http://chronicle.com/free/v52/i33/33a04101.htm.
47. Psst! Your Metadata Is Showing! Dark Reading.
http://www.darkreading.com/blog.asp?blog_sectionid=447&doc_id=145225.
48. Exposing Vulnerabilities in Web Software. Thiel, David. Amsterdam: s.n. BlackHat Europe
2008. http://www.blackhat.com/presentations/bh-europe-08/Thiel/Whitepaper/bh-eu-08thiel-WP.pdf.
49. Convention européenne des droits de l‟homme (article 8 sur le respect de la vie privée).
http://conventions.coe.int/treaty/fr/Treaties/Html/005.htm.
50. Directive 95/46/EC du Parlement européen et du Conseil du 24 octobre 1995 relative à la
protection des personnes physiques à l‟égard du traitement des données à caractère personnel et à la libre
circulation de ces données. http://ec.europa.eu/justice_home/fsj/privacy/law/index_fr.htm.
51. Groupe de travail « Article 29 ». Avis 4/2007 sur le concept de données à caractère personnel. 06 2007.
http://ec.europa.eu/justice_home/fsj/privacy/docs/wpdocs/2007/wp136_fr.pdf.
52. ENISA. The new users‟ guide: How to raise information security awareness.
http://www.enisa.europa.eu/doc/pdf/deliverables/new_ar_users_guide.pdf.
53. The Emperor’s New Security Indicators. Stuart E. Schechter, Rachna Dhamija, Andy Ozment, Ian
Fischer. 2007. IEEE Symposium on Security and Privacy.
54. Yahoo‟s CAPTCHA Security Reportedly Broken.
http://www.darkreading.com/document.asp?doc_id=143620.
55. Spammers crack Gmail Captcha. http://www.theregister.co.uk/2008/02/25/gmail_captcha_crack/.
56. Friendbot – automation tool for creating myspace friends. http://www.friendbot.com/.
57. Roelof Temmingh, Chris Böhme. investigating individuals and organisations using open source
intelligence. http://www.blackhat.com/presentations/bh-europe-08/Temmingh-Bohme/ Presentation/bh-eu08-temmingh-bohme.pdf.
58. Fried, Ina. Warning sounded over „flirting robots”. CNET news. 2007. http://news.cnet.com/830113860_3-9831133-56.html.
59. Russian Computer Program fakes chat room flirting. ABC News.
http://www.abc.net.au/news/stories/2007/12/13/2118477.htm.
60. Solving Captchas for Cash. http://ha.ckers.org/blog/20070427/solving-captchas-for-cash/.
61. Sid Stamm, Zulfikar Ramzan, Markus Jakobsson. Drive-by pharming report. Symantec.
http://www.symantec.com/avcenter/reference/Driveby_Pharming.pdf.
62. Online port scanner – note this has not been tested by the group.
https://www.grc.com/x/ne.dll?bh0bkyd2.
63. Symantec Threat Report, Volume XIII. 2007.
http://www.symantec.com/business/theme.jsp?themeid=threatreport.
64. Grossman, J. Advanced Web Attack Techniques using GMail. 2006.
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html.
65. CVE-2008-1318 JSON based attack on mediawiki. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE2008-1318.
66. Report, ENISA. Information Security Certifications.
http://www.enisa.europa.eu/doc/pdf/deliverables/inf_sec_certification_2008.pdf.
67. EU Stork Project: Large-scale eID pilots. http://www.eid-stork.eu/.
68. Explanation of Web of Trust. http://en.wikipedia.org/wiki/Web_of_trust.
69. http://news.cnet.com/8301-13578_3-10040152-38.html.
70. Caja – capabilities javascript. http://code.google.com/p/google-caja/.
71. The new users‟ guide: How to raise information security awareness.
http://www.enisa.europa.eu/doc/pdf/deliverables/new_ar_users_guide.pdf.
72. Get Safe Online Guidelines. Safe Social Networking.
http://www.getsafeonline.org/nqcontent.cfm?a_id=1459.
73. Yahoo. Yahoo Employee Blogging Guidelines. http://jeremy.zawodny.com/yahoo/yahoo-blogguidelines.pdf.
74. Privacy and Identity Management for Europe, Tutorials. https://www.primeproject.eu/prime_products/reports/tuto/.
75. Access Control for Cross-Site Requests – W3C Specification. http://dev.w3.org/2006/waf/access-control/.
76. XACML – eXtensible Access Control Markup Language (OASIS). http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml.
77. oAuth specification. 12 2007. http://oauth.net/core/1.0/.
78. Open ID. http://openid.net/.
79. Introducing Windows Cardspace. http://msdn.microsoft.com/en-us/library/aa480189.aspx.
80. Liberty Alliance. http://www.projectliberty.org/.
81. HTML 5, W3C Draft. http://dev.w3.org/html5/spec/Overview.html.
82. Web Security Context: User Interface Guidelines – W3C Working Draft. 07 2008.
http://www.w3.org/TR/wsc-ui/.
83. The EU Provenance Project. http://www.gridprovenance.org/theproject.html.
84. The OWASP Guide to Building Secure Web Applications v2.
http://www.owasp.org/index.php/Category:OWASP_Guide_Project.
85. Learn to Work Safely with Web 2.0. http://career-resources.dice.com/jobtechnology/learn_to_work_safely_with_web_2_0.shtml.
86. ComputerWorld: Security Survival Tips for the Web 2.0 World.
http://www.computerworld.com/action/article.do?command=viewArticleTOC&articleId=
285367&specialReportId=9000283&intsrc=article_sp_feat_bot.
1.
Credentica website. http://www.credentica.com/technology.html.
2.
Idemix website. http://www.zurich.ibm.com/security/idemix/.
3. EU Prime Project (Privacy and Identity Management for Europe). https://www.prime-project.eu/.
. ...................