août
2008
Lorsqu’on développe une applet, on est vite confronté aux contraintes lié à la sécurité, qui fait qu’un bon nombre de fonctionnalités pourtant apparemment basique ne sont pas utilisable directement. Il faut impérativement signer l’application ce qui provoquera l’affichage d’une autorisation d’exécution sur le poste de l’utilisateur.
Tout cela est parfois rageant lorsqu’on doit le faire pour une toute petite fonctionnalité qui peu paraitre tout à fait banale…
J’ai été confronté récemment à un problème similaire sur une application web et du JavaScript : j’avais besoin d’un bout de code me permettant de recopier automatiquement une partie de la page dans le presse-papier. Je n’ai eu aucun problème à implémenter cela sous Internet Explorer :
window.clipboardData.setData("Text", "Texte à copier...");
Malheureusement pour moi cela ne fonctionnait pas sous Firefox…
En effet Firefox n’implémente pas l’objet clipboardData, et mes recherches d’alternatives m’ont amenées vers trois solutions qui ne m’ont pas vraiment convaincu :
- La première consistait à utiliser une animation Flash qui s’occuperait du copier/coller, et qui serait appelée par une méthode JavaScript.
- La seconde correspondait à un code datant de l’époque Netscape, et qui ne fonctionnait plus de nos jours.
- La dernière option consistait à modifier les règles de sécurité de Firefox afin de faire fonctionner la seconde méthode.
Je ne comprenais pas les « dangers » que pouvait représenter le presse-papier. Ou plus précisément le fait d’y placer quelque chose.
En effet je comprend que l’accès au contenu du presse-papier pourrait être problématique, puisque cela pourrait permettre à une application de récupérer des informations auxquelles elle ne devrait pas avoir accès. En archivant les données qui transite par le presse-papier il pourrait être possible de récupérer des données sensibles (mot de passe, informations privées, …). Encore faut-il pouvoir les interpréter et les regrouper… mais ce serait possible !
J’avais par contre beaucoup plus de mal à comprendre les raisons qui ont amenées les développeurs de Firefox à interdire la copie dans le presse-papier. Le seul danger que je voyais c’est que cela pourrait écraser les données contenu dans le presse-papier, mais je ne pensais pas que cela puisse être considéré comme un moyen de stockage sécurisé !
Par dépits j’avais laissé tomber tout cela, jusqu’à hier soir où je suis tombé sur cet article : Adobe Flash ads launching clipboard hijack attack.
Des animations Flash utilisent le presse-papier pour des attaques de détournement. Grosso-modo l’astuce consiste à recopier systématiquement une URL dans le presse-papier, en écrasant les données éventuelles qui y ont été mise par l’utilisateur…
L’objectif : Apporter des visites sur ces URLs (qui proposent des anti-virus ou des mises à jours fictifs, infestés de malware).
- Soit parce que l’utilisateur entrera cette URL dans le navigateur en croyant avoir copié une autre adresse.
- Soit parce qu’il publiera cette adresse sur un blog/forum par erreur et par innatention.
- Soit tout simplement parce qu’il serait curieux de savoir à quoi correspond cette adresse…
Une proof-of-concept de cette « faille » est disponible et permet de mieux comprendre le problème : tant que cette page sera ouverte, il ne sera plus possible d’utiliser le presse-papier (il renverra toujours la même adresse bidon).
Mais le gros problème c’est surtout que des bannières de publicité ainsi « piégées » se sont retrouvées incluses sur de grands sites outre-atlantique, tel que Newsweek, Digg and MSNBC.com, ce qui a fait que cela a touché un grand nombre de personne…
Bref, ce n’est pas vraiment un problème de sécurité en tant que tel (ou tout du moins comme on pourrait l’imaginer), mais plutôt une intrusion forcé qui occasionne une gêne importante pour l’utilisateur… Et ceci rejoint la notion de sécurité car cela apporte de la confusion à l’utilisateur.
Je comprend mieux désormais le choix des développeurs de Firefox, et je ne comprend pas qu’Internet Explorer puissent toujours laisser le presse-papier en accès libre (aussi bien en lecture qu’en écriture d’ailleurs !).
Tutoriels
Discussions
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Classes, méthodes private
- jre 1.5, tomcat 6.0 et multi processeurs
- [ fuite ] memoire
- Définition exacte de @Override
- Difference de performances Unix/Windows d'un programme?
- Possibilité d'accéder au type générique en runtime
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Recuperation du nom des parametres