linking pre-check to POST and other requests?

One problem with the pre-flight check is that it is not bound to the
subsequent requests that it might authorize.

This means that there are race conditions when policies change, as
the service is unable to distinguish requests that were authorized
before a policy change from requests that were authorized
afterwards.

It also means that a service that is intended to expose data across
origins can't distinguish between a request that's caused through
some XSRF technique, and one that has gone through the authorization
algorithm.

Specifically for POST, a useful technique to avoid that kind of
problem is to use additional fields in the body of the POST that
send a nonce to the web application; that nonce would have been
previously obtained (either through a redirect-based protocol
between the two web applications, or through a cross-site GET).
Effectively, the "real" request is authorized much as it would be
with JSONRequest.  In case of a policy change, the nonce can be
invalidated.

I don't see how this technique would work generically for other
methods.

One way to bind a request to the pre-flight check is to define an
additional response header that is returned in response to the
OPTIONS inquiry.  That header would simply be an opaque, random
string which is replayed in the subsequent unsafe request.  The
opaque string would not be accessible through any client-side API.
The server can then verify that the nonce is one it issued before.

One side effect of this design is that it assumes that the OPTIONS
inquiry won't be cached.

Thoughts?

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 16 January 2008 23:15:31 UTC