RE: ISSUE 19: Requirements and Usage Scenarios document

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.


             "David Orchard"                                               
             >                                                          To 
             Sent by:                  Jon Ferraiolo/Menlo Park/IBM@IBMUS  
             public-appformats                                          cc 
              "Anne van Kesteren"                 
                                       <>, "WAF WG         
             01/15/2008 10:00          <>,         
             AM                        <>  
                                       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.


 From: Jon Ferraiolo []
 Sent: Tuesday, January 15, 2008 9:46 AM
 To: David Orchard
 Cc: Anne van Kesteren; WAF WG (public);
 Subject: RE: ISSUE 19: Requirements and Usage Scenarios document

 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.


 Inactive hide details for "David Orchard" <>"David
 Orchard" <>

                         Sent by:                                          
                         public-ap           "Anne van Kesteren"           
                         pformats-           <>, Jon       
                         request@w           Ferraiolo/Menlo               
                         8 08:44             "WAF WG (public)"             
                         AM                  <>    
                                             RE: ISSUE 19: Requirements    
                                             and Usage Scenarios document  


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


 > -----Original Message-----
 > From:
 > [] 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 <>
 > wrote:
 > > I described a CSRF scenario in
 > >
 > > 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
 > <>
 > <>

Received on Tuesday, 15 January 2008 18:49:41 UTC