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

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Tue Jan 15 15:37:53 PST 2008


Yes, I understand that, but they’re misunderstanding the risk here. It’s not unauthorized access to a service that has side-effects in a GET like your example is showing. This, agreed, is already fubar. The risk here is information disclosure.
Yes, you can get a browser to access a resource through an img tag, borrowing the host’s cookies and thus its identity, but you’re *never* going to get the contents and send it to evilsite.com, so there is no possible information disclosure here.
Now do the same thing with the access-control specs and a poorly configured server, and you can get that contents which was previously not accessible. We’re not denying that the new feature is being misused in this case but as I understand it the argument is whether the specs opens possibilities of new attacks or not however badly the server is configured. It does.

How much confusion there has been in this argument just shows that even specialists in the field can get confused, so it means that the average user has a high probability of getting it wrong and opening what he shouldn’t without realizing what they’re doing.

I’m fine adding that to the thread but I’m afraid the IE team won’t comment at this point.

From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: Tuesday, January 15, 2008 3:02 PM
To: OpenAjax Alliance Security Task Force
Subject: Re: [OpenAjaxSecurity] Anyone care to comment on latest CSRF discussion about Access Control


Hi Bertrand,
Actually, Anne is a he. (Dutch, I believe.)

His point about <img>,<script> and <form> is that if a web service works with GET, then you could invoke the CSRF-vulnerable web service via something like:

<img width="0" height="0" src="http://example.com/reset_password.asp?new_email_address=badboy@evil.com&new_password=gotcha"/>

So, they are saying that because some web services are designed poorly today such that they are vulnerable to CSRF attacks *and* allow data upload via GET parameters to <img>, then what's the big deal about opening up a (what they believe is) a tiny new CSRF attack vector via XMLHttpRequest where method=POST, especially given the (what they believe is) critical requirement that cookies be sent with the cross-domain request. Personally, I don't buy this line of reasoning. I don't think we should allow a new browser feature which extends the ability for site A to send cookies up to site B, especially when that feature is specifically defined to work with POST. If site B wants to share the information that it stores in cookies with a different site, then there are other mechanisms that can be used.

At the moment, I am outnumbered on the W3C mailing list. It would be helpful if the IE team offered up some opinions on the W3C mailing list.

Jon



[cid:image001.gif at 01C8578C.2F991A60]Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
Sent by: security-bounces at openajax.org

01/15/2008 11:38 AM
Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org>



To


OpenAjax Alliance Security Task Force <security at openajax.org>


cc




Subject


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








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/>_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080115/30153fb6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
Url : http://openajax.org/pipermail/security/attachments/20080115/30153fb6/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 168 bytes
Desc: image003.png
Url : http://openajax.org/pipermail/security/attachments/20080115/30153fb6/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
Url : http://openajax.org/pipermail/security/attachments/20080115/30153fb6/attachment-0003.png 


More information about the security mailing list