[whatwg] JSONRequest

[Chris Holland]

Yeah, my main issue with JSONRequest right now is that we're coupling
two things:

1) protocol specifications to cater to various business needs.
2) security of that protocol.

Doug, you're basically making the assumption that

1) because JSONRequest will work in entirely different ways currently
not implemented by any service
2) it will be secure

I would *love* to be able to use a clean JSONRequest from within the
same host, and have access to cookies and basic http auth, to
transparently conduct transactions, because it's more elegant and
lightweight than some <script> payload, or some HTML/XML document
payload from an xmlhttprequest. And I bet other developers will find
it more elegant and, despite documentation 1) not understand why
cookies and basic auth information are ignored, get frustrated and
generate more time-wasting discussions, and 2) still eventually find
ways to expose their data to be consumed by JSONRequesters, not
realizing that it's available to hosts outside of their firewall.

JSONRequest defines a compelling alternative to xmlhttprequest for
data exchange. But you could easily decouple the "cross-host" aspect
from the "JSON" aspect of your proposal.

That's where the extra HTTP header would come-in:
"X-Allow-Foreign-Hosts": Forcing developers who expose such a service,
to make the conscious choice to expose data to the world, what Jim
refers to as "OPT-IN". If your service is to be consumed by a
JSONRequest, it *must* send that header, otherwise, the client will
simply fail in similar ways as if you tried to load an image in a
script src="", heh.

Again, we spoke about much of all this around here:
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-March/003155.html

go back and forth from that message ... i think we're digging a bit
too deep at some points.

Looking back, I'm leaning toward hoping the "X-Allow-Foreign-Hosts"
header value would be boolean-esque, and should the service author
wish to more granularly control which foreign HTML documents may
"suck-down" their contents, they might just lean on the value of the
HTTP "Refer[r]er" header value.

and X-Allow-Foreign-Hosts might be instead named
X-Allow-Foreign-Documents ... or something better. heh. and
"ContextAgnosticXmlHttpRequest" is also  a bad name, i'm just not good
at naming things ... <:\




On 3/20/06, Jim Ley <jim.ley at gmail.com> wrote:
> 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.
>


--
Chris Holland
http://chrisholland.blogspot.com/