[Cryptography] Crippling Javascript for safer browsing

[John Ioannidis]

On Wed, Jun 4, 2014 at 7:36 AM, Jerry Leichter <leichter at lrw.com> wrote:

> 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
>
>
Jerry, you know very well why none of these are ever going to happen. Why
are you even bothering to enumerate them?

A certain browser vendor won't even give you the ability to change the
default font size and scale the rest of the screen accordingly -- if it
looks good on the screen of the the squirt who wrote the code, they don't
care about what screens others might have. And you expect them to ship
changes that would break that model?

/ji

> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140604/cb60f51c/attachment.html>