> 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. JSONRequest cannot generate a
GET, so those interfaces are safe, and it cannot generate a conventional POST
body, so those applications are safe, too.
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)
and does no validation of the POST data before issuing a JSON response, there is
the concern that JSON data can be sent to the browser. This is a thing that
JSONRequest can do that form.submit cannot.
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.
If the legacy application was misusing application/json in a speculative way,
the data might still be delivered. However, it will still be blocked if any of
the pre-JSON conventions are used:
Using a character encoding other than ASCII or UTF-8.
No quotes on keys.
Single quotes on keys.
Single quotes on string literals.
\x sequences.
Unusual values such as undefined or NaN.
Expressions or functions.
So, to repeat, JSON introduces no new security vulnerabilities for the legacy
JavaScript data formats of six years ago. The dangers of POST are already
existent. In that respect JSONRequest is strictly an improvement. The formats of
the POST bodies are not compatible. The Content-Type is not compatible.
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 believe that the string of errors would have to be
so long as to be completely implausible.
