With the Web programming platform, though, come the Web’s programming practices and security issues, sometimes with more serious consequences than before.
Let’s begin with a classical piece of bad programming: Parsing data by evaluating it as code.
eval() primitive that comes in usefully: It takes a string and interprets it.
Now, one can argue that that’s just the same thing as including another script, so it’s not
really a big deal when done in the client-side part of a Web Application. The effect is,
after all, limited to one application, and that application’s server-side code will have to
deal with hostlie clients anyway.
However, while Widgets might feel a lot like the usual Web environment to the programmer, they
vastly) different. For instance, the Dashboard has a
available; that method takes a string and executes it as a Unix shell script. Effectively,
widgets) one executes has become the same question as the one what programs one installs. A
widget that evaluates JSON data is now a way for an attacker to turn an attack against, say, a
service like Twitter, or against your local network,
into an attack that takes over an entire machine. That problem isn’t just academic: Unsafe
JSON parsing is a regrettably common programming practice among widget authors. And your
web browsing behavior is intercepted whenever you’re asked to pay at a commercial wireless
hotspot. Exploiting these attacks is easy.
eval() isn’t the only way to create this kind of attack surface: Using callback based JSON programming
techniques by inserting
<script> tags into a widget’s document object
model creates exactly the same kind of vulnerability.
innerHTML DOM property to add a large fragment of HTML to the user interface. If
the data that are written to that property come from an untrusted source (e.g., the network),
and aren’t properly sanitized, then an attacker can once again get scripts executed.
But Google isn’t alone: There are more widgets out there with this kind of vulnerability. Triggering the vulnerability might not take an e-mail, but involve a network attack, or, maybe, a malicious blog post, a photo description, or some interaction on a social networking site. Or the widget itself might come from a malicious source. The point here is that we’re dealing with a shift in what Web-style programming can achieve — and that that shift does not come without risk, and responsibility. A shift, incidentally, that extends beyond just Widgets, as Web technology is also becoming the programming platform of choice for mobile devices, and as the capabilities of Web applications that run in the classical browser are extended.
Addressing this risk and responsibility will require work both inside the “Web industry” proper (and in the W3C Working Groups where it meets, including the Web Application Formats and Web API WGs), and with the broader community: This is a problem that extends beyond just the platform.