[Cryptography] Crippling Javascript for safer browsing

Jerry Leichter leichter at lrw.com
Wed Jun 4 07:36:34 EDT 2014


As software engineers, we're always drawn to make our systems as general and powerful as possible; but it's long been clear that power and security are antithetical.  Javascript in browsers is a great example.  A browser is fundamentally a display, and yet we've been drawn to include within it the a Turing-complete programming language - which inevitably opens holes for abuse, which then get patched or limited through some kind of wrapping sandbox.

Meanwhile, the only full defense is browser extensions that simply block Javascript completely - something that's impractical for most major websites today.

The fundamental problem here is the accepted belief that a browser's quality is related to the faithfulness of its implementation of the Javascript specs - even when those specs lead to browsers that facilitate attacks against their users.

Let me give a couple of examples of the kind of thing I'm talking about:

1.  Javascript lets you create new windows - and because some companies and programmers have a goal of allowing browser apps to look just like native apps, it lets you create any kind of window at all.  As a result, it's impossible for a browser to define a "secure password prompt" window (though some - Safari, for example - have tried):  Anything the browser can do, a Javascript hack can do.  Other attacks - e.g., clickjacking - are based on the same basic power.

But why grant that power?  A Javascript implementation that always created windows with a specific chrome on them, forced them to be visible, and enforced a minimum size, might inconvenience some developers, but would render a whole class of attacks impossible.  You might actually be able to trust that a password prompt really *was* a password prompt.

2.  Javascript implements a ton of environmental queries, from screen resolution and size to fonts on the machine to cache information.  This allows for easy fingerprinting of browsers.  A Javascript implementation that simply lied about this stuff - rounding screen information to one of a few standardized values, sending back a fixed list of standard fonts in a standard order, and so on - could stop such attacks.

3.  If a Javascript implementation ignored actions that triggered on attempts to close a window, all kinds of extortionate programs would have a much harder time harassing and terrifying ordinary users.

Of course, what I've said about Javascript applies equally well to other browser facilities.  If there are things in HTML5 that make attacks easier while not adding anything significant - don't implement them, or implement them in a way that mitigates the risks, even if doing so violates the standards.

It's a fundamental (and paradoxical-appearing) result in game theory that sometimes deliberately limiting your own choices improves your position.  We've been discussing keeping the level of language in protocols low in the Chomsky hierarchy to limit vulnerabilities in parsers.  The same idea applies elsewhere.  It'll be a tough lesson to learn, given decades of design philosophy that looks for ever more power - even the tools that disable Javascript are perceived not as limitations but as a way to give the user more choices.  But it's a lesson we need to learn if we're to have any hope of building more secure systems.

                                                       -- Jerry



More information about the cryptography mailing list