The Business Agility Blog

#1 JavaScript engines in browsers

JavaScript engines in browsers generally seem to be implemented as a single
instance with many contexts.

This works fine in theory, but resource scheduling and throttling appears to be
none-existent.

So a single piece of JavaScript running wild will block the page it’s running
on. And not only that page, but all the others as well because it’s the engine
itself that is feeding all the resources to a single execution chain.

Best case scenario : the ’stop script’ dialog, which makes no sense to most end
users.

Worst case scenario : browser crash.
Solution : sane context-aware resource scheduling and throttling built right
into the browsers.

#2 Shared libraries

A lot of AJAX code is written on top of large JavaScript libraries. Having
those available in the browser would save a lot of load time when going from
site A to site B, who both use the same library.

Having a way to specify a library you want to use in your code where the
browser will simply load it if it’s not available would be nice.

A way of saying

require({
  provider : 'http://dojotoolkit.org/libspec.js',
  version  : '0.9-IO'
});

would save everyone a lot of hassle. Make it signed, with cache-expiration,
etc. If you don’t want to rely on a Dojo/Protoype/etc build, make one yourself
and be your own provider.

#3 Offline storage

A standard way to store data on the browser across sessions would also improve
the state of the Web 2.0. Firefox is working on this, Microsoft is coming upwith something completely Microsoft-centric and non-browser based (thanks for that!)
and Dojo is hacking strings into flash objects (proprietary tech, but works
everywhere).

Something open and extendable that works everywhere, please.

#4 Cross domain scripting considered harmful

A piece of JavaScript code can only access a resource from the URL it was
loaded from. Sounds nice in theory, but there are now so many different ways of
circumventing that restriction in legitimate production usage across the net
that it’s starting to become a little silly to think that evil haxx0rs will be
stopped by this limitation.

Solution : pick a standard and drop the restriction.

#5 JavaScript engine inspection

The internals of most JavaScript engines are really, really hard to get at and
developers are often forced to resort to ’round-about ways to track down leaks,
circular references, etc.

No, I don’t want another debugger to examine my code with, I want an inspector
to examine the state of my code in the context of the JavaScript engine and the
host environment without breaking out the system debugger and having to
reconstruct the whole thing from assembly and C API calls.

And a good one for each major platform, please.

It seems like a month doesn’t go by without a new whitepaper detailing interesting new ways to maliciously apply JavaScript comes out. And this is fine. The problem I have is not with the papers themselves (I enjoy reading them – a lot of novel code appears there) but rather, how the media picks them up. Sure, ‘AJAX is insecure’ makes for clickable headlines, but it’s bad reporting.

When a security issue is reported the first thing that is relevant is discovering whether this is an implementation bug or an architectural flaw. Implementation bugs are fairly trivial to fix (but might have a lot of short-term impact). Architectural flaws are big time trouble.

Ajax security issues tend to fall into neither category. In fact, they usually are not even Ajax security issues. At all.

These issues generally focus on the interesting things you can accomplish as an attacker once you have already breached security by performing a form on how of malicious code injection.

There is nothing inherently insecure about Ajax applications. Their security (or insecurity) depends entirely on how the service provider manages the content delivered to the client.

So the Ajax security alerts don’t really tell us anything about Ajax security in itself. It is by now a well-established maxim in the security community that once an attacker manages to execute arbitrary code on your computer – it’s not your computer anymore. Why would anyone assume the rules have changed because the web jumped up a number in the media?

As an attacker, if you manage to inject your code into a page you can pretty much go hog-wild with the user session. But this is nothing new. For Ajax security the surface area available for attacks is fairly limited. Once you circumvent that the sky’s the limit, of course. There are any number of ways in which it is possible to get around the single domain policy found in all modern browsers. Some of these have even become a de-facto standard for Ajax developers and have lead to comments stating that such policies are pointless (I respectfully disagree here, but more on that later).

The content provider has a trusted role. A function of that role is to sanitize the content. LISP programmers and security programmers have been comfortable with the idea that code equals data and vice versa for a long time. This is for others a rather novel concept, but it’s high time everybody else caught up.

And shifting blame on end-users (a popular activity in the IT world) is simply not acceptable. As developers we have to shield end-users from technological complexity. This includes security. When people use our applications they implicitly trust us. As technology developers we have to honour that trust.

It makes for some interesting food for thought.

The bottom line is that security is hard and we can’t expect end-users to ever comprehend the complexities involved. So dumping security resonsibility on end-users is fairly stupid.

It’s up to us to write decent systems.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.