Re: FAQ & Use Cases

On 2008-01-16 11:44:11 -0800, Jon Ferraiolo wrote:

> I appreciate the attention that the WG has put into trying to
> promote a secure approach to deliverying POST requests, but IMO
> it would be better to pursue a different technical strategy, such
> as what we see in JSONRequest or something derivative of that.
> With JSONRequest, POSTs are allowed without requiring a prior GET
> (or HEAD or OPTIONS). JSONRequest also can be made available via
> a JavaScript implementation that works in today's browsers. 

The JSONRequest proposal is here:

  http://www.json.org/JSONRequest.html

A key element of that proposal is:

  In making the request, no HTTP authentication or cookies are sent.

That is most notably *not* true of the JSON-based techniques that
are used to perform cross-site data access at this point, i.e.,
injecting <script> tags into the DOM that then invoke a callback.

So, I'm surprised by your claim that this proposal can be
implemented in today's browsers

> Where did the idea of user-specific widgets come from, anyway?
> IMO, that would be a very, very low priority (approaching zero).

I'd disagree strongly with that, on a requirements level -- there
are numerous widgets (in the sense of desktop widgets) that actually
deal with user-specific resources, such as your inbox.  There are
also web-based widgets that deal with user-specific resources, e.g.,
when you have a view of your webmail inbox and calendar on your
search engine's start page.

> There are other approaches to sending data to a 3rd party domain
> that are more secure and still achieve the same result. Once
> again, JSONRequest does not send cookies. I assume that Doug
> Crockford assumes that authenticated information (if necessary)
> would come from be sent with the payload (rather than via
> cookies), which means that if domain FOO wants to upload data to
> domain BAR, then domain FOO's web page would require the user to
> someone enter their BAR authentication information (which could
> be stored in FOO's cookies, not BAR's cookies). With such an
> approach, the user will be told by FOO's web page that this web
> page needs his BAR account information, so the user gets to
> opt-in to allowing the cross-site POST, instead of the current
> approach in Access Control where cookies (potentially with
> credentials) are always sent without the user being aware.

In other words, you use redirects and form submissions to authorize
the cross-site request, then transmit a token that is used as part
of the JSONRequest, instead of using any ambient authentication or
session information.  (The details of your description aren't entire
right, but that's besides the point.)

This is effectively the same technique that web applications use to
defend against cross-site request forgery now; note that they'll
need to continue doing so.

One critical ingredient here is the assumptions that JSONRequest
HTTP requests are sufficiently different from "ordinary" ones that
they won't confuse any web applications that aren't intended to use
them.

> >Cookies and authentication information is already sent cross-site for the
> >HTML <img>, <script>, and <form> elements so this does not introduce a new
> >attack vector. It simply makes use of the Web.
> 
> <img> and <script> only work with GET, so if a web server follows best
> practices (i.e., only support POST when submitting data), then you aren't
> subject to data submission attacks. There is no way to retrieve data via
> <img>, so that doesn't allow data retrieval attacks. With <script>, the
> only way to retrieve data is if the server supports JSON-with-callback.

That is not accurate -- overloading the object constructor is just
one way to retrieve data from not JSON-with-callback servers.  While
some techniques are trying to mitigate this, it strikes me as risky
to assume that <script> doesn't leak data that was retrieved.

> Because of these factors, I don't think <img> and <script> should
> be used to say that the web is already vulnerable.

So, let's be precise.  The HTTP requests can be triggered using img
and script.

Even if the data aren't leaked, the access-control spec doesn't
introduce additional attacks in the GET case, as it will only permit
data retrieval if a policy is set.

> It is true that <form> works with both GET and POST and does send
> cookies to other domains, which means web site developers today
> indeed need to protect against CSRF attacks via cross-domain use
> of <form>, where CSRF protection is usually is accomplished by
> the server actually managing a session with the user where a
> random token is maintained across the session (without storing it
> within cookies). Right now, Access Control does not have a good
> mechanism for achieving server-controlled session management with
> such a random token, largely because it uses a client-side PEP
> approach. In fact, Access Control gets in the way of the way most
> server developers would implement CSRF protection.

I don't think I'm following you here.  The semantics of GET and POST
aren't actually changed by the access control technology; therefore,
including a nonce either in the construction of the URI, or as part
of query parameters.

Mind elaborating?

> With JSONRequest, the access control rules are loosened such that
> the new mechanism (i.e., JSONRequest) is allowed to access other
> domains, and therefore assumes that the policy enforcement point
> is the server who receives the GET and POST requests. This
> approach makes more sense and results in a simpler mechanism.

This particular decision is made much more flexible in the
access-control spec.  Higher-layer techniques remain possible,
unless I'm missing a point right now.

> On the other hand, JSONRequest can be implemented in JavaScript
> and will work with today's browsers, and therefore the community
> can use it immediately.

Parts of it might be usable immediately, but the more interesting
properties rely on browser-side implementation.

> What the above paragraph translates into is that I would like to
> see a requirement that says something about it being highly
> desirable that the mechanism can run in today's browsers as they
> exist today (without requiring the addition of a new browser
> plugin).

That won't be true of *any* mechanism that achieves cross-site data
access.

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

Received on Wednesday, 16 January 2008 22:51:24 UTC