Re: FAQ & Use Cases

Thomas Roessler <tlr@w3.org> wrote on 01/16/2008 02:51:12 PM:

> 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

When I said the JSONRequest can be implemented in today's browsers, what I
meant is that it is possible to define JavaScript APIs that match those
found in the JSONRequest specification, but under the hood of course, where
the implementation would be, if the browser did not natively support
JSONRequest, then of course it is not possible in today's browsers to make
everything work as found in the current JSONRequest specification. The
cookie problem is definitely as problematic with a pure JavaScript
implementation of JSONRequest as it is with the today's dynamic script tag
approach (given that the JavaScript implementation of JSONRequest almost
certainly would pull off its magic via dynamic script tags).

In an ideal world, I would start with the current JSONRequest specification
as the starting point and then adjust it in minor ways, such as (my
opinion) add XML as an option and address issues having to do with allowing
pure JavaScript implementations in the short-term.

>
> > 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.

But I am pretty sure that you don't have to transmit cookies to the web
site that holds the definition of the XBL-powered widget to make this
happen. The web page is in domain A, and there is information stored about
domain A within its cookies. When you grab an XML widget from domain B, the
widget's markup content gets cloned into some shadow tree within the web
page that is within domain A. The JavaScript logic within this widget then
will have client-side access to the domain A cookies and can customize to
its heart content while operating within the (domain A) web page. (Or has
XBL changed and the XBL widget is sandboxed into an IFRAME-like approach?)

>
> > 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.

Yes, I agree with last sentence, but it is definitely not true that data
can be retrieved via <img>, and with <script>, it is a complicated story.
My main point is that I don't buy the argument that we shouldn't claim that
there are so many vulnerabilities today that we shouldn't worry about the
vulnerabilities that are side-effects of Access Control, particularly due
to its transmission of cookies.

>
> 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?

Thanks for your clear response. Yes, you are right, and I was wrong when I
said Access Control gets in the way of CSRF protection. It's just that it
won't be drop-dead simple for a server that wants to implement CSRF
protection along with Access Control. The most popular techniques used
today to achieve CSRF protection (e.g., hidden form fields holding the
nonce) probably would warrant some rework to work well in a world that
included Access Control. But "rework" is different than "get in the way".

>
> > 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>