If you are going to consider requiring a preflight request where the server
has to explicitly opt-in to custom headers before custom headers will be
sent, how about requiring a preflight request where the server has to
explicitly opt-in to cookies before cookies will be sent? That would help
address the accountability issue that has been discussed recently.

Jon



                                                                       
             "Anne van                                                 
             Kesteren"                                                 
             <[EMAIL PROTECTED]                                          To
             >                         "Mark Baker" <[EMAIL PROTECTED]>  
             Sent by:                                                   cc
             public-appformats         "mike amundsen" <[EMAIL PROTECTED]>,
             [EMAIL PROTECTED]           "John Panzer" <[EMAIL PROTECTED]>,
                                       "Jonas Sicking" <[EMAIL PROTECTED]>,
                                       [email protected]        
             02/19/2008 06:56                                      Subject
             AM                        Re: CSR and Mozilla - Clarifying
                                       HTTP Header Filtering           
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       





On Tue, 19 Feb 2008 15:33:02 +0100, Mark Baker <[EMAIL PROTECTED]> wrote:
> On 2/19/08, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
>> On Tue, 19 Feb 2008 05:21:12 +0100, Mark Baker <[EMAIL PROTECTED]> wrote:
>> > http://lists.w3.org/Archives/Public/public-webapi/2006May/0008.html
>>
>> No, these are completely different cases. What you're referring to is ok
>> for same-origin requests and is what the same-origin requests still
>> allow.
>> Non same-origin requests probably require a different policy though.
>
> I think it's the same case.  The issue in both cases is that the
> script should always be subordinate to the user agent whose job it is
> to ensure that the messages it sends are valid HTTP messages that
> don't misrepresent either the user or its own capabilities.

The issue is that cross-site requests that are possible today for GET do
not involve arbitrary headers made up by the author. Therefore servers
could be vulnerable to cross-site GET requests that do have arbitrary
headers set. This is a new attack vector and has nothing to do with the
same-origin blacklist.

Having said that, Henri Sivonen suggested that for cross-site GET requests

where the author has provided new headers the preflight OPTIONS could also

be performed. You'd basically get

   if method == GET && !authorHeaders:
      crossSiteRequest()
   else:
      crossSiteRequestWithPreflight()


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

<<inline: graycol.gif>>

<<inline: pic14686.gif>>

<<inline: ecblank.gif>>

Reply via email to