Javascript Girl
  1. Javascript Girl
  3. Pourquoi écrire au presse-papiers dans JS considéré comme un trou de sécurité?
Intereting Posts
Existe-t-il un moyen d'obtenir la fonction actuelle dans la fonction actuelle? Double injection dans AngularJS via ngInject et ng-annotate Ngf-max-size $ digest () erreur avec ng-file-upload dans angular.js Comment utiliser JSON.stringify et json_decode () correctement Inclure un fichier javascript dans l'application Brillant Enregistrer .addClass avec cookie jQuery ou stockage local Comment puis-je écouter le début d'un utilisateur créant un polygone dans Google Maps v3? Comment trouver les fuites de mémoire JS? Multiline questionaire éditable JSON.stringifier les objets profonds Comment vérifier l'existence d'un fichier dans l'annuaire téléphonique avec le partage de téléphone Comment déployer OpenLayers avec Tomcat + JSF 2 Convertir la chaîne Json en liste d'objets C # Comment savoir si TD actuel est la dernière TD en TR L'attribut focalisable SVG ne fonctionne pas

Pourquoi écrire au presse-papiers dans JS considéré comme un trou de sécurité?

Il semble qu'il n'existe actuellement aucune méthode JavaScript pure pour accéder au presse-papiers du système à l'aide de la plupart des navigateurs modernes, Internet Explorer étant une exception. Sur de nombreuses autres questions de Stack Overflow (p. Ex., Accès au Presse – papiers à l'aide de Javascript – sans Flash? ), Il est expliqué que cette limitation est une mesure de sécurité délibérée pour protéger contre les sites Web qui lisent des mots de passe ou d'autres données sensibles du presse-papiers.

Bien qu'il semble évident que la lecture du presse-papier serait un risque de sécurité énorme, il ne me paraît pas clair pourquoi il serait écrit d' écrire sur le presse-papiers. Quel scénario, le cas échéant, les navigateurs protègent-ils en refusant à JS la possibilité de copier des données dans le presse-papiers?

L'écriture dans le presse-papiers est un moyen pour les sites Web malveillants (ou un autre code exécuté dans des sites, tels que des publicités flash) pour inciter les utilisateurs à diffuser des logiciels malveillants. Cela s'est produit il y a quelques années avec des publicités flash qui ont copié une URL de logiciels malveillants dans le presse-papiers, dans l'espoir que les utilisateurs le colleront lorsqu'ils ont l'intention de coller quelque chose, polluant ainsi les articles de Facebook, les forums et les e-mails. Au lieu d'un lien vers une photo du chat de Tante Tilly, vous collez un lien vers un malware drive-by. En règle générale, il s'agissait de "vous avez été infecté par un virus, payez-nous 50 $ pour le logiciel de suppression" de faux antivirus. J'ai fait des recherches là-dessus, car beaucoup de mes clients de ClipMate demandent pourquoi ces URL désagréables apparaissent soudainement dans ClipMate. Pendant la recherche, j'ai été attaqué par des publicités flash sur MSNBC et DIGG. Le presse-papier a ensuite été verrouillé dans Flash 10. Vous pouvez en savoir plus sur ma saga ici: http://www.clipboardextender.com/defective-apps/clipboard-virus-not-exactly-but-still-dangerous

Je m'attends à ce que la restriction JavaScript soit pour éviter que des choses similaires ne se produisent.

Que faire si l'utilisateur ne veut pas que son presse-papiers soit écrasé?

Si l'utilisateur s'attend à ce que son presse-papiers contienne une chose, mais en cachet, il a été remplacé par une autre chose, même s'il s'agit d'un problème de sécurité potentiel, pas seulement un ennui.

Bien qu'il s'agisse d'un vecteur d'attaque peu probable, il n'est pas déraisonnable de penser que quelque chose pourrait être rêvé qui implique l'ingénierie sociale: convaincre l'utilisateur de coller des informations altérées dans un champ de mot de passe sur une ressource cible. Cette ressource serait alors sécurisée par un mot de passe connu de l'attaquant.

Mis à part les problèmes de vulnérabilité susmentionnés, il existe au moins un scénario dans lequel la mise en œuvre de l'API de presse-papiers javascript peut apporter des problèmes de sécurité.

De nos jours, nous avons de nouvelles API pour établir une connexion entre des fenêtres distinctes sans invoquer le serveur, comme PostMessage , MessageChannel ou, par exemple, BroadcastChannel introduit récemment sur Firefox. Ces API ont un niveau de support de navigateur différent, mais tous considèrent des problèmes d'origine croisée. Autrement dit, il devrait être impossible de recevoir un message d'une fenêtre sur un hôte différent, à moins que cette fenêtre ne l'autorise explicitement.

Cela ne tient pas avec l'API du presse-papiers. Imaginez qu'un code sur la page colle le code au presse-papiers et que ce presse-papiers est scanné par une autre fenêtre. C'est un scénario très étrange et très hypotetique selon certaines hypothèses assez étranges et exotiques, mais il vaut la peine de le mentionner.