W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: Security-sensitive headers

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 19 Feb 2008 10:10:52 +0100
To: "Collin Jackson" <collinj@cs.stanford.edu>, public-webapi@w3.org
Cc: "Adam Barth" <abarth@cs.stanford.edu>
Message-ID: <op.t6rk4ezp64w2qv@annevk-t60.oslo.opera.com>

On Tue, 19 Feb 2008 02:21:31 +0100, Collin Jackson  
<collinj@cs.stanford.edu> wrote:
> Approach 1: Create a prefix denoting headers that are determined by
> the user agent and cannot be overwritten by unprivileged JavaScript.
> For example, "UA-" or "Sec-". This is the approach we prefer.

Given that older clients and malicious clients will be vulnarable why is  
that not a problem going forward? I'm fine with doing this though.

> [...] but under the current
> specification we'd have to chose a header name that starts with
> "Proxy-". There have been many other proposals for new
> security-related HTTP headers (e.g. content restrictions) so it would
> be nice to solve this issue in general.

Comments like this do encourage me to introduce "Sec-" so we don't get a  
whole bunch of fake "Proxy-" headers. (Note that not all clients blaclist  
everything "Proxy-" yet.)

> Another related issue that would be good to standardize is the
> handling of the Cookie header. Internet Explorer 6 and 7 doesn't
> appear to allow Cookies to be set using XMLHttpRequest at all. Firefox
> 2 allows pages to use XMLHttpRequest to set a Cookie header, but
> merges the user-set header with the user agent header:
> Cookie: [actual cookies values]; [user-set Cookie header value]
> I've heard some arguments for removing Cookies from cross-site
> XMLHttpRequests, which indicates to me that the Cookie header might be
> a good candidate for adding to the security-sensitive list.

What are those arguments?

Anne van Kesteren
Received on Tuesday, 19 February 2008 09:06:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC