RE: Accountability in AC4CSR

Ian Hickson wrote:
> On Thu, 7 Feb 2008, Close, Tyler J. wrote:
> > > >
> > > > That's the new part.
> > >
> > > Referer-Root is not new. It's a subset of an existing header.
> >
> > The content of Referer-Root is a subset of Referer; however, the
> > conditions under which an honest client sends Referer-Root are
> > different. Today, an honest, correctly implemented browser
> won't send a
> > cross-domain POST of XML content. Consequently, it is not
> convincing for
> > a dishonest client to use the Referer header to claim that
> a web page
> > from another site originated such a request. The same is
> not true of the
> > [Referer-Root] header. The [Referer-Root] header can be used to
> > convincingly blame another site for a request.
>
> Why is this a problem, given that the same (but with Referer)
> is already
> true for all GET requests and POST requests from <form>s?

For cross-domain GET requests, the server alone is accountable for any effects the request may have, so there is nothing to be gained in blaming another site for the request. The user has no blame to escape from.

For those sites that are aware of the possibility of cross-domain POST requests from <form>s, there is, in general, some server-side mechanism to prevent such requests from being processed. Since the request is rejected by the server, there are no effects for which someone may be held accountable. Those sites that are unaware of the possibility of cross-domain POST requests from <form>s may be vulnerable to an XSRF attack, which is generally considered a bug for which the web-application is accountable.

So for both these cases, there are, in general, no effects for which someone other than the server can be held accountable. The AC4CSR spec seeks to introduce a new scenario in which there are effects for which someone other than the server may be held accountable.

> How would you solve this problem?

I would not send any cookies, or HTTP-Auth credentials. This precaution makes it clear that the user is not automatically accountable for a cross-domain request. This is the right default, since the user may never have consented to the request. The request may have been silently generated by a visited web page.

I would also not identify any web site in the Referer-Root header, since the web site hosting the target resource cannot safely rely on the accuracy of this information. A custom client can of course put whatever information it wants in this header and there's no way for the server to know whether or not it's talking to an honest client.

These steps remove potentially misleading and so unsafe information from the HTTP request. The web-application will then need to employ a mechanism of its own choosing to implement access-control, and so assign accountability, for cross-domain requests. There are a variety of mechanisms to choose from here.

For example, in one pattern, the script issuing the cross-domain request may need to include in the request a shared secret obtained from the web-application via the user. In this scenario, the user may obtain a secret from the web-application which represents the user's consent for a third party site to issue particular requests, such as deleting email from a web-mail account. The user passes this secret to the third party web page. When the web-application receives a request that presents this secret, it knows the request is authorized and the user is to be held accountable for the effects, since the user expressed consent.

There are many other ways in which a web-application may implement access-control and accountability. The important part for the AC4CSR specification is not introducing misleading information that may result in broken implementations.

--Tyler

Received on Tuesday, 12 February 2008 00:34:42 UTC