RE: Accountability in AC4CSR

On Tue, 12 Feb 2008, Close, Tyler J. wrote:
> > 
> > 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.

The user's own IP may be enough to authenticate the user, so that doesn't 
stop the user taking the blame.

More importantly, if the user is using a hostile client, then either the 
user himself is hostile, in which case he wouldn't be using his own 
cookies and he _should_ be held responsible for anything he does, or, the 
user is using a hostile client unintentionally due to the user's system 
having been compromised, in which case the client doesn't need to make a 
cross-site request to do evil things, it can just do direct requests on 
the user's behalf.

Furthermore, if the client is hostile, then nothing the spec says will 
stop it from including any cookies on HTTP authentication it might want 
to include.


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

I guess I don't understand what scenario could have a hostile client in 
which the user is a victim and in which a third-party request would need 
to be faked. As I've mentioned before, if the client is hostile without 
the user's knowledge, then the client doesn't need to fake the third-party 
site. It can just change the other information in the request instead 
(e.g. it could intercept a cross-site transaction request and just change 
the destination account).


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

But if the client is hostile, what stops the client from sending a 
_different_ request than the one the user authorized?



Could you elaborate on exactly what situation you are envisaging here, 
using concrete examples?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 12 February 2008 01:27:38 UTC