W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: ISSUE 19: Requirements and Usage Scenarios document

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 16 Jan 2008 11:59:14 +0100
To: "Jon Ferraiolo" <jferrai@us.ibm.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <op.t40rg0oi64w2qv@annevk-t60.oslo.opera.com>

On Wed, 16 Jan 2008 01:34:08 +0100, Jon Ferraiolo <jferrai@us.ibm.com>  
> If we are still talking about <img>, <script>, etc, then I would argue  
> that the type of the request isn't identical because these are GET  
> requests,
> whereas the scenario I described is a POST request. So, if a server only
> supports POST for data insert/update/delete operations (which is
> recommended best practice, therefore a good number of sites will do  
> this), then <img> and <script> cannot do any harm.

Before you can even issue a POST the server first needs to reply to a  
preflicht OPTIONS request in the right way. (The access control POST is  
therefore a whole lot more secure than a the <form> POST we already have.  
Even though they are almost identical.)

> Also, with
> Access-Control-powered XHR, meaningful data can be retrieved from the
> other-domain server leveraging any cookies that apply to the other  
> domain,

Cookies in the response are not exposed. Please carefully study the  

> whereas with <img> the JavaScript will not receive any data and with
> <script> data can only be received if it is formatted as JSON (or other
> JavaScript). Therefore, there are indeed new opportunities for doing bad
> things, including new CSRF opportunities, because the current draft says
> the browser should send cookies.

Cookies are sent in the request, yes. The cookies in the response are not  
exposed. The response itself is protected by the opt-in access control  

Anne van Kesteren
Received on Wednesday, 16 January 2008 11:01:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC