Auteur Sujet: [Chrome] API JS donnant accès aux données sensibles réservées origines sures  (Lu 2555 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Que de chemin depuis les premiers navigateurs Web très grand public (Netscape Navigator, IE 2.0) ... les pages Web ne sont plus des documents textes pouvant contenir d'autres ressources non interactives avec une interactivité limité aux échanges avec le serveur (généralement par des formulaires).

L'interactivité ne passant pas forcèment par le serveur est partout. Pour ce faire, l'accès au DOM par JS a remplacé le Java, Flash et autres widgets ActiveX (chaque système ayant son modèle de sécurité, modèle pouvant être "faites moi confiiiiaaaance).

Puis sont arrivées des API donnant accès des informations privées de l'utilisateur, avec contrôle d'accès au niveau du nom de domaine :
- géolocalisation (*)
- accès au micro (#)
- accès à la Webcam (#)
- accès à l'accéléromètre sur un smartphone, qui peut être extrêmement sensible

(*) sur un laptop, un service fournis par Google à partir de sa base de données Wifi construite par les Google Cars de Google Street View; sur un smartphone le composant GPS peut être utilisé ou bien le Wifi

(#) Flash a été le seul moyen d'utiliser d'enregistrer l'utilisateur depuis un site pendant longtemps et certains sites utilisent encore le moyen

Ces API dévoilent des données privées; une fois l'accès autorisé, on peut toujours de révoquer mais on ne peut pas empêcher un site d'enregistrer les informations. Ces autorisations n'ont donc rien à voir avec l'autorisation de déposer des cookies HTTP, contrairement à ce que le grand confusionniste adulé défenseur du libre raconte.

Il est donc essentiel que le contrôle d'accès soit fiable : seuls les domaines autorisés par l'utilisateur doivent accéder aux informations.

corrector

  • Invité
Intent to deprecate: Insecure usage of powerful features

We want to start applying the concepts in https://w3c.github.io/webappsec/specs/powerfulfeatures/ to features that have already shipped and which do not meet the (new, not present at the time) requirements. We want to start by requiring secure origins for these existing features:

- Device motion / orientation
- EME
- Fullscreen
- Geolocation
- getUserMedia

As with gradually marking HTTP as non-secure (https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure), we expect to gradually migrate these features to secure-only, based on thresholds of usage, starting with lowest usage and moving towards higher. We also expect to gradually indicate in the UX that the features are deprecated for non-secure origins.

The deprecation strategy for each of these features is not decided on and may very well differ from feature to feature. We don’t currently know what the thresholds will be, or how heavily used the features are on what kinds of origins. We are in the process of gathering data, and will report back when we have it. There are no firm plans at all at this time, other than eventual deprecation. We intend for this to stimulate a public discussion of the best way to approach this deprecation. So, to that point, we'd love to hear what the community thinks.

Thanks,
   Joel Weinberger, Chrome Security

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ

corrector

  • Invité
En clair : certaines API sont tellement sensibles qu'on ne doit PLUS les accepter sur des pages HTTP via Internet.

Autoriser une API sur une page HTTP sur un domaine Internet revient à l'autoriser à n'importe qui capable de subvertir le DNS ou bien le routage.

localhost N'est PAS concerné par cette discussion : le fichier HOSTS n'est PAS le DNS, et l'interface de bouclage local n'est pas un accès à Internet.

vivien

  • Administrateur
  • *
  • Messages: 29 137
    • Twitter LaFibre.info
Si j'ai bien compris, ces API seront utilisables en https et plus en http.

Cela ne change pas grand chose : les sites malveillants vont passer au https.

corrector

  • Invité
Si j'ai bien compris, ces API seront utilisables en https et plus en http.
Oui, à terme.

Pour l'instant les sites en HTTP peuvent les utiliser, mais ça n'a pas vocation à durer.

Cela ne change pas grand chose : les sites malveillants vont passer au https.
Tu penses à quels sites?

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 202
  • FTTH 1Gb/s sur Paris (75)
Ca garantira juste qu'un MITM ne pourra chopper ces infos.

C'est toujours la responsabilité de l'utilisateur de savoir a qui il donne ses infos.

corrector

  • Invité
Il y aura TOUJOURS des gens qui se feront VOLONTAIREMENT filmer et qui le regretteront.

Ah à un moment il faut ou bien responsabiliser les gens ou bien leur enlever leur PC.

corrector

  • Invité
Si j'ai bien compris, ces API seront utilisables en https et plus en http.

Cela ne change pas grand chose : les sites malveillants vont passer au https.
HTTP ou HTTPS ne change pas grande chose (en pratique pour la plupart des utilisateurs abrutis par les merdias).

La présence ou l'absence de ces API ne change pas grand chose (en pratique pour la plupart des utilisateurs abrutis par les merdias).

Avant de donner une information confidentielle comme un mot de passe il faut regarder sur quel site on se trouve. AVANT de vérifier la présence d'un cadenas il faut regarder la barre d'adresse, à l'oppose d'années de lavages de cerveaux par les merdias.
« Modifié: 06 février 2016 à 11:09:20 par corrector »

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 202
  • FTTH 1Gb/s sur Paris (75)
HTTP ou HTTPS ne change pas grande chose.

ca change quand meme.

en HTTP si je suis sur le site 'lafibre.info', j'ai confiance et j'autorise ma camera ou ma position. Mais un type (NSA, DGSE, Stéphane Richard, XN, etc) peut écouter le trafic entre moi et lafibre.info a mon issue et donc choper ma position et ma tronche.

en HTTPS j'ai une garantie que y'a que lafibre.info qui a ces infos (apres si un type a hacker le serveur de Vivien la c'est un autre sujet..).

corrector

  • Invité
Sauf que pour 97 % des utilisateurs, lafibre.info ou lafibre.com ou lafibre-info.com ou lafibre.info.stuff.ru ou toto.cn ça ne fait aucune différence du moment que le contenu du site est le même (ou même différent d'ailleurs).

corrector

  • Invité
[Chrome] API JS donnant accès aux données sensibles réservées origines sures
« Réponse #10 le: 06 février 2016 à 11:06:23 »
en HTTPS j'ai une garantie que y'a que lafibre.info qui a ces infos (apres si un type a hacker le serveur de Vivien la c'est un autre sujet..).
En fait, n'importe qui ayant accès au disque dur du serveur peut en récupérer la clef privée, donc le personnel du DC, les hackers chinois, etc.

corrector

  • Invité
Si j'ai bien compris, ces API seront utilisables en https et plus en http.

Cela ne change pas grand chose : les sites malveillants vont passer au https.
Cela n'a rien à voir avec des sites malveillants.

Il est question de savoir si la connexion à un site est sécurisé; si ce n'est pas le cas, la demande de permission ne doit pas être

"voulez-vous activer votre microphone sur http://machin?"

mais :

"voulez-vous que n'importe quel site utilise votre microphone n'importe quand?"

Ce qui est une permission tellement dangereuse qu'on ne peut pas la proposer.

 

Mobile View