XHR LC Draft Feedback

[Sunava Dutta]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Good to see the draft move to LC.

 

·         Removed dependency on DOM Level 3 Events

·         Removed dependency on Window Object 1.0

·         Clearly marked which HTTP methods are to raise SECURITY_ERR

 

Thanks for the changes.

 

 

I noticed the draft (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) has called out the restricted headers. This is great.

Perhaps it would be helpful to mention for each header, why they are restricted. It will help developers (and others concerned who are not security savvy) understand the security philosophy and also help to ensure that headers of equivalent function with different names are also submitted for consideration in this blocked list. (I don’t have any that comes to mind currently).

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# [phone]

FAX# [phone]

 

[Sunava Dutta]

Some parts of this message have been removed. Learn more about Nabble's security policy.

May I also suggest protecting Access-Control-Origin (since it’s essentially a variant of the referer?).

This is for setRequestHeader of course.

 

So essentially summarizing my two requests for your convenience.

1.       Mentioning for each header the reasons for restriction. (I think security is paramount but for shipped implementations I would hesitate to reduce surface area of attack unless there is a compelling reason. It’s much harder to restrict once we ship!)

2.       Protecting Access-Control-Origin header from being set in XHR.

Cheers and thank you!

 

From: public-webapi-request@... [mailto:public-webapi-request@...] On Behalf Of Sunava Dutta
Sent: Tuesday, April 15, 2008 2:59 PM
To: Anne van Kesteren
Cc: public-webapi@...; Gideon Cohn; Ahmed Kamel; Zhenbin Xu; Doug Stamper
Subject: XHR LC Draft Feedback

 

Good to see the draft move to LC.

 

·         Removed dependency on DOM Level 3 Events

·         Removed dependency on Window Object 1.0

·         Clearly marked which HTTP methods are to raise SECURITY_ERR

 

Thanks for the changes.

 

 

I noticed the draft (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) has called out the restricted headers. This is great.

Perhaps it would be helpful to mention for each header, why they are restricted. It will help developers (and others concerned who are not security savvy) understand the security philosophy and also help to ensure that headers of equivalent function with different names are also submitted for consideration in this blocked list. (I don’t have any that comes to mind currently).

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# [phone]

FAX# [phone]

 

[Anne van Kesteren-2]

On Fri, 18 Apr 2008 03:00:46 +0200, Sunava Dutta  
<sunavad@...> wrote:
> So essentially summarizing my two requests for your convenience.
>
> 1.       Mentioning for each header the reasons for restriction. (I  
> think security is paramount but for shipped implementations I would  
> hesitate to reduce surface area of attack unless there is a compelling  
> reason. It's much harder to restrict once we ship!)

The restrictions on allowed headers have come forth based on  
implementation feedback from Opera, Apple, and Mozilla. If you have  
feedback that suggests the list of headers should be different, please let  
us know.


> 2.       Protecting Access-Control-Origin header from being set in XHR.
> Cheers and thank you!

I agree that Access-Control-Origin needs to be blocked, but shouldn't we  
add this header in XMLHttpRequest Level 2? Adding it in XMLHttpRequest  
Level 1 seems slightly odd, though I don't feel strongly either way.


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

[Sunava Dutta]

Comments inline. Thanks,

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@...]
> Sent: Monday, May 12, 2008 8:12 AM
> To: Sunava Dutta
> Cc: public-webapi@...; Gideon Cohn; Ahmed Kamel; Zhenbin Xu; Doug
> Stamper
> Subject: Re: XHR LC Draft Feedback
>
> On Fri, 18 Apr 2008 03:00:46 +0200, Sunava Dutta
> <sunavad@...> wrote:
> > So essentially summarizing my two requests for your convenience.
> >
> > 1.       Mentioning for each header the reasons for restriction. (I
> > think security is paramount but for shipped implementations I would
> > hesitate to reduce surface area of attack unless there is a compelling
> > reason. It's much harder to restrict once we ship!)
>
> The restrictions on allowed headers have come forth based on
> implementation feedback from Opera, Apple, and Mozilla. If you have
> feedback that suggests the list of headers should be different, please let
> us know.

[Sunava Dutta] Ah, sorry I'm not being clear. What I'm asking for is the reasons for why the headers are blocked (based on implementation feedback, but what is the feedback per blocked header?) to be called out for each header in the spec. Otherwise it seems arbitrary.
>
>
> > 2.       Protecting Access-Control-Origin header from being set in XHR.
> > Cheers and thank you!
>
> I agree that Access-Control-Origin needs to be blocked, but shouldn't we
> add this header in XMLHttpRequest Level 2? Adding it in XMLHttpRequest
> Level 1 seems slightly odd, though I don't feel strongly either way.
[Sunava Dutta] Having it in XHR L2 is OK with me.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

[Anne van Kesteren-2]

On Mon, 12 May 2008 22:27:05 +0200, Sunava Dutta  
<sunavad@...> wrote:

>> > 1.       Mentioning for each header the reasons for restriction. (I
>> > think security is paramount but for shipped implementations I would
>> > hesitate to reduce surface area of attack unless there is a compelling
>> > reason. It's much harder to restrict once we ship!)
>>
>> The restrictions on allowed headers have come forth based on
>> implementation feedback from Opera, Apple, and Mozilla. If you have
>> feedback that suggests the list of headers should be different, please  
>> let us know.
>
> [Sunava Dutta] Ah, sorry I'm not being clear. What I'm asking for is the  
> reasons for why the headers are blocked (based on implementation  
> feedback, but what is the feedback per blocked header?) to be called out  
> for each header in the spec. Otherwise it seems arbitrary.

I see. (Your original message seemed to imply the list was not correct.)  
To be honest, and as I've stated in my reply to Julian, I'm not sure what  
the rationale is for some of them. Hopefully implementors can chime in on  
this thread and provide feedback for why each of the headers listed in  
setRequestHeader() is blocked.

I'm not sure if that information should be included in the specification  
itself though. Generally that's not done in specifications as far as I can  
tell.


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

[Adam Barth-2]

On Mon, May 12, 2008 at 8:11 AM, Anne van Kesteren <annevk@...> wrote:
> > 2.       Protecting Access-Control-Origin header from being set in XHR.
> > Cheers and thank you!
>
>  I agree that Access-Control-Origin needs to be blocked, but shouldn't we
> add this header in XMLHttpRequest Level 2? Adding it in XMLHttpRequest Level
> 1 seems slightly odd, though I don't feel strongly either way.

One option is to rename the header "Sec-Origin", which is already
blocked in XHR Level 1.

Adam

[Julian Reschke]

Anne van Kesteren wrote:
> I see. (Your original message seemed to imply the list was not correct.)
> To be honest, and as I've stated in my reply to Julian, I'm not sure
> what the rationale is for some of them. Hopefully implementors can chime
> in on this thread and provide feedback for why each of the headers
> listed in setRequestHeader() is blocked.

Right. On the other hand, if nobody can explain why a particular header
is on that list, it should be removed.

> I'm not sure if that information should be included in the specification
> itself though. Generally that's not done in specifications as far as I
> can tell.

I'd say it's done in well-written specs.

BR, Julian

[Anne van Kesteren-2]

On Tue, 13 May 2008 07:42:59 +0200, Adam Barth  
<public-webapi@...> wrote:
> One option is to rename the header "Sec-Origin", which is already
> blocked in XHR Level 1.

True, but I think Access-Control-Origin is better as it more clearly  
indicates what it is related to. And since we can safely do it given that  
cross-site requests won't work for XMLHttpRequest until Access Control is  
implemented I think it's acceptable.


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

[Anne van Kesteren-2]

On Sat, 24 May 2008 10:32:03 +0200, Anne van Kesteren <annevk@...>  
wrote:
> On Tue, 13 May 2008 07:42:59 +0200, Adam Barth  
> <public-webapi@...> wrote:
>> One option is to rename the header "Sec-Origin", which is already
>> blocked in XHR Level 1.
>
> True, but I think Access-Control-Origin is better as it more clearly  
> indicates what it is related to. And since we can safely do it given  
> that cross-site requests won't work for XMLHttpRequest until Access  
> Control is implemented I think it's acceptable.

It has been suggested that having an "Origin" header instead of  
"Access-Control-Origin" would be useful in other contexts as well. That  
browsers could always include this as it does not have the privacy issue  
the "Referer" header has (does not include the path) and could therefore  
be used for Access Control but also to prevent CSRF.

I'm not really sure whether that is a good idea, but you (Adam) and Collin  
can hopefully weigh in on that. :-)


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

[Thomas Roessler]

On 2008-05-24 10:57:03 +0200, Anne van Kesteren wrote:

> It has been suggested that having an "Origin" header instead of
> "Access-Control-Origin" would be useful in other contexts as
> well. That browsers could always include this as it does not have
> the privacy issue the "Referer" header has (does not include the
> path) and could therefore be used for Access Control but also to
> prevent CSRF.

Incidentally, +1 to "Origin" - for two reasons:

(a) it might indeed turn out to be more generally useful
(b) it's much less of a mouthful than Access-Control-Origin

--
Thomas Roessler, W3C  <tlr@...>

[Adam Barth-2]

On Sat, May 24, 2008 at 1:57 AM, Anne van Kesteren <annevk@...> wrote:

> On Sat, 24 May 2008 10:32:03 +0200, Anne van Kesteren <annevk@...>
> wrote:
> It has been suggested that having an "Origin" header instead of
> "Access-Control-Origin" would be useful in other contexts as well. That
> browsers could always include this as it does not have the privacy issue the
> "Referer" header has (does not include the path) and could therefore be used
> for Access Control but also to prevent CSRF.
>
> I'm not really sure whether that is a good idea, but you (Adam) and Collin
> can hopefully weigh in on that. :-)

You can find a lot of articles written by people who are sad they
can't use the HTTP Referer header to prevent CSRF.  The two main
issues with using the Referer header are (1) an attacker can easily
suppress the header (for example by issuing the cross-site request
from an FTP URL) and (2) legitimate requests often lack the header.

Collin and I tested issue (2) experimentally by running a web
advertisement that issued a number of network requests to our servers,
and we observed that, indeed, the Referer header is often missing for
HTTP requests (although it is almost always present for HTTPS
requests).  Here are two charts summarizing our observations:

http://crypto.stanford.edu/~abarth/research/webapi/referer/

The data seems to indicate that the Referer header is most often
suppressed in the network layer due to privacy concerns.  We think the
header is suppressed in the network layer because the
document.referrer value is very often not suppressed (browser-layer
suppression preferences block both the header and document.referrer),
and the header is often not suppressed over HTTPS.  The evidence that
the header is suppressed for privacy reasons is that the header is
suppressed much less often for same-site requests than for cross-site
requests.

We suggest that user agents attach an Origin header to POST requests.
This balances the security benefits of easy CSRF protection with the
privacy costs.  If user agents attached this header, sites could
protect themselves from CSRF by (2) undertaking state-modify actions
only in response to POST requests and (2) implementing the below web
application firewall rule (e.g., ModSecurity rule):

SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,status:403
SecRule REQUEST_METHOD ^POST$ chain,deny,status:403
SecRule REQUEST_HEADERS:Origin !^(https?://www\.example\.com(:\d+)?)?$

People often suggest that we should attach the Origin header to GET
requests as well as POST requests.  This increases the security
benefits of the proposal, but it also increases the privacy cost
because the header would then be sent for every hyperlink click.  Many
organizations suppress the Referer header at their network boundary to
prevent external sites from learning the structure of their internal
network.  While the Origin header does not include the path (and thus
reveals much less information), the names of internal hosts might
still be sensitive.  We think restricting the header to POST requests
will discourage these organizations from suppressing the header
because it is much less common for an internal site to POST to an
external site (compared with how common it is for an internal site to
hyperlink to an external site).

Of course, XHR2 could use the Access-Control-Origin header and this
proposal could use the Origin header, but the two are conceptually
very similar and it might be worthwhile to use the same header name.

Adam

[Anne van Kesteren-2]

On Sat, 24 May 2008 20:48:00 +0200, Adam Barth  
<public-webapi@...> wrote:

> People often suggest that we should attach the Origin header to GET
> requests as well as POST requests.  This increases the security
> benefits of the proposal, but it also increases the privacy cost
> because the header would then be sent for every hyperlink click.  Many
> organizations suppress the Referer header at their network boundary to
> prevent external sites from learning the structure of their internal
> network.  While the Origin header does not include the path (and thus
> reveals much less information), the names of internal hosts might
> still be sensitive.  We think restricting the header to POST requests
> will discourage these organizations from suppressing the header
> because it is much less common for an internal site to POST to an
> external site (compared with how common it is for an internal site to
> hyperlink to an external site).

Interesting. I note that for cross-site requests using Access Control  
(XMLHttpRequest, server-sent events, XSLT, XBL, and maybe more later...)  
we need this Origin header to always function. Also for GET requests.  
(Though these GET requests are distinct from the ones you get from <a> in  
that the response data is somehow exposed to the origin from which the  
request originated if the third party agrees.)

Having said that, if Access Control becomes successful disabling Origin  
would break major sites so maybe it's not much of an issue.


> Of course, XHR2 could use the Access-Control-Origin header and this
> proposal could use the Origin header, but the two are conceptually
> very similar and it might be worthwhile to use the same header name.

Ok, I'll use Origin.

Thanks!


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

[Jonas Sicking-2]

Anne van Kesteren wrote:

>
> On Sat, 24 May 2008 10:32:03 +0200, Anne van Kesteren <annevk@...>
> wrote:
>> On Tue, 13 May 2008 07:42:59 +0200, Adam Barth
>> <public-webapi@...> wrote:
>>> One option is to rename the header "Sec-Origin", which is already
>>> blocked in XHR Level 1.
>>
>> True, but I think Access-Control-Origin is better as it more clearly
>> indicates what it is related to. And since we can safely do it given
>> that cross-site requests won't work for XMLHttpRequest until Access
>> Control is implemented I think it's acceptable.
>
> It has been suggested that having an "Origin" header instead of
> "Access-Control-Origin" would be useful in other contexts as well. That
> browsers could always include this as it does not have the privacy issue
> the "Referer" header has (does not include the path) and could therefore
> be used for Access Control but also to prevent CSRF.
>
> I'm not really sure whether that is a good idea, but you (Adam) and
> Collin can hopefully weigh in on that. :-)

A similar idea came up when this header was named 'Referer-Root'.
However it was suggested to name the header 'Access-Control-Origin' to
allow servers to easily block all cross-site requests that were done
based on the Access-Control spec.

If the header is simply named 'Origin' (or 'Referer-Root') then blocking
any requests that include that header would also block for example
cross-site image requests or cross-site POSTs.

This can be both good and bad. The good part is that it gives sites a
tool to easily block all third-party requests. The bad part is that it
makes it harder to just block the most dangerous ones, i.e. ones where
the requesting site can read the response.

I suggest we keep Access-Control-Origin as is. A separate 'Origin' spec
seems useful, but I suspect it would be better done as a separate spec.

/ Jonas

[Anne van Kesteren-2]

On Sun, 25 May 2008 23:36:48 +0200, Jonas Sicking <jonas@...> wrote:
> If the header is simply named 'Origin' (or 'Referer-Root') then blocking  
> any requests that include that header would also block for example  
> cross-site image requests or cross-site POSTs.

Right. Given that it's likely we get extensions in the future that allow  
reading the contents of images (<img>.getImageData() or something) or the  
response of a <form> POST (some features in Web Forms 2.0 allow this as  
far as I can tell).


> This can be both good and bad. The good part is that it gives sites a  
> tool to easily block all third-party requests. The bad part is that it  
> makes it harder to just block the most dangerous ones, i.e. ones where  
> the requesting site can read the response.

The response is never revealed unless specified by the server.


> I suggest we keep Access-Control-Origin as is. A separate 'Origin' spec  
> seems useful, but I suspect it would be better done as a separate spec.

I'm not convinced it's worth separating the two.


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

[Anne van Kesteren-2]

On Tue, 13 May 2008 10:40:16 +0200, Julian Reschke <julian.reschke@...>  
wrote:
> Anne van Kesteren wrote:
>> I see. (Your original message seemed to imply the list was not  
>> correct.) To be honest, and as I've stated in my reply to Julian, I'm  
>> not sure what the rationale is for some of them. Hopefully implementors  
>> can chime in on this thread and provide feedback for why each of the  
>> headers listed in setRequestHeader() is blocked.
>
> Right. On the other hand, if nobody can explain why a particular header  
> is on that list, it should be removed.

All the headers on that list are better controlled by the user agent. I  
made the specification more clear on that.

I also made it clear that the user agent is not to set any headers other  
than those on that list and those permitted to be set if the author has  
not set them (as explained under the send() algorithm).


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

[Julian Reschke]

Anne van Kesteren wrote:

>
> On Tue, 13 May 2008 10:40:16 +0200, Julian Reschke
> <julian.reschke@...> wrote:
>> Anne van Kesteren wrote:
>>> I see. (Your original message seemed to imply the list was not
>>> correct.) To be honest, and as I've stated in my reply to Julian, I'm
>>> not sure what the rationale is for some of them. Hopefully
>>> implementors can chime in on this thread and provide feedback for why
>>> each of the headers listed in setRequestHeader() is blocked.
>>
>> Right. On the other hand, if nobody can explain why a particular
>> header is on that list, it should be removed.
>
> All the headers on that list are better controlled by the user agent. I
> made the specification more clear on that.
>
> I also made it clear that the user agent is not to set any headers other
> than those on that list and those permitted to be set if the author has
> not set them (as explained under the send() algorithm).

So, why are the headers below on the list?

     * Accept-Charset
     * Accept-Encoding
     * Expect
     * Referer
     * User-Agent

BR, Julian

[Anne van Kesteren-2]

On Tue, 27 May 2008 14:32:01 +0200, Julian Reschke <julian.reschke@...>  
wrote:
> So, why are the headers below on the list?
>
>      * Accept-Charset
>      * Accept-Encoding
>      * Expect
>      * Referer
>      * User-Agent

Because they are better handled by the user agent. Charsets and encodings  
are transparent to the API and the user agent surely knows Referer and  
User-Agent better.


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

[Julian Reschke]

Anne van Kesteren wrote:

>
> On Tue, 27 May 2008 14:32:01 +0200, Julian Reschke
> <julian.reschke@...> wrote:
>> So, why are the headers below on the list?
>>
>>      * Accept-Charset
>>      * Accept-Encoding
>>      * Expect
>>      * Referer
>>      * User-Agent
>
> Because they are better handled by the user agent. Charsets and
> encodings are transparent to the API and the user agent surely knows
> Referer and User-Agent better.

I don't see why the client shouldn't be able to select a particular
character set or encoding, even if it doesn't make a difference from the
API point of view *for now* (it may when when we allow binary access).

But even now it may make sense to request a particular character set;
for instance, if the object is plain text, but the UA selects a default
character set that does not allow specific characters.

I also don't see why the client shouldn't have the option to set the
Expect header; keep in mind that although 100-continue is the only
expectation code defined in RFC2616, other codes can be defined as well,
and it's not XHR's business to close that door.

Setting the user agent may be necessary when a server makes bad choices
with respect to UA sniffing; for instance I have seen servers returning
an HTML login form to things that identify themselves as IE, instead of
doing HTTP auth.

For something to be on the black list, you really need really strong
arguments.

BR, Julian

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>I also don't see why the client shouldn't have the option to set the
>Expect header; keep in mind that although 100-continue is the only
>expectation code defined in RFC2616, other codes can be defined as well,
>and it's not XHR's business to close that door.

I think whether the client uses `Expect: 100-continue` is a decision
similar to deciding whether the client uses, say, a Transfer-Encoding.
The client may also be specifically configured to use a different
version of the protocol, like IE is configured to talk HTTP/1.0 to
proxy servers by default. Besides, the client may not even handle the
100-continue response properly.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Julian Reschke]

Bjoern Hoehrmann wrote:

> * Julian Reschke wrote:
>> I also don't see why the client shouldn't have the option to set the
>> Expect header; keep in mind that although 100-continue is the only
>> expectation code defined in RFC2616, other codes can be defined as well,
>> and it's not XHR's business to close that door.
>
> I think whether the client uses `Expect: 100-continue` is a decision
> similar to deciding whether the client uses, say, a Transfer-Encoding.
> The client may also be specifically configured to use a different
> version of the protocol, like IE is configured to talk HTTP/1.0 to
> proxy servers by default. Besides, the client may not even handle the
> 100-continue response properly.

What about "Expect: foobar"?

BR, Julian