Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

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

Le 29 novembre 2017 à 09h27

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.

Le 29 novembre 2017 à 09h27

Commentaires (10)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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

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

votre avatar

> les images (hors svg+xml)



Faut lire tous les mots.

votre avatar







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.


votre avatar



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

votre avatar







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.


votre avatar

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: .

votre avatar

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

votre avatar







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. 


votre avatar

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=" />

votre avatar







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;


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

Fermer