[OpenAjaxSecurity] Anyone care to comment on latest CSRF discussion about Access Control

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Tue Jan 15 11:38:16 PST 2008


Her arguments about <img>, <script> and <form> don't make a lot of sense: how do you steal what the server returned? Only script allows it *if* it's designed to send contents back to a parent frame or something along those lines.

From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: Tuesday, January 15, 2008 8:17 AM
To: security at openajax.org
Subject: [OpenAjaxSecurity] Anyone care to comment on latest CSRF discussion about Access Control


I have been slammed again by Anne, editor of the CSRF spec, this time saying nothing is new with the scenarios that I depict (you have to follow the link to see the scenario I depict), but my argument is that, if it becomes popular with web service providers, Access Control would add new vulnerability to different sorts of web services (in particular, XHR and XML based ones) and to a larger group of less sophisticated developers. What do you think about how hard we should pound on the cookie issue?

Jon


----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 01/15/2008 08:12 AM -----
"Anne van Kesteren" <annevk at opera.com>

01/15/2008 07:52 AM


To


Jon Ferraiolo/Menlo Park/IBM at IBMUS


cc


"WAF WG (public)" <public-appformats at w3.org>


Subject


Re: ISSUE 19: Requirements and Usage Scenarios document








On Tue, 15 Jan 2008 15:20:46 +0100, Jon Ferraiolo <jferrai at us.ibm.com>
wrote:
> I described a CSRF scenario in
> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0072.html.
> Search for the word "attack". My example attack vector depends on cookies
> being sent as part of the cross-site request and assumes that the
> simplicity of using Access Control would result is widespread adoption
> by a
> new generation of unsophisticated web service developers who will open up
> their APIs to mashup applications without understanding the consequences.
> Note that the big CSRF worry here is that cookies are sent with the
> requests.

Cookies are already sent for <img>, <script>, and <form> requests. Nothing
new. If people mindless opt in we have might have a problem (though it's
really the people that opt in that do), but I would expect that
dalmationlovers.invalid & co are using some off the shelf software.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

----- Forwarded by Jon Ferraiolo/Menlo Park/IBM on 01/15/2008 08:12 AM -----
"Anne van Kesteren" <annevk at opera.com>
Sent by: public-appformats-request at w3.org

01/15/2008 07:52 AM


To


Jon Ferraiolo/Menlo Park/IBM at IBMUS


cc


"WAF WG (public)" <public-appformats at w3.org>


Subject


Re: ISSUE 19: Requirements and Usage Scenarios document









On Tue, 15 Jan 2008 15:20:46 +0100, Jon Ferraiolo <jferrai at us.ibm.com>
wrote:
> I described a CSRF scenario in
> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0072.html.
> Search for the word "attack". My example attack vector depends on cookies
> being sent as part of the cross-site request and assumes that the
> simplicity of using Access Control would result is widespread adoption
> by a
> new generation of unsophisticated web service developers who will open up
> their APIs to mashup applications without understanding the consequences.
> Note that the big CSRF worry here is that cookies are sent with the
> requests.

Cookies are already sent for <img>, <script>, and <form> requests. Nothing
new. If people mindless opt in we have might have a problem (though it's
really the people that opt in that do), but I would expect that
dalmationlovers.invalid & co are using some off the shelf software.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080115/baa67bfb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 168 bytes
Desc: image002.png
Url : http://openajax.org/pipermail/security/attachments/20080115/baa67bfb/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 166 bytes
Desc: image003.png
Url : http://openajax.org/pipermail/security/attachments/20080115/baa67bfb/attachment-0003.png 


More information about the security mailing list