- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 03 Jan 2008 10:42:03 -0800
- To: "Close, Tyler J." <tyler.close@hp.com>
- CC: Jon Ferraiolo <jferrai@us.ibm.com>, Anne van Kesteren <annevk@opera.com>, Ian Hickson <ian@hixie.ch>, Mark Nottingham <mnot@yahoo-inc.com>, "public-appformats@w3.org" <public-appformats@w3.org>
Close, Tyler J. wrote: > > Jonas Sicking wrote: >> Close, Tyler J. wrote: >>> Hi Jon, >>> >>> Jon Ferraiolo wrote: >>>> * The Access Control mechanism MUST not broaden the attack >>>> surface for hackers, particularly with regard to CSRF >>> Could you elaborate a bit on this contraint? For example, one >> > interpretation might be that the currently proposed mechanism >> > violates this constraint since any cookies or HTTP Auth credentials >> > the user may have are included in the request sent to the server >> > (the opposite of what's done in the JSONRequest proposal). >> In essense, >> > the current proposal is one for determining the set of >> hosts that are >> > allowed to issue CSRF requests, which is a broadening of the CSRF >> attack surface. >> >> Does this really broaden the attack surface since it is >> already possible >> to do GET requests, that includes cookies and HTTP Auth >> credentials, to >> any uri on any server by simply pointing an <img> to that uri? > > The barn door is pretty wide open, but the current proposal does open it even further. For example, it is not currently possible to POST an XML request which includes the user's cookies and HTTP Auth credentials (modulo exploits of various browser plugins). Various web-services may become more vulnerable under the current proposal. This will only be possible if the server first explicitly declares that it is able to handle such a request. A POST request is always preceded by a GET request in which the server has to explicitly state that the POST request should be allowed. / Jonas
Received on Thursday, 3 January 2008 18:42:23 UTC