- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Tue, 15 Jan 2008 10:29:21 -0800
- To: "David Orchard" <dorchard@bea.com>
- Cc: "Anne van Kesteren" <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>, public-appformats-request@w3.org
- Message-ID: <OFD100B4C2.CC08C228-ON882573D1.0065627D-882573D1.006590AE@us.ibm.com>
But wouldn't it be better if the functionality were made available without introducing a new attack vector? I would suggest that the objective be to satisfy the functionality requirements that are dictated by the use cases, and if possible choose a technical approach that does not introduce new attack vectors. Jon "David Orchard" <dorchard@bea.com > To Sent by: Jon Ferraiolo/Menlo Park/IBM@IBMUS public-appformats cc -request@w3.org "Anne van Kesteren" <annevk@opera.com>, "WAF WG (public)" 01/15/2008 10:00 <public-appformats@w3.org>, AM <public-appformats-request@w3.org> Subject RE: ISSUE 19: Requirements and Usage Scenarios document I thought from your note that this was opening up a new attack vector but that was acceptable because the functionality that results in the vector is so desirable. Cheers, Dave From: Jon Ferraiolo [mailto:jferrai@us.ibm.com] Sent: Tuesday, January 15, 2008 9:46 AM To: David Orchard Cc: Anne van Kesteren; WAF WG (public); public-appformats-request@w3.org Subject: RE: ISSUE 19: Requirements and Usage Scenarios document David, Wouldn't it be simpler to just say "no new attack vectors" rather than attempt to find wording that says "aren't already similar..."? If it's a new attack vector, I don't think it matters whether it is similar to something that already exists. Jon Inactive hide details for "David Orchard" <dorchard@bea.com>"David Orchard" <dorchard@bea.com> "David Orchard" <dorchard @bea.com> To Sent by: public-ap "Anne van Kesteren" pformats- <annevk@opera.com>, Jon request@w Ferraiolo/Menlo 3.org Park/IBM@IBMUS cc 01/15/200 8 08:44 "WAF WG (public)" AM <public-appformats@w3.org> Subject RE: ISSUE 19: Requirements and Usage Scenarios document Anne, If Cookies would be sent as part of more requests because of deployment of the Access Control spec, then isn't this spec opening a new attack vector? I understand your point that cookies are already sent under img, script and form, but this is something newer and in addition to those. I think one of the rough requirements we have is no new attack vectors. Now maybe that requirement ought to be something like "no new attack vectors that aren't already similar to current attack vectors such as cookies under img, script and form". Cheers, Dave > -----Original Message----- > From: public-appformats-request@w3.org > [mailto:public-appformats-request@w3.org] On Behalf Of Anne > van Kesteren > Sent: Tuesday, January 15, 2008 7:53 AM > To: Jon Ferraiolo > Cc: WAF WG (public) > Subject: Re: ISSUE 19: Requirements and Usage Scenarios document > > > On Tue, 15 Jan 2008 15:20:46 +0100, Jon Ferraiolo <jferrai@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/> > >
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic28361.gif
- image/gif attachment: ecblank.gif
- image/gif attachment: 0C846402.gif
- image/gif attachment: 0C324068.gif
Received on Tuesday, 15 January 2008 18:49:41 UTC