[whatwg] JSONRequest

[Jim Ley]

On 3/20/06, Douglas Crockford <douglas at crockford.com> wrote:
>  > Or indeed wrote your script before this JSONRequest was invented.
>
> I think I see where you are confused. A pre-JSONRequest JSON application
> will be using GET, or POST with a conventional POST body.

What exactly is a "conventional POST body"

> JSONRequest cannot generate a GET, so those interfaces are
> safe,

Many webservers will return data in response to a POST even if
expecting a GET, a bug perhaps, but there's no specification which
prevents it.

> and it cannot generate a conventional POST
> body, so those applications are safe, too.

I have lots of applications that POST json to the server, and return
more JSON, for exactly the reason your proposing this interface now.

> If an application is so badly implemented that it accepts dangerous POSTs (we
> already determined that JSONRequest is safer than form.submit in this regard)

Where did we determine this?   Please start sharing your security
analysis, it seems rather lacking to me, so I'm not really prepared to
trust blanked statements of what you've determined.

> So, is this a problem? No. First, JSONRequest will reject the response and not
> return to the script because the Content-Type is not application/json.
> application/json is only now being registered as MIME media type. Legacy
> applications should not have been using it.

_SHOULD_  see, you're relying on perfect systems everywhere, that is
not an appropriate reliance, and as there are other methods - opt-in
methods - that allow cross domain scripting to be done more securely,
I simply don't see the point of not using them, and go for these poor
security methods you're advocating.

Also, someone using a application/vnd.someone.json will likely change
their server configuration to application/json as soon as it's
registered, so legacy apps will be using the appropriate mime-type.

> So, to repeat, JSON introduces no new security vulnerabilities for the legacy
> JavaScript data formats of six years ago.

You just admitted, that it did, so please stop repeating that phrase,
you may want to use a phrase such as "few" or "rare" or "only in
certain situations" are new security vulnerabilities present, but
there are certainly not none, and your refusal to admit this in the
document, when you do here suggests that you do not want your
specification to be reviewed fairly by all concerned.

> I would very much like to see the details of a specific attack in which a legacy
> application which depends solely on firewall locality for its security is
> compromised by JSONRequest.

I have some where all that would be needed is a
application/x--jl-message-result becomes a application/json -
something that is likely to happen (without me knowing) once the the
mime-type is registered.  Of course it's behind a firewall, so I can't
direct you to it, but it meets all of the other restrictions on JSON
you've listed above.  The data protected is pretty innocuous, but I'd
be crazy to think I was the only person doing it, why do you think I
am?

Cheers,

Jim.