About 12 years ago I was fighting a losing campaign against JavaScript’s ubiquity. There was a time when JavaScript was a security nightmare, and I ranted and raved against it. Things have changed enormously since then, all for the better. A few of the slogans that I and my colleagues shouted from the rooftops in the previous millennium seem to have stuck in the public mind, “Using JavaScript is insecure” or “JavaScript can’t be used for encryption”. Those slogans are no longer true. This post talks a little bit about how things have changed.
What has happened over the past dozen years falls into two categories. The first have to do with the way browser developers look at JavaScript. All of the vulnerabilities in handling JavaScript taught browser developers to be much more systematic and careful with how they handled JavaScript itself. The design of JavaScript and browsers have gone through a lot of change during this time.
Playing in the sandbox
The second category of change is more recent, and it really changes the game. The buzzword is “sandbox”, and it needs a lot of clarification because it is used all over the place in different ways. Roughly the idea is that something can do what it wants within a limited area and cannot really interact with anything outside of that sandbox. It is a safe place to play.
Increased browser sandboxing affects 1Password in two very big ways, and these are because of two different kinds of sandboxing relevant to us.
Sandboxing the browser
The first sandbox that matters for us is that browsers are becoming increasingly restrictive in what bits of your system they can interact with. The way that 1Password interacts with Safari 5.0 and earlier is profoundly different than the way that 1Password is allowed to interact with Safari 5.1 and above. Prior to Safari 5.1, there were “hooks” in Safari that allowed external applications to communicate with Safari. But in Chrome, from its inception, and in Safari from version 5.1 that kind of communication isn’t allowed. This is a major security enhancement; it limits the damage that a browser exploit can do. A successful browser exploit now can only interact with data and processes that are within the browsers’ sandboxes.
The upshot of this is that we have had to entirely redesign our Safari extension to fit within the tighter, better security model of Safari. It means that 1Password needs to work within the browser to do its job. That work must be done using only CSS, HTML, and JavaScript. Clearly for 1Password most of that work will be in JavaScript.
Sandboxing the extension
Browser extensions shouldn’t step on each others’ toes. We need to prevent this not only for security reasons, but for stability reasons. Extension X shouldn’t be able to see the database created by extension Y. So each Safari extension is also put in its own sandbox. This not only protects others from a misbehaving extension, but it protects the extension from outside interference from other sources, including JavaScript in the web page a browser is visiting.
JavaScript and encryption
People used to say that you can’t do encryption in JavaScript (because it doesn’t have the right data types, and because as in interpreted language it is far too slow). I suspect that most readers will have noticed that computers have gotten a little bit faster over the past 10 years. So while JavaScript may not be ones first choice of language coding encryption routines, there are now well developed, publicly available implementations of all of the algorithms and protocols that we rely on.
Users of 1PasswordAnywhere over the years have already experienced JavaScript opening of their 1Password data.
Times, and rules of thumb, change
It seems like yesterday (though it was actually years ago) that I was telling people to distribute documents as PDFs instead of word processor documents, because PDFs can’t be exploited in the same way. (As an aside, I would like to mention that there is a new security update for iPhone which fixes an exploit that can live in a malicious PDF file). It’s also true that the password advice I would have given 10 years ago is much different that what I would give now. The tools and the threats have changed so much. So it is with JavaScript.
Jeffrey Goldberg
Principal Security Architect
Tweet about this post