La norme est conçue pour être sûre. L ' implémentation peut ne pas l'être.

Le navigateur isole JavaScript, car il s'exécute dans un processus de navigateur lui-même. Il ne peut rien faire qui n'est pas autorisé par l'interpréteur JavaScript du navigateur ou le compilateur JIT. Cependant, en raison de sa complexité, il n'est pas du tout rare de trouver des vulnérabilités permettant à JavaScript de compromettre le navigateur et d'obtenir l'exécution de code arbitraire avec les privilèges du processus du navigateur.

Parce que ces types de bogues de sécurité sont si courants que de nombreux navigateurs implémenteront un bac à sable. Il s'agit d'un mécanisme de protection qui tente d'isoler un processus de navigateur compromis et de l'empêcher de causer d'autres dommages. Le fonctionnement du bac à sable dépend du navigateur. Firefox a un sandboxing très limité, tandis que Chrome et Edge ont un sandboxing important. Cependant, malgré cette défense en profondeur, les vulnérabilités des navigateurs peuvent souvent être combinées avec des vulnérabilités d'échappement du bac à sable.

Comment est-ce sûr?

Ce n'est pas le cas. Ou plus exactement, il est aussi sûr que l'implémentation du navigateur. Les navigateurs (y compris leur moteur JavaScript) sont des logiciels complexes, avec l'ajout régulier de nouvelles fonctionnalités - parce que les utilisateurs les veulent.

Cela signifie que, même si les plus connus ont certainement une procédure de qualité pour tester leur code contre les vulnérabilités connues, le risque d'une faille non détectée dans l'implémentation d'une fonctionnalité existe toujours.

Actuellement, la méthode acceptée est que dès qu'une brèche est détectée, une nouvelle version contenant un correctif est publiée. Mais entre la découverte de la brèche et l'installation du correctif, le navigateur est vulnérable, c'est la raison pour laquelle il est recommandé de garder son navigateur à jour, afin de n'être exposé qu'au zero-day vulnérabilités.

Il est vrai qu'au niveau JavaScript les navigateurs sont conçus pour sandbox le code en cours d'exécution (principalement en n'exposant aucune API dangereuse), mais JavaScript est un langage très complexe à analyser et exécuter .

ECMAScript est la norme derrière JavaScript, en raison de l'énorme inflation marketing autour des langages de programmation conviviaux pour les débutants que nous connaissons aujourd'hui, ECMAScript se met à jour rapidement et introduit des fonctionnalités de plus en plus complexes à implémenter pour un runtime. Ceci, à son tour, élargit la surface d'attaque et permet aux bogues de s'infiltrer .

Un exemple merveilleux est le travail récent de Patrick Biernat , Markus Gaasedelen , Amy Burnett pour le pwn2own 2018.

http://blog.ret2.io/2018/06/05/pwn2own-2018-exploit-development/

Le blog décrit la découverte d'un 0day qui permet l'exécution de code arbitraire dans WebKit et comment il est utilisé pour exploiter un autre 0day dans le gestionnaire de fenêtres macOS pour échapper à la sanbox dans laquelle Safari s'exécute (c'est un sandbox macOS, pas un Safari) pour passer à "root" et posséder le système.
En bref, en visitant simplement un lien tout en activant JavaScript, un système macOS peut être totalement compromis sans un seul problème visible pour l'utilisateur. C'est à quel point JavaScript peut être sûr: aussi sûr qu'un logiciel complexe que peut être JSCore de WebKit.
C'est pourquoi les utilisateurs qui ont besoin d'une haute sécurité sont invités à désactiver JavaScript (c'est une exigence assez courante dans DarkWeb, par exemple ).

La vulnérabilité ility dans WebKit découvert par les auteurs ci-dessus est une condition de concurrence entre le ramasse-miettes nouvellement introduit et la fonction array.reverse : si le GC commence à marquer un tableau pendant qu'il est inversé, cela pourrait conduire à un UAF (Utiliser After Free) exploit. La marque est effectuée séquentiellement sur le tableau, supposons que le GC soit juste au milieu du tableau lorsque cela est inversé, puis la seconde moitié n'est jamais marquée et donc élue pour la collection, ce qui entraîne un UAF (l'objet du tableau lui-même n'est pas collecté, seulement son élément).

La façon dont un UAF est utilisé pour créer des primitives d'exploitation plus puissantes pouvant conduire à l'exécution de code arbitraire est plus ou moins une variation des mêmes techniques: d'abord un objet intéressant est alloué dans l'espace nouvellement libéré (par exemple, un array) puis une primitive RW est créée (par exemple en modifiant la limite du tableau) et enfin des opcodes arbitraires sont écrits en mémoire (par exemple dans une page JITted).
Les détails pour ce 0day particulier sont dans le blog lié.

La partie intéressante est la façon dont ce 0day a été trouvé: étant donné que WebKit est si grand, un examen approfondi du code est impossible sans énormément d'efforts et une gigue automatisée a été configurée. réfléchissons au fait que lorsque nous avons des centaines de milliers ou des millions de lignes de code, il est très difficile de faire en sorte que chacune se comporte bien les unes par rapport aux autres.

Comme indiqué dans d'autres réponses, chaque navigateur possède son propre moteur de script conçu pour sandbox l'exécution de JavaScript et chaque moteur tente de limiter les fonctionnalités JavaScript qui pourraient conduire à un comportement malveillant.

Mais en règle générale, JavaScript n'a jamais été sécurisé dans le navigateur. Les développeurs de codes malveillants trouvent constamment des moyens d'exploiter le fonctionnement de chaque moteur ainsi que ses fonctionnalités JavaScript disponibles pour atteindre des objectifs malveillants.

Au cours des premières années, JavaScript était plutôt dangereux dans le navigateur. Maintenant, c'est une course constante entre les développeurs de codes malveillants et les développeurs de navigateurs / moteurs et finalement les développeurs malveillants gagnent toujours, même si ce n'est que pour une courte période. Ainsi, JavaScript peut difficilement être qualifié de sûr. "Devrait être sûr pour le moment" est une façon plus précise de le dire.

JavaScript est assez puissant

C'est pourquoi de nombreux utilisateurs le considèrent comme dangereux et le bloquent à l'aide d'extensions de navigateur. JavaScript permet aux sites Web de suivre les utilisateurs d'une manière impossible sans cela, y compris l'identification des utilisateurs après qu'ils ont supprimé leurs cookies en prenant les empreintes digitales du navigateur. De nombreuses API Web plus récentes telles que WebUSB autorisent des choses qui ne sont pas du tout sûres, mais les navigateurs demanderont l'autorisation de l'utilisateur lorsqu'ils accèdent à des API non sécurisées comme USB et appareil photo.

Il n'y a rien de sûr en soi à propos de JavaScript, à bien des égards, il est moins sûr que d'autres langages:

• instruction eval
• typage dynamique

C'est le sandbox où le navigateur exécute le JavaScript qui assure la sécurité. Consultez la documentation sur le bac à sable Chrome ici, notez qu'il n'y a aucune référence au script JavaScript ou ECMA.

Aujourd'hui, la grande majorité du code s'exécutant dans le navigateur est écrit en JavaScript. Avec la montée en puissance de WebAssembly, nous verrons probablement la plate-forme de navigateur passer du verrouillage de langue principalement unique d'aujourd'hui (comme un mainframe du passé) à une plate-forme ouverte où n'importe quel langage compatible WebAssembly peut être utilisé. . Cela prouvera en quelque sorte que JavaScript n'est pas particulièrement sûr / spécial, car à ce stade, de nombreux langages seront exécutés dans le navigateur. Toutes ces langues utiliseront le sandbox fourni par le navigateur pour s'exécuter.

Il est sûr par rapport au code exécutable au niveau de la machine, comme ActiveX utilise.

Un programme de code machine a un accès illimité à toute interface que le système d'exploitation et les bibliothèques fournissent à tout programme exécuté sous ce compte utilisateur, n'est VRAIMENT limité dans ce qu'il peut faire que par ce que le matériel et le système d'exploitation le restreignent to - essentiellement rendre un tel programme aussi puissant que l'utilisateur qui l'exécute. Il peut y avoir des outils qui essaient de le restreindre en interceptant certaines des interfaces fournies, mais il est difficile d'arrêter un programme conscient de ces mesures pour les contourner.

L'interpréteur javascript fait partie du navigateur, et écrit de manière à n'offrir au programme qu'il exécute que les interfaces et les pouvoirs qu'il souhaite leur offrir.

JavaScript est "relativement sûr", mais pas "absolument sûr". Tout code que vous exécutez sur votre système a le potentiel de nuire. Il n'y a pas de système parfaitement sûr, à l'exception de celui qui n'a jamais été utilisé. JavaScript est plus sûr que de mettre un périphérique USB inconnu dans votre ordinateur, et plus sûr qu'un binaire que vous téléchargez à partir d'un site Web douteux ou insérez une pièce jointe suspecte, et beaucoup plus sûr que certains des scripts que vous trouverez sur les sites Web qui vous indiquent de copiez-collez-les dans votre shell.

Il a des fonctionnalités de sécurité: un bac à sable pour aider à isoler le processus, une API relativement limitée qui a des contraintes de sécurité pour éviter d'exécuter des instructions informatiques arbitraires, et des contrôles de sécurité destinés à Limitez l'exposition des données sensibles telles que les empreintes digitales ou le partage de données entre domaines. Celles-ci s'ajoutent aux contrôles de votre système d'exploitation appliqués au binaire du navigateur pour limiter les mauvais comportements et aux applications antivirus qui peuvent aider à arrêter de telles attaques.

Cependant, ce n'est pas absolument sûr. Les bogues dans le moteur d'exécution du navigateur, le navigateur lui-même, l'antivirus ou même le processeur lui-même peuvent tous compromettre la sécurité de JavaScript. Le système est aussi sûr que sa sécurité la plus faible. La sécurité de JavaScript est principalement destinée à empêcher les exploits «occasionnels» (comme un enfant de 8 ans qui apprend JavaScript pour la première fois et écrit accidentellement un exploit), mais n'a aucune chance contre des attaquants dévoués. JavaScript est suffisamment compliqué pour qu'il y ait forcément des bogues, peut-être de manière étrange et inattendue.

Ceux qui sont expérimentés dans le piratage, les tests de stylet et la sécurité peuvent parcourir le code source, déboguer des exécutables et le font. faites tout ce qu'ils peuvent pour essayer de trouver des fissures dans l'armure. Les points faibles de l'implémentation JavaScript. Et JavaScript est suffisamment gros pour que de telles lacunes existent au départ, car il est pratiquement impossible d'automatiser tous les tests possibles qui permettraient de trouver ces bogues.

D'une manière générale, tout script typique que vous pourriez exécuter sur un site Web typique est probablement "sûr", en particulier ceux auxquels sont liés par les principaux moteurs de recherche. Cependant, une fois que vous commencez à sortir des sentiers battus, il est extrêmement probable que votre système soit compromis à un moment donné s'il y a ne serait-ce qu'un seul point faible. Il suffit d'un très bon exploit, ou parfois de deux ou trois en tandem, pour prendre complètement le contrôle d'un système.

En l'état, n'activez JavaScript que pour les sites de confiance (j'utilise personnellement NoScript à cette fin) , gardez toujours tous vos logiciels à jour et faites toujours attention aux avertissements du navigateur tels que les certificats invalides, etc. Même dans ce cas, vous ne serez pas en sécurité à 100%, mais vous participerez activement à votre propre stratégie d'atténuation.

Cette réponse abordera deux points soulevés à la question et une "fonctionnalité" du navigateur non soulevée dans la question.

JavaScript a certaines limitations telles que l'interdiction de lire et d'écrire sur le disque

cette limitation n'existe pas techniquement dans les navigateurs Chromium / Chrome où requestFileSystem est défini, qui écrit directement sur le disque; c'est-à-dire le dossier File System du répertoire de configuration Chromium / Chrome dans le système de fichiers des utilisateurs.

Voir Comment écrire dans un fichier (répertoire utilisateur) en utilisant JavaScript?

et ne pas autoriser l'accès à d'autres fenêtres ou domaines de navigateur.

Si une fenêtre est ouverte à partir d'une fenêtre déjà ouverte, la communication entre les fenêtres s est possible en utilisant, y compris , mais sans s'y limiter, postMessage , MessageChannel , SharedWorker , ou simplement interroger les paramètres de chaîne.

Voir Comment puis-je charger un collaborateur Web partagé avec un script utilisateur?

Un autre point non mentionné à l'OP qui doit être soulevé ici spécifique à Chromium / Chrome est le fait que l'implémentation SpeechRecognition de l'API Web Speech sur ces navigateurs enregistre la voix des utilisateurs (identifiant biométrique) et envoie cet enregistrement à un service distant, sans informer directement l'utilisateur de ce qui se passe. Il n'est pas immédiatement clair si le ou les enregistrements sont conservés (pour toujours) par le "service Web" non divulgué ou "supprimés" à un moment donné.

Voir Est-ce que webkitSpeechRecognition envoie l'audio enregistré à une télécommande service Web par défaut?

Il est sûr car il a été conçu pour être sûr. Ou du moins, c'est sûr au point où un "JavaScript est assez puissant" moins que formel suggère qu'il est probablement suffisamment sûr pour vous rassurer. En pratique, aucun logiciel n'est parfaitement sûr, c'est donc une question de degré. Javascript est suffisamment sûr pour que la plupart des entreprises acceptent de permettre aux employés de visiter des sites Web à l'aide du matériel de l'entreprise.

JavaScript est conçu pour empêcher les attaquants d'accéder à vos fichiers ou à toute information privée. Par exemple, il a un support pour empêcher un script sur un site de regarder les données d'un autre site (connu sous le nom d'attaque intersite).

Bien sûr, ce n'est pas parfait. Il y a eu une récente frayeur avec Spectre et Meltdown, une paire d'exploits qui reposaient sur une faille dans certains processeurs pour se libérer des exécutions JavaScript du bac à sable. Cela devait être patché avec des hacks logiciels plutôt laids pour couvrir les processeurs défectueux.

Mais en général, il est "sûr" d'exécuter de tels scripts car de nombreux experts en sécurité ont passé beaucoup de temps à s'assurer que ce sentiment de la sécurité est justifiée. Mais tout dépend de votre modèle de menace. Si vous aviez des milliards de dollars en jeu, vous ne voudriez peut-être même pas faire confiance à la sécurité de JavaScript!

La vraie question est donc de savoir quelle est votre barre pour «sûr»? Considérez-vous que Windows est sûr? Qu'en est-il d ' Internet Explorer? Adobe Acrobat Reader? OpenJPEG? Le noyau Linux? OpenSSL? La sécurité et la convivialité sont toujours en désaccord. Vous devez utiliser quelque chose (ou peut-être que vous ne l'avez pas. Les Amish n'ont pas encore été frappés par un 0-day ... sauf si vous comptez une nouvelle souche de grippe) Pour vraiment comprendre si vous pouvez appeler quelque chose de "sûr" pas vous avez besoin d'un modèle de menace, définissant comment quelqu'un pourrait vous attaquer, et d'un modèle de convivialité définissant la convivialité que vous devez atteindre tout en atténuant le modèle de menace. Sans ceux-ci, nous devons lire vos mots et votre histoire pour deviner ce que signifie «sûr».