Firefox 58 va bloquer un peu plus les Data URL de manière automatique

Firefox 58 va bloquer un peu plus les Data URL de manière automatique

Par Sébastien Gavois

Le 29 Novembre 2017 à 09h27
Logiciel
1 min 10

Firefox 58 va bloquer un peu plus les Data URL de manière automatique

Avec Firefox 57, Mozilla avait modifié le comportement de son navigateur pour les Data URL (commençant par data:), qui permettent de placer du contenu et des scripts « inline » au sein d'une page en leur faisant prendre la forme d'un lien clicable.

Si cette fonctionnalité peut être utilisée de manière légitime, elle est aussi détournée à des fins de phishing et autres pièges destinés à tromper l'internaute.

Dans Firefox 58, qui doit arriver fin janvier, les choses vont encore un peu plus se durcir nous apprend un billet du blog dédié à la sécurité de Mozilla.

Cette fois, ces liens seront purement et simplement bloqués, à quelques exceptions près : les documents texte, les images (hors svg+xml), PDF et JSON, lorsque l'utilisateur tape volontairement la Data URL dans la barre d'adresse ou qu'il veut télécharger le fichier.

En cas de blocage, une alerte sera affichée dans la console.

Commentaires (10)


v1nce
Le 29/11/2017 à 11h49

Ca ressemble plus à une solution de facilité qu’à une vraie solution.

Et puis autoriser le PDF et pas le SVG ??? 


lockidor
Le 29/11/2017 à 13h12

> les images (hors svg+xml)



Faut lire tous les mots.


laurient
Le 29/11/2017 à 14h16







lockidor a écrit :



> les images (hors svg+xml)



Faut lire tous les mots.





Ba oui c’est ce qu’il lit:

 ce qui est permis les documents texte, les images (hors svg+xml), PDF et JSON signifie que les SVG sont bloqués.



CryoGen
Le 29/11/2017 à 14h38



In more detail, the following cases will be blocked: 




 Web page navigating to a new top-level data URL document using:   


      window.open(“data:…”);   


     window.location = “data:…”   


     clicking  (including ctrl+click, ‘open-link-in-*’, etc).   


 Web page redirecting to a new top-level data URL document using:   


     302 redirects to “data:…”   


     meta refresh to “data:…”   


 External applications (e.g., ThunderBird) opening a data URL in the browser




Whereas the following cases will be allowed: 




 User explicitly entering/pasting “data:…” into the address bar   


 Opening all plain text data files   


 Opening “data:image/*” in top-level window, unless it’s “data:image/svg+xml”   


 Opening “data:application/pdf” and “data:application/json”   


 Downloading a data: URL, e.g. ‘save-link-as’ of “data:…”






C’est pour éviter les redirections foireuses, car les url DATA: peuvent tout de même envoyer des informations aux serveurs. Ca doit être pour ca que le svg+xml est bloqué en top-level


v1nce
Le 29/11/2017 à 17h24







CryoGen a écrit :



C’est pour éviter les redirections foireuses, car les url DATA: peuvent tout de même envoyer des informations aux serveurs. Ca doit être pour ca que le svg+xml est bloqué en top-level





Ca doit aussi être le cas pour du PDF, non ? Entre un svg de base (sans scripting ni ressource externes) et un pdf qui contient des liens foireux, je ne sais pas qui est le plus dangereux.



CryoGen
Le 29/11/2017 à 17h40

Le problème n’est pas le lien mais l’envoi de données. Je pense que le soucis du SVG+XML c’est de pouvoir faciliter le phishing (saisi d’information dans le navigateur directement) alors que le pdf ne vas pas pouvoir (il me semble) permettre d’envoyer de l’info.



Celà dit je ne suis pas un expert là dedans, c’est juste que la brève de NXI est incomplète, notamment sur le problème de pouvoir exploiter des liens DATA: .


Flykz
Le 29/11/2017 à 18h29

Je sens que ça va être bien relou, je sais pas pourquoi.


v1nce
Le 29/11/2017 à 23h57







CryoGen a écrit :



Le problème n’est pas le lien mais l’envoi de données. Je pense que le soucis du SVG+XML c’est de pouvoir faciliter le phishing (saisi d’information dans le navigateur directement) alors que le pdf ne vas pas pouvoir (il me semble) permettre d’envoyer de l’info.





Ton SVG ne va pas poster le formulaire tout seul comme un grand. Sauf si le scripting est activé.

Mais tu as le même problème avec le PDF : tu peux intégrer des forms dans un PDF (genre des CERFA bien relous), et du javascript qui s’exécute automatiquement.



 Après si Firefox gère entièrement l’affichage du PDF (sans déléguer à un interpréteur externe ou à un plugin)  ils peuvent éliminer le problème (soit parce qu’ils traitent le problème soit tout simplement parce que les fonctionnalités de scripting ou d’envoi de form n’ont pas été implémentées dans le viewer)



Si on s’est emm*és à faire en sorte que le PDF fonctionne c’est un peu dommage de ne pas accorder le même attention au svg. 



CryoGen
Le 30/11/2017 à 08h16

Bon déjà je viens de lire que Chrome/Chromium bloque aussi les data url, c’est qu’il doit y avoir un vrai problème de sécu avec ça <img data-src=" />


v1nce
Le 30/11/2017 à 18h13







CryoGen a écrit :



Bon déjà je viens de lire que Chrome/Chromium bloque aussi les data url, c’est qu’il doit y avoir un vrai problème de sécu avec ça <img data-src=" />







Je me plains des choix de firefox en matière de sécurité mais ils sont quand même largement au-dessus de Chrome qui est incapable de faire un modèle de sécurité potable et qui choisit systématiquement et de manière assumée la solution de facilité : tout bloquer.&nbsp;



Fermer