from __future__ import *

buy music albums Silver Apples buy mp3 albums Tarrus Riley buy tracks mp3 Kravits buy Reaper albums mp3 buy Kravits albums music buy music Evita CD online albums mp3 Silver Apples download Madonna CD music buy tracks music Kravits download music albums Silver Apples

Recently, Fortify Software has claimed that there is a pervasive and critical vulnerability in Web 2.0 with their JavaScript Hijacking paper. The way they wrote the paper is extremely misleading and was likely constructed this way on purpose to garner press and business for their company.

The first egregious dishonesty in their paper is that it analyzes client-side Ajax frameworks. This is not where the vulnerability is, nor where it's fixed. The service's intended client-side JavaScript code is not even executed during ANY PART of the demonstrated exploit! However, client-side Ajax frameworks are a hot topic, so what the hell, let's blame them.

The second is that they do not enumerate all of the preconditions required for the exploit. The client must support JavaScript setters. The only browser that I've found that supports these are Firefox. Internet Explorer 6, Safari, and Opera are NOT VULNERABLE to the specific exploit described in the paper. The paper claims that "all of the examples in the paper could be adapted to work under Internet Explorer too". Oh yeah? Prove it.

And MOST importantly the exploit is only applicable to JSON that also happens to be valid JavaScript code. The only type of JSON that is valid JavaScript code without parentheses is a JavaScript array (or bare primitives, but those are not interesting or exploitable). That's right, the simplest fix is to always make sure you send an object on the outside, not an array.

Exploitable:

[{"object": "inside an array"}]

NOT Exploitable:

{"object": "not inside an array"}

Also NOT Exploitable:

{"result": [{"object": "inside an array"}]}

The simplest solution is to just change the JSON RFC to include a strong recommendation that only objects should be allowed as an envelope. Server-side frameworks should give error or provide warning when an array is serialized without a containing object. I notified them of this before the paper was published, but they ignored my suggestion and instead went for the more complicated suggestion of trying to add backwards-incompatible sludge to JSON.

I've crafted a little example that shows which browser you're using and the attacks that were successful. The Fortify exploit is "Array/Object JSON vulnerable". The two other tests are for JSON documents not contained by an array. The Fortify exploit is the only one that succeeds, and it only succeeds in Firefox.

Aral Balkan has recently released SWX, a new data exchange format for Flash.

In his current implementation it's really two standards: A JSON-ish format based on PHP (bad idea) and a particular layout of SWF bytecode on the receiving end (good idea).

Creating another JSON-like format is stupid. I really don't know why he did that. There are plenty of fast parsers for JSON in PHP, which are almost certainly going to be faster and perhaps safer than scanning input with a regex and eval-ing it. Using eval in server-side code with untrusted input, no matter how good you think your input validation is, is just foolish

Generating SWF bytecode for the return value is a good idea. It's fast, compact (zlib compressible even), requires no parsing on the Flash end, and can be used cross-domain (with appropriate instrumentation) since it's just a loadMovie call. We actually do something very similar to SWX for essentially these reasons (that's a lot of what eswf is used for).

I'd like to see him give up on the PHP junk in exchange for JSON and add explicit hooks in the standard for cross-domain help (LocalConnection transport, System.security.allowDomain support). All said, this could be a good thing for Flash developers and I'll be paying close attention to the project over the next few months.