W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [cors] Possible need for a "Destination" Header

From: Mike Chack (mchack) <mchack@cisco.com>
Date: Tue, 17 Feb 2009 08:46:30 -0800
Message-ID: <7FE6845B1F8A264E9E03562D7EBB225C07602E9C@xmb-sjc-22b.amer.cisco.com>
To: "Anne van Kesteren" <annevk@opera.com>, <public-webapps@w3.org>
You are correct that there are a number of other means in information
can be coopted. So trying to limit access via the originating site would
essentially be useless.


Mike Chack 
O: +1 408.526.4639 
M: +1 408.504.6594 

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@opera.com] 
Sent: Tuesday, February 17, 2009 3:23 AM
To: Mike Chack (mchack); public-webapps@w3.org
Subject: Re: [cors] Possible need for a "Destination" Header

On Mon, 16 Feb 2009 18:14:10 +0100, Mike Chack (mchack)
> Unless I am missing something, there seems to be a security hole with
> the current proposal. If a site has been hacked then malicous code can
> send content to any site that abides by the access control policies.
> is up to the destination site to accept the request, and in the case
> a nefarious destination, would most certainly do so. Wouldn't it also
> make sense to have some policy control from the origination site that
> would limit where requests could be made. This could be done in the
> of a "Desitnation" Header that would give more control over where
> XmlHttp requests could be directed.

I'm not sure I follow. If a site has been hacked, why would it still  
control the "Destination" header? Note that if a site is hacked and
to distribute data to evilpartner.com it already has lots of ways to do

that e.g. through <img src>, <form action>, <iframe src>, etc.

Anne van Kesteren
Received on Tuesday, 17 February 2009 16:53:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:51 UTC