Les cookies, vrais ou faux amis ?

Qui sont les cookies ?

Le cookie est un fichier texte (combinaison de chiffres et de lettres d’une taille maximale de 4 KB) déposé par un service web sur l’appareil – smartphone, tablette ou PC – de l’utilisateur. Ces informations permettent de reconnaître l’utilisateur au-delà d’une première visite ainsi que ses paramètres. Il existe de nombreuses catégories de cookies. Par exemple, certains cookies sont strictement nécessaires au bon fonctionnement d’une page web (ex. load balancing, session de l’utilisateur ou facilitation du shopping en ligne lors de l’ouverture de plusieurs sessions) ou permettent de produire des statistiques, dans ce cas, leur usage relève de l’intérêt légitime du responsable de traitement et ne nécessite donc pas la collecte d’un consentement (cf. délibération de la CNIL du 4 juillet 2019 relative à l’utilisation des cookies et traceurs). D’autres cookies ont pour objectif de mieux connaître l’utilisateur via l’analyse de sa navigation ou de ses habitudes de consommation. Ils nécessitent alors le recueil d’un consentement de la part de l’utilisateur dans la mesure où leur absence n’altère en rien le bon fonctionnement du site. Ces derniers – et plus particulièrement les « cookies tiers » ou « cookies de suivi » – interrogent quant au respect de la vie privée dans la mesure où ils permettent de suivre la navigation d’un utilisateur lors de ses visites de différents sites web, une activité également connue sous le terme « tracking », qui permet de déduire des habitudes et de modes de vie des utilisateurs plus ou moins intrusives (centres d’intérêt, habitudes de consommation, lieux de vie ou mobilité, fréquentation de centre de soin, opinion politique, orientation sexuelle, sensibilité religieuse, etc.).

Ainsi, la CNIL distingue les catégories de cookies suivantes :

Attention, certains cookies de mesures d’audience peuvent être exemptés de consentement en fonction du choix et du paramétrage de la solution de mesure d’audience associée. Pour plus d’information sur les solutions de mesures d’audience nécessitant ou pas le consentement, se référer ici.

Les cookies comme réponse à des enjeux métiers dans un environnement concurrentiel

Si ces outils sont si utilisés aujourd’hui, c’est d’abord et avant tout parce qu’ils répondent à des besoins métiers, notamment pour les directions marketing/commerciales ou de la communication. D’une part, ils permettent d’offrir une expérience personnalisée en définissant ou en associant un « profil utilisateur » à leurs clients ou prospects. Pour que les campagnes marketing soient plus précises (mieux ciblées) ou pour toucher un plus grand nombre de personnes susceptibles d’être intéressées par le produit / service, ces entreprises ont souvent besoin d’enrichir leurs bases avec des cookies tiers et des segments marketing. Pour cela, elles s’appuient sur des prestations « clé en main » fournies par des régies publicitaires dont l’un des métiers est de vendre d’immenses bases de données de cookies (Criteo, RelevanC).

De manière générale on observe que les organisations qui utilisent ces cookies ont mis en place des outils permettant à l’utilisateur de décider lui-même s’il souhaite les accepter ou non en fonction de leurs finalités. Mais certaines pratiques sont loin d’être totalement transparentes…

Le pixel invisible ou espion, une technologie méconnue de l’utilisateur

Qu’est-ce qu’un pixel ?

Le pixel invisible (ou espion) est parfois utilisé comme une alternative au cookie dans la mesure où son usage ne peut techniquement pas être bloqué par un navigateur. Il s’agit d’un graphique (1×1 pixel) qui est téléchargé lors de la consultation d’une page web ou lors de l’ouverture d’un email. Ce pixel est généralement masqué ou si petit qu’il est impossible à voir. Sa fonction est de collecter des informations sur l’utilisateur (adresse IP, type d’appareil, version du navigateur, résolution d’écran, etc.)[1] ou de permettre le dépôt d’un cookies tiers permettant de renvoyer ces informations à un serveur.

Si la plupart des sites mentionnent l’utilisation de pixels et permettent à l’utilisateur de gérer ses préférences, la très grande majorité utilisateurs ignorent à quoi ils servent. De plus, il arrive que ces pixels soient présents dans le contenu d’emails sans que le(s) destinataire(s) n’en soit informé(s). Non visibles et encore très peu soumis au recueil du consentement, le pixel continue enregistre quantité de données à caractère personnel pouvant porter atteinte à la vie privée du destinataire. Que dit la réglementation et jusqu’où s’applique-t-elle ?

[1] L’ajout d’un script Javascript permet de recueillir des informations complémentaires à propos de l’utilisateur qui en est très rarement informé (ex. système d’exploitation, localisation approximative, etc.).

Le RGPD définit des obligations claires à respecter

Les données à caractère personnel collectées et traitées par les traceurs qui peuvent ensuite être utilisées pour en déduire des habitudes et de modes de vie des utilisateurs sont soumises au RGPD qui définit des exigences claires quant à leur utilisation. Préalablement au dépôt de cookies ou traceurs sur des terminaux, les acteurs du numérique doivent respecter, entre autres, les obligations suivantes sous peine de ne pas être en conformité :

1. Informer l’utilisateur de la mise en œuvre de traceurs et cookies utilisés et leur(s) finalité(s) précise(s) dans un bandeau rédigé en des termes simples et compréhensibles
2. Recueillir le consentement de l’utilisateur ou de lui fournir la possibilité de s’y opposer (nb. ce consentement est valable 13 mois maximum)
3. Respecter l’activation par l’utilisateur du paramètre DoNotTrack offert par certaines récentes versions de navigateurs

Attention : jusqu’en juillet 2019, la CNIL considérait que la poursuite de la navigation vallait accord au dépôt de Cookies sur le terminal utilisateur. Cette pratique, qualifiée de « soft opt-in » a depuis été révisée par CNIL (voir ici).

En conclusion, des efforts restent à réaliser pour aller vers plus de transparence et de pédagogie vis-à-vis des utilisateurs pour qu’ils puissent choisir de faire l’objet d’une navigation personnalisée respectueuse de la vie privée.

Un an après l’entrée en application du RGPD, les traceurs – incluant les cookies et les pixels – sont généralement bien gérés par les entreprises lors de la navigation web. En effet, la plupart des sites mettent à disposition des utilisateurs un bandeau d’information, une politique relative à l’utilisation des données à caractère personnel et un outil de gestion des cookies, incluant les pixels, pour que l’utilisateur puisse gérer ses préférences (opt-out lorsque le consentement n’est pas nécessaire) et consentements sur ces sites. Néanmoins, l’information relative à l’usage de ces traceurs à des fins de traitement marketing (ciblage, profilage) ne fait pas toujours la distinction entre les cookies et les pixels, ce qui ne permet pas l’information claire et transparente de l’utilisateur. Pour finir, l’information quant à l’utilisation de pixels dans les emails est presque inexistante (ou alors accessible après plusieurs clics !) ne permettant pas d’assurer la transparence envers les destinataires. Bien qu’elles ne permettent pas d’endiguer le dépôt de traceurs, des solutions telles que l’effacement régulier de l’historique de navigation ou de moteur de recherche ou telles que l’installation d’extensions (ex.  NoScript, Ghostery, Adblock Plus et bien d’autres encore pour la navigation, PixelBlock, Ugly Email pour la messagerie) peuvent être mises en œuvre par les utilisateurs pour limiter la collecte de leurs données à caractère personnel.

Cet article Traceurs et vie privée : quels efforts à faire pour une navigation respectueuse de la vie privée ? est apparu en premier sur RiskInsight.

« Va parler à la maitresse si quelqu’un t’embête à l’école », « Je ne te louerai pas ce DVD, ce film est trop violent pour toi » ou encore le classique « Surtout, ne suis pas un inconnu, même s’il t’offre des bonbons ». On a tous encore en tête, même après des décennies, les conseils de nos parents concernant notre sécurité dans la vie de tous les jours. Mais avec une utilisation de plus en plus précoce d’Internet par les enfants, cette vie de tous les jours s’est maintenant étendue à la toile. Il est donc devenu impératif de sensibiliser les plus jeunes aux risques auxquels ils s’exposent en surfant sur le web pour qu’ils puissent en tirer tous les bénéfices !

L’éducation aux risques numérique, une nécessité

C’est la mission que se donne ISSA France sous le patronage du secrétariat d’état chargé du numérique avec son cahier de vacances « Les As du Web ». Et le besoin est là : selon un récent sondage IPSOS, plus d’un tiers des jeunes interrogés (entre 9 et 17 ans) ne protègent en rien les informations personnelles qu’ils mettent en ligne. Plus inquiétant, un cinquième de ces enfants pourrait envisager de donner rendez-vous à un étranger rencontré sur Internet, et 10% discutent d’ailleurs régulièrement avec de parfaits inconnus.

La sensibilisation de cette population à ces dangers est d’autant plus importante que l’autorité parentale ne suffit pas toujours : ils sont 65% à déclarer ne pas respecter au moins une règle de conduite édictée par leurs parents… Ces derniers ne sont d’ailleurs pas toujours très au courant eux-mêmes des dangers de la toile.

Sensibiliser les enfants, et par transitivité des parents, est donc un enjeu qui a déjà fait l’objet d’initiatives, avec notamment la création du Permis Internet par le Ministère de l’Intérieur. La publication de ce cahier de vacances « Les As du Web » est une étape supplémentaire dans l’intégration du numérique au sein de l’éducation des jeunes générations.

Comment parler simplement d’un sujet complexe

Pour autant, aborder une thématique technologique avec un public aussi particulier peut relever d’une véritable gageure, et ce d’autant plus qu’ISSA France a choisi de s’adresser aux 7 – 11 ans. Cibler cette tranche d’âge tombe sous le sens car c’est l’âge auquel ces internautes en herbe accèdent à Internet et sont les plus vulnérables.

Le premier challenge est donc d’arriver à isoler les sujets à aborder dans l’ouvrage. Ils doivent traiter les grands risques auxquels les enfants seront exposés de la manière la plus didactique et rassurante possible. Le choix d’un cahier de vacances, avec ses jeux et son graphisme ludique répond à cet objectif. Ensuite, il s’agit de trouver les bons mots. Le monde du numérique est truffé d’anglicismes et utilise un vocabulaire très particulier qu’il faut simplifier et expliquer si besoin au jeune lecteur afin de faciliter sa compréhension.

Les grands thèmes du petit cahier

Le cahier de vacances « Les As du Web » aborde donc dans un ouvrage ludique et pédagogique d’une vingtaine de pages les six thématiques suivantes :

• Qui se cache derrière ton écran ? Et pour quoi faire ? Pour bien expliquer que l’on peut facilement masquer son identité et prétendre être celui que l’on n’est pas.
• Tes données personnelles : apprends à les reconnaitre et protège-les ! Pour montrer la valeur de ses données et les enjeux à long terme.
• Le monde numérique n’est pas que pour les enfants. Ne t’y promène pas seul. Pour démontrer que le web n’est finalement pas si différent du monde « réel ».
• Le cyberharcèlement : c’est grave ! Cette partie donne les bons réflexes sur comment réagir lorsque l’on est visé ou témoin ?
• Internet ne dit pas toujours la vérité. Gare aux mensonges pour ne pas les répéter. Important en ces temps-de « fake news ».
• Sur Internet, reste cool et toi-même. Afin de démystifier et donner les bons réflexes de posture.

De la page web aux enfants, il reste du chemin à parcourir

Le projet est maintenant arrivé au bout de sa première phase : la création du contenu. Wavestone est d’ailleurs très heureux d’y avoir, avec d’autres, participé. Mais cette première étape ne constitue que 10% du chemin car tout l’enjeu maintenant est de faire que ce contenu atteigne sa cible !

Pour se donner les moyens d’y arriver, ISSA France souhaite imprimer un million de copies papier d’ici cet été. Car si pour le moment, le cahier n’est disponible qu’en ligne, l’association souhaite en effet placer de nombreux exemplaires physiques à des endroits stratégiques, comme les gares, les aéroports ou les aires d’autoroute lors des départs en vacances. Et c’est là que vous pouvez aider et participer au succès de cette initiative. A votre échelle en partageant autour de vous le cahier de vacances mais aussi à l’échelle de votre entreprise, puisqu’ISSA France est toujours à la recherche de partenaires pour participer à la diffusion de cet ouvrage et lui permettre d’atteindre sa cible.

Cet article Les As du Web : Participez à l’initiative de sensibilisation des 7-11 ans aux risques du web est apparu en premier sur RiskInsight.

Une évolution dans les technologies et les usages de l’Internet

Du côté des utilisateurs, les usages apparus dans la dernière décennie ne feront que se confirmer et s’amplifier à l’horizon 2020. La croissance et la diversification des réseaux sociaux permettra d’accélérer encore le partage de données personnelles avec une hausse des performances techniques et du nombre d’utilisateurs. Ce phénomène, profondément générationnel, pourrait poursuivre son développement et soulever avec lui de nombreuses questions relatives à la confiance en l’information et aux limites de la liberté d’expression.

Du côté des entreprises, dans la continuité de la virtualisation du poste de travail, le télétravail devient un thème dans les feuilles de route stratégiques de nombreux groupes qui y voient une opportunité de réduire les charges de l’immobilier qui constituent ordinairement leur second poste de dépenses. Le Cloud Computing se renforce et permet l’intégration de parts toujours plus vastes du capital informationnel des entreprises par des prestataires spécialisées, notamment dans la sécurité des infrastructures.

Enfin, l’IoT et le Machine Learning provoqueront un bouleversement important des business models et du positionnement des acteurs historiques dans tous les secteurs. 3 nouveaux besoins de société devront impérativement être pris en compte pour être compétitif : la mobilité, la connaissance et la confiance.

Un cadre reglementaire encore a definir

Les récentes démonstrations de puissance des GAFA, capables d’associer des bases de données d’utilisateurs gigantesques à des méthodes d’intelligence artificielle de pointe, initient une nouvelle ère consacrée à l’ultra-personnalisation des services mais aussi à la surveillance de masse. En effet, les immenses opportunités ouvertes dans le champ du marketing par le biais de l’ultra-personnalisation des services et la surveillance de masse cachent une réalité préoccupante : un cadre législatif qui protège très imparfaitement les internautes face aux utilisations abusives et discriminantes d’acteurs publics comme privés.

Dans ce contexte, les « lois renseignement » émergent dans de nombreux pays occidentaux afin de poser un cadre normatif à des pratiques déjà courantes de ces services. Posant la question de libertés individuelles menacées sous le prétexte de lutte antiterroriste, ces textes sont régulièrement adoptés en dépit de fortes protestations de la société civile.

Après plusieurs révélations sur les activités de la NSA en Europe, l’Union Européenne décidait d’invalider en octobre 2015 le Safe Harbour qui permettait jusque-là aux Etats-Unis et à l’Europe d’échanger librement leurs données considérant que son partenaire outre-Atlantique n’était plus en mesure de garantir à ces données un niveau de protection suffisant ou adéquate. Afin de combler le vide juridique entourant l’usage des données personnelles, le GDPR constitue le nouveau texte de référence pour la protection des données à caractère personnel en Europe, applicable par les 28 états de la zone à partir du printemps 2018. Ce texte protègera en effet les utilisateurs au détriment des entreprises qui verront leurs possibilités restreintes a minima à un impératif de consentement « explicite et positif ». De même, la directive européenne NIS, pour la sécurité des services numériques, sera progressivement traduite dans les juridictions nationales, notamment en France en lien avec la loi de programmation militaire.

Finalement, les récents bras de fer entre les géants du web et l’administration américaine ont prouvé l’incapacité du gouvernement à imposer à Apple et Google l’application du Patriot Act. Cela a permis à ces acteurs d’affirmer une primauté du respect des libertés individuelles et une certaine autonomie face aux organes politiques, jusqu’ici seuls maitres à bord dans ce type de situation. Une évolution décisive des rapports de force historiques s’amorce doucement avec la mise en retrait des autorités étatiques face aux acteurs majeurs de l’économie et il est encore difficile aujourd’hui de savoir où cette évolution nous mènera.

Ainsi, deux compétences seront déterminantes d’ici 2020 et même après pour s’adapter à l’époque technologique, innover et survivre à l’évolution rapide des règles de la concurrence : une grande maitrise des limites et contraintes réglementaires, d’une part, et une capacité à tirer le meilleur des données à disposition, sans sortir d’un cadre légal autorisé et évolutif. Tout l’enjeu d’un futur environnement basé sur le web 3.0 sera donc de construire et sauvegarder une relation de confiance mutuelle avec les clients comme avec les parties-prenantes, notamment étatiques.

De nouvelles menaces dans le cyberespace

Dans le cadre d’une analyse prospective visant à établir les évolutions de la cybercriminalité à horizon 2020, un comité d’expert s’est prononcé sur les typologies de menaces attendues de manière récurrentes envers les entreprises privées et les individus. Ainsi, les entreprises auraient à craindre en priorité les atteintes à la disponibilité de leurs systèmes, telles des dénis de service, les vols de données stratégiques motivés par la mise en concurrence et des attaques visant l’image de la société (compagnes de désinformation et de diffamation). Du côté des individus, les escroqueries et les détournements sont les menaces les plus importantes à considérer et auxquelles s’ajouteraient les attaques visant les systèmes d’alarmes et domotiques en soutien à des intrusions physiques.

Deux scénarios se démocratiseront et s’entre-alimenteront pour décrire un paysage d’ensemble de la menace en 2020 :

• L’attaque « as a service » : La croissance rapide et continue du nombre de connexions sur le Web entraînera mathématiquement l’ouverture d’une très large surface d’attaque. Les attaques non ciblées ou basées sur des réseaux de machines esclaves (machines contrôlées à distance par un attaquant et utilisées en grand nombre pour saturer des services web, par exemple) pourront ainsi se déployer de manière massive et gagner une force de frappe dont on peine à imaginer les limites à l’heure actuelle. Une étude d’universitaires israéliens estimait que 6 000 smartphones sont suffisants pour venir à bout d’un système d’appel d’urgence du type 911 aux États-Unis ; que ne pourrait-on pas faire avec un réseau de millions, voire de milliards, d’objets infectés par des Botnet malwares (logiciels malveillants permettant à un hacker de contrôler à distance les machines infectées) ? Ces attaques, de faible complexité mais à l’impact massif.
• La guerre économique : Un contexte de compétition exacerbée entre les acteurs économiques majeurs des pays industrialisés aboutira à un renforcement des menaces « géostratégiques ». L’Internet deviendra un nouveau terrain de conflit sur lequel se joueront les intérêts économiques et politiques des Nations. Les menaces seront ciblées et iront des actions de sabotage, comme ce fut le cas avec le virus Stuxnet, à l’espionnage industriel. Ces offensives pourront atteindre de hauts niveaux de complexité et seront mis en œuvre par des équipes de professionnels bénéficiant de protections diverses et de ressources financières et opérationnelles importantes voire illimitées.

Avec la généralisation du Cloud Computing et des objets connectés, les usages « digitaux » qui émergent aujourd’hui se conforteront largement à horizon 2020. En lien avec cette évolution, de nouvelles menaces, moins ciblées pour les entreprises et les individus et plus ciblées pour les états, sont attendues. Le cadre législatif, fortement évolutif, vise aujourd’hui autant à protéger les internautes, qu’à soutenir les entreprises et l’issue des rapports de force est incertaine.

Cet article Quelle sécurité pour le cyberespace en 2020 ? est apparu en premier sur RiskInsight.

HTTPS ou le règne de “la confiance aveugle”

Lorsqu’un utilisateur se connecte à un site internet via le protocole chiffré HTTPS, c’est le protocole SSL (Secure Socket Layer) qui se charge du chiffrement. Pour ce faire, des mécanismes de cryptographie asymétrique sont employés.

Le navigateur web de l’utilisateur va tenter de vérifier l’identité du serveur auquel il se connecte. Pour cela, le serveur présente au navigateur un certificat X.509, contenant notamment sa clé publique et une signature. Le navigateur va alors vérifier la validité de la signature, puis utiliser la clé publique afin d’échanger une clé de session qui sera utilisée pour chiffrer l’ensemble des communications de manière symétrique.

Le navigateur vérifie ensuite la validité de la signature en s’assurant de l’existence d’une chaîne de confiance (chain of trust) entre le certificat et l’une des autorités de certification de confiance. Qui sont ces autorités de confiance ? C’est en tentant de répondre à cette question que l’on réalise la fragilité du système actuel.

Pour que le navigateur accepte la connexion, il va remonter la chaîne de confiance jusqu’à l’autorité de confiance racine et s’assurer que celle-ci est présente dans le magasin de certificats.

Le navigateur Firefox, par exemple, dispose de son propre magasin de certificats auxquels il fait confiance. D’autres, comme Internet Explorer ou Chrome, se basent sur le magasin de certificats du système d’exploitation.

Et par défaut, ces magasins regorgent d’autorités de certification, de tous pays ! Le navigateur Firefox en compte plus d’une centaine.

Il suffit donc qu’une seule de ces autorités de certification délivre, par erreur ou plus vraisemblablement suite à une attaque, un certificat valide pour “*.google.com” pour que des attaquants puissent mener une attaque de type Man-in-the-Middle. En se faisant passer pour un serveur légitime de Google, ils pourront intercepter et déchiffrer les échanges entre le navigateur et le serveur… Cette menace ne relève malheureusement pas du domaine de la science-fiction, comme le prouve l’exemple de Diginotar en 2010.

De plus, dans le cas d’échanges d’informations stratégiques, la menace étatique doit être prise en compte. Que se passerait-il si le gouvernement d’un pays demandait à l’une des autorités de certification de ce pays, faisant partie de la liste des autorités de confiance racine de Firefox, de signer un certificat valide pour mail.google.com ? Cette société serait-elle en position de refuser, ou de communiquer à ce sujet ? La réponse est, sans doute, non ; dans ce cas, le navigateur accepterait le vrai-faux certificat et n’afficherait aucune alerte à l’utilisateur.

Limiter la confiance dans les autorités de certification

Afin de se prémunir des deux scénarios envisagés, il est possible d’utiliser le protocole SSL d’une autre façon, en créant une association entre le nom de domaine d’un site (www.google.com) et le certificat ou l’autorité de certification attendus. Ainsi, seul le certificat attendu ou un certificat signé par l’une des autorités de certification attendues sera accepté et une alerte sera levée si un autre est présenté.

Il est alors nécessaire de disposer d’un référentiel de ces associations (site internet / certificat) valides, ou de le construire au fur et à mesure de la navigation sur les sites. Malheureusement, ce type de mécanisme n’est pas réellement pris en compte par les navigateurs. Il peut cependant se faire au moyen de modules additionnels, comme Certificate Patrol pour Firefox.

Google Chrome réalise déjà une validation de ce type, pour un nombre limité de sites. Le fichier qui contient la liste blanche des sites pour lesquels HSTS est activé par défaut contient également la liste des sites pour lesquels le pinning est activé :

{
   "pinsets": [
 […]
     {
       "name": "google",
       "static_spki_hashes": [
         "VeriSignClass3",
         "VeriSignClass3_G3",
         "Google1024",
         "Google2048",
         "GoogleBackup1024",
         "GoogleBackup2048",
         "EquifaxSecureCA",
         "GeoTrustGlobal"
       ],
       "bad_static_spki_hashes": [
         "Aetna",
         "Intel",
         "TCTrustCenter",
         "Vodafone"
       ]
     },

[…]

"entries": [
     // Dummy entry to test certificate pinning.
     { "name": "pinningtest.appspot.com", "include_subdomains": true, "pins": "test" },

     // (*.)google.com, if using SSL, must use an acceptable certificate.
     { "name": "google.com", "include_subdomains": true, "pins": "google" },

Extrait du fichier transport_security_state_static.json

Google Chrome va donc vérifier, lors de la connexion à un site du type “google.com”, que le certificat est valide et qu’il est signé par une des autorités de certification autorisées. Il semblerait de plus que cette information soit remontée aux serveurs de Google : c’est ainsi qu’a pu être découvert et rendu publique le cas du certificat intermédiaire distribué par Turktrust.

L’utilisation du pinning est la plupart du temps observée dans le cas d’applications mobiles, puisqu’il est alors facile pour le développeur d’inclure le certificat attendu dans le paquet de l’application. Pour les navigateurs internet, seul le recours aux modules additionnels est possible, à moins de modifier le fichier source en extrait ci-dessus et de recompiler, ce qui n’est sans doute pas la solution la plus simple.

L’OWASP a récemment publié une cheatsheet, ainsi qu’un article plus détaillé, sur la mise en œuvre technique du pinning, notamment dans le contexte du développement d’applications mobiles.

Bien que difficile à généraliser, l’utilisation du pinning semble une évolution logique pour répondre aux risques liés aux hiérarchies de confiance. Cette initiative est à conseiller pour les systèmes bien maîtrisés, comme les applications mobiles et les VPN.

Pour le déploiement dans les navigateurs internet, il faudra malheureusement attendre que les principaux acteurs intègrent cette fonctionnalité. On pourrait imaginer, dans un contexte professionnel, pouvoir indiquer au navigateur de n’accepter que les certificats issus de la PKI interne pour les sites d’entreprise.

Cet article Épinglez vos certificats ! est apparu en premier sur RiskInsight.

Pourquoi a-t-on besoin de HSTS ?

Malheureusement, l’utilisation de HTTPS n’est souvent pas exclusive, ouvrant la voie à trois types de menaces :

• Attaques réseau passives sur des flux non-chiffrés

Il arrive fréquemment que seule une partie des requêtes au serveur web soient chiffrées, par exemple l’authentification. Une fois authentifié, les requêtes suivantes sont en clair. Un attaquant capable d’intercepter les flux réseau (sur un Wifi ouvert, au Starbucks, par exemple), pourra alors analyser les requêtes non-chiffrées, qui contiennent les cookies de session de l’utilisateur. Il pourra ainsi usurper son identité.

• Attaques réseau actives pour détourner le trafic et l’intercepter

Il n’est pas rare de rencontrer des sites proposant une connexion sécurisée mais également une connexion HTTP traditionnelle. Il est alors possible, pour un attaquant capable d’intercepter les flux réseau, de modifier à la volée les données envoyées par le site et de remplacer les liens « https://www.site.com » par des liens vers la version en clair « http://www.site.com ». Des outils permettent d’automatiser cette tâche, comme sslstrip : à nouveau l’attaquant pourra intercepter les cookies et usurper l’identité de la victime. L’attaquant pourrait aussi bien tenter de faire accepter à l’utilisateur un certificat invalide, afin de pouvoir déchiffrer les échanges SSL à la volée.

• Erreurs de développement

Il est également possible que, volontairement ou non, certaines requêtes soient effectuées en clair, par exemple pour charger des images ou un contenu vidéo. Si les images sont hébergées sur le même serveur, les cookies seront envoyés avec la requête et là encore, l’attaquant pourra dérober les cookies et usurper l’identité de la victime.

La solution proposée par HSTS : forcer l’utilisation de HTTPS

HSTS se propose de parer à ce type d’attaques en permettant aux sites web d’indiquer au navigateur qu’il ne doit accepter d’ouvrir que des liens HTTPS vers ce site.

Pour cela, un en-tête HTTP spécifique doit être envoyé au navigateur, qui n’acceptera alors que des liens https:// pour le site en question, et ce pour un temps donné.

De plus, si une erreur de validation de certificat survenait, le navigateur refuserait d’ouvrir la page en question ; en cas d’utilisation de HSTS, l’utilisateur n’a plus la possibilité de passer outre un message d’erreur de validation du certificat : voilà une avancée judicieuse ! HSTS permet donc un premier niveau de protection contre les attaques de type Man-in-the-middle (homme du milieu).

Implémenter HSTS en ajoutant les bons en-têtes

La syntaxe de l’en-tête HTTP est la suivante :

Strict-Transport-Security: max-age=XXX; includeSubDomains

Où :

• Strict-Transport-Security : indique l’utilisation de HSTS
• max-age= : définit la période durant laquelle le navigateur doit forcer l’utilisation de HTTPS, en secondes
• includeSubdomains : permet d’indiquer que la politique s’applique également à l’ensemble des sous-domaines ; cette directive est optionnelle

Dans le cas d’un serveur web Apache, il convient d’insérer les commandes suivantes dans la configuration du site :

Header set Strict-Transport-Security "max-age=XXX"

Header append Strict-Transport-Security includeSubDomains

Il est également conseillé de paramétrer la directive « max-age » de manière dynamique, de façon à la faire coïncider avec la date d’expiration du certificat

HSTS recommande également l’utilisation d’une liste prédéfinie de domaine HSTS par les navigateurs (comme Gmail, Facebook, etc …). Ainsi, on couvre le risque de la première connexion non-chiffrée.

Il est important de noter que les en-têtes HSTS ne sont pris en compte par les navigateurs que si le certificat présenté par le site est signé par une autorité de certification racine présente dans le magasin de certificats, excluant de fait le cas des certificats auto-signés.

Tous les navigateurs sont-ils compatibles HSTS ?

Les mécanismes HSTS sont supportés depuis plusieurs années par Chrome, Firefox et Opéra, qui intègrent désormais une liste par défaut de sites HSTS.

En revanche, les navigateurs Internet Explorer de Microsoft et Safari d’Apple sont à la traîne et n’implémentent pas encore ces protections.

HSTS apporte donc une avancée significative dans la sécurisation des échanges sur Internet, et ce de manière transparente pour le grand public. En imposant la sécurité (en ne leur proposant pas d’accepter un certificat invalide), on se prémunit d’un maillon faible, l’utilisateur, qui peut permettre la réalisation d’attaques de type man-in-the-middle comme ce fut récemment le cas pour le site Github en Chine.

Cependant, d’autres menaces subsistent : on pense notamment aux fréquentes faiblesses dans le choix des protocoles et algorithmes de chiffrement. De plus, la problématique des autorités de certification, qui sont garantes des identités sur internet, reste ouverte, comme le rappellent les cas de Diginotar ou plus récemment de Turktrust.

La sécurisation des échanges sur internet reste une problématique qui requiert de l’expertise dans son implémentation, ainsi que des contrôles réguliers pour assurer la confidentialité et l’intégrité des données échangées vis-à-vis des nouvelles menaces.

Cet article HTTP Strict Transport Policy, une avancée dans la sécurisation des échanges sur Internet ? est apparu en premier sur RiskInsight.

Comment se fait-on clickjacker ?

Pour mener une attaque par clickjacking, un attaquant va procéder de la manière suivante :

1- Il identifie sa cible, une page non-protégée contre ce type d’attaque, qui permet de réaliser une action en cliquant sur un lien ou un bouton.

2- Il intègre cette page dans une page malveillante qu’il maîtrise

3- Il s’arrange pour que, lorsque la victime clique sur un élément de la page, elle clique en réalité sur un bouton ou un lien provenant du site vulnérable

Par exemple, il peut utiliser les propriétés de style offerte par HTML/CSS pour rendre transparente la page vulnérable. Dans l’exemple ci-dessus, l’utilisateur verra le bouton « Jouer ! » mais cliquera en réalité sur le « Bouton 1 », provenant d’un site différent !

Les exemples les plus fréquents d’attaque par clickjacking sont les “likejacking” et “tweetbomb”. La première, ciblant le réseau social, a pour objectif de faire « liker » une page, c’est-à-dire d’augmenter sa popularité. La seconde vise à diffuser sur Twitter un message, la plupart du temps publicitaire.

Les risques se limitent-ils aux réseaux sociaux ?

Mais non ! Il est important de noter que les enjeux liés à ce type d’attaques ne s’arrêtent pas à la pollution de réseaux sociaux. De même que les attaques par rejeu de requête (XSRF),  les attaques par clickjacking permettent d’exécuter des actions à l’insu de la victime.

Il est donc tout à fait imaginable d’employer ce type d’attaque afin, par exemple, d’ajouter des articles dans le panier des clients d’un site de e-commerce. Pour cela, il suffirait à l’attaquant de reprendre le scénario précédent, mais de remplacer les boutons « like » de Facebook par le bouton « Ajouter au panier » du site e-commerce. L’attaquant pourrait augmenter grandement les ventes de son produit !

 Comment se protéger efficacement ?

La protection contre ce type d’attaques est à considérer du double point de vue de l’utilisateur et du responsable du site internet qui sert – involontairement – de support à l’attaque. La protection idéale nécessite donc sensibilisation et moyens techniques.

Pour les utilisateurs finaux en effet, se protéger implique d’avoir conscience du risque et de faire preuve de vigilance en surveillant ses fréquentations sur le web ! Il convient de rester méfiant à l’égard des liens commerciaux et des jeux ou concours qui promettent monts et merveilles.

Pour les équipes en charge de la sécurité des applications web, deux éléments sont à considérer pour mitiger le risque lié au clickjacking : l’utilisation d’en-têtes http spécifiques, et l’emploi de protections en JavaScript.

 Utiliser les en-têtes http appropriés pour se protéger

Il est d’une part possible d’utiliser l’en-tête http « X-FRAME-OPTIONS », qui va indiquer au navigateur à quelles conditions le contenu du site peut être intégré dans une iframe. Il est possible de lui spécifier trois valeurs :

• « DENY », qui va interdire l’inclusion de la page ;
• « SAMEORIGIN », qui va autoriser uniquement les sites du même domaine à inclure la page ;
• « ALLOW-FROM », qui permet de spécifier le ou les domaines autorisés à inclure la page.

Utiliser JavaScript pour s’assurer que ses pages ne sont pas dissimulées

En complément, il est possible d’utiliser du code JavaScript pour se protéger. Pour cela, ces codes vont par exemple s’assurer que la page est bien au niveau supérieur et qu’elle sera visible. Il faut néanmoins reconnaître qu’aucun de ces codes n’est totalement fiable.

Pour des informations détaillées sur les implémentations de ces protections, le site de l’OWASP propose une page dédiée à ce sujet.

La réauthentification, meilleure arme de protection pour les actions sensibles

La solution la plus efficace reste de ré-authentifier l’utilisateur pour les actions sensibles, par exemple en lui redemandant son mot de passe ou en utilisant un second facteur d’authentification, comme cela est l’usage sur les sites de banque en ligne.

Ces protections sont-elles couramment déployées ?

En un mot : non. Malheureusement, ce type d’attaque n’est toujours pas, 4 ans après leur découverte, pris au sérieux par la plupart des développeurs / testeurs / équipes de sécurité, sans doute car elles n’ont pour l’instant pas été exploitées à grande échelle en dehors des réseaux sociaux.

Selon un article publié récemment sur le blog de Qualys, les protections standards décrites ci-dessus ne sont ainsi pas encore déployées systématiquement : près de 70% des 20 sites bancaires les plus fréquentés n’implémentent pas de protection efficace contre ce type d’attaque.

Il est fort à parier que l’emploi de ce type d’attaque va augmenter et se diversifier à l’avenir.  En effet, les mesures de protection contre les attaques par rejeu de requête (XSRF) se généralisant, notamment par leur intégration dans les frameworks de développement, les attaquants se tourneront mécaniquement vers d’autres vulnérabilités, dont le clickjacking. Anticiper dès à présent  reste le moyen le plus sûr d’éviter d’en être la victime.

Cet article Clickjacking, mais qui a volé ma souris ? est apparu en premier sur RiskInsight.

L’adresse IP est l’identifiant unique d’une ressource sur internet, lui permettant d’échanger des données avec toute autres ressource IP. La version d’IP actuellement utilisée, IPv4, ne propose pas assez d’adresses uniques (à peine 4 milliards) pour répondre aux besoins actuels, et doit donc céder la place à IPv6, qui en propose un nombre quasi-infini. Les deux protocoles répondent au même besoin mais ne sont pas
compatibles : le passage à IPv6 est donc une évolution majeure, la plus grande qu’ait connu l’internet depuis 25 ans, et revêt une nouvelle urgence depuis que les dernières adresses IPv4 ont été attribuées en Février 2011.

Pourquoi un IPv6 Day ?

IPv6 a encore du mal à démarrer : les fournisseurs de contenu attendent que les clients aient migré, et les clients attendent le contenu. L’idée du IPv6 day était de rompre temporairement avec ce cercle vicieux, en mettant à disposition en IPv6 le contenu des principaux sites d’internet : Facebook, Google, Microsoft… et ce dans un but bien précis, celui de valider qu’à grande échelle, les mécanismes de cohabitation IPv6 / IPv4 fonctionnent bien, et que les clients peuvent donc accéder aux contenus IPv6 sans encombre dès lors qu’il est proposé. Une répétition générale, donc, pour voir si l’internet serait mis en péril grave par le déploiement progressif d’IPv6.

Quel bilan pour cette expérience et quelles suites lui donner ?

Finalement, l’IPv6 Day s’est révélé être beaucoup de bruit pour rien… et c’est tant mieux ! En effet, aucune remontée significative de lenteurs ou de pannes n’a été signalée, si bien que pour l’énorme majorité des utilisateurs, tout s’est déroulé comme lors d’une journée tout à fait banale. Conclusion : IPv6 fonctionne bien, et les sites web peuvent le mettre en oeuvre sans craindre de mettre en péril les connexions de leurs utilisateurs. Certains auraient même décidé de ne pas le désactiver à la fin de la journée. Les entreprises vont donc pouvoir commencer à réfléchir sereinement au déploiement d’IPv6 sur leurs sites web hébergés, car la pénurie d’adresses nous guette toujours et se rapproche inexorablement.

Cet article IPv6 Day : examen de passage réussi pour le nouveau fondement d’Internet est apparu en premier sur RiskInsight.