- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Wed, 02 Dec 2009 12:19:08 -0800
- To: W3C Web Security Interest Group <public-web-security@w3.org>
Since we're apparently moving this discussion over to this list...
The (old) original thread on ietf-http-wg@w3.org is rooted here (just for
reference)..
HTTPbis and the Same Origin Policy
http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0229.html
..and all the messages up thru Joe Gregorio's from Tue 1-Dec are included by
value below for convenience.
=JeffH
------- Forwarded Messages
Date: Wed, 25 Nov 2009 07:39:51 -0800
From: Tyler Close <tyler.close@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: HTTPbis and the Same Origin Policy
AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
this policy is a major constraint on the behavior of many HTTP user
agents, restricting what HTTP requests can be sent and what HTTP
responses can be delivered. SOP is not defined by any standard. Should
HTTPbis step up?
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 2
Date: Wed, 25 Nov 2009 16:50:40 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: Tyler Close <tyler.close@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
Tyler Close wrote:
> AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
> this policy is a major constraint on the behavior of many HTTP user
> agents, restricting what HTTP requests can be sent and what HTTP
> responses can be delivered. SOP is not defined by any standard. Should
> HTTPbis step up?
> ...
Well, HTTPbis (as WG and set of specs) is really constrained in what
we're doing, see <http://www.ietf.org/dyn/wg/charter/httpbis-charter>.
And that's a good thing, because an open-ended charter would make it
likely that we never finish.
That being said, defining this in a spec probably *is* a good idea. Did
you just volunteer? Note that to produce a spec you actual IETF WG is
required.
BR, Julian
------- Message 3
Date: Wed, 25 Nov 2009 17:16:49 +0100
From: Julian Reschke <julian.reschke@gmx.de>
To: Tyler Close <tyler.close@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
Julian Reschke wrote:
> Tyler Close wrote:
>> AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
>> this policy is a major constraint on the behavior of many HTTP user
>> agents, restricting what HTTP requests can be sent and what HTTP
>> responses can be delivered. SOP is not defined by any standard. Should
>> HTTPbis step up?
>> ...
>
> Well, HTTPbis (as WG and set of specs) is really constrained in what
> we're doing, see <http://www.ietf.org/dyn/wg/charter/httpbis-charter>.
> And that's a good thing, because an open-ended charter would make it
> likely that we never finish.
>
> That being said, defining this in a spec probably *is* a good idea. Did
> you just volunteer? Note that to produce a spec you actual IETF WG is
> required.
s/you/no/
Br, Julian
------- Message 4
Date: Wed, 25 Nov 2009 09:27:46 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Tyler Close wrote:
>>
>> AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
>> this policy is a major constraint on the behavior of many HTTP user
>> agents, restricting what HTTP requests can be sent and what HTTP
>> responses can be delivered. SOP is not defined by any standard. Should
>> HTTPbis step up?
>> ...
>
> Well, HTTPbis (as WG and set of specs) is really constrained in what we're
> doing, see <http://www.ietf.org/dyn/wg/charter/httpbis-charter>. And that's
> a good thing, because an open-ended charter would make it likely that we
> never finish.
Quoting from the charter:
"""
The working group will refine RFC2616 to:
...
* Document the security properties of HTTP and its associated
echanisms (e.g., Basic and Digest authentication, cookies, TLS) for
common applications
"""
Given that charter, it's hard to see how the WG can escape documenting
the Same Origin Policy. It is a necessary part of how common
applications use HTTP Auth, cookies and even unadorned HTTP requests
and responses.
> That being said, defining this in a spec probably *is* a good idea. Did you
> just volunteer? Note that to produce a spec you actual IETF WG is required.
;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
least. Documenting SOP is a *big* task. I understand why it makes you
worry about slipping deadlines. So, should the charter be revised to
exclude the primary security policy that governs use of HTTP? ;)
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 5
Date: Wed, 25 Nov 2009 18:46:15 +0100
From: Thomas Roessler <tlr@w3.org>
To: Tyler Close <tyler.close@gmail.com>
cc: Thomas Roessler <tlr@w3.org>,
Doug Schepers <schepers@w3.org>,
HTTP Working Group <ietf-http-wg@w3.org>,
Anne van Kesteren <annevk@opera.com>,
Ian Hickson <ian@hixie.ch>,
"Michael(tm) Smith" <mike@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
Much of this material is in fact part of the HTML5 and XMLHttpRequest =
specifications.
The XMLHttpRequest specification is in Last Call as of 19 November (with =
16 December deadline), and it includes a specification of the same =
origin policy for XMLhttpRequest -- see step 13 of the open() method =
[1].
http://www.w3.org/TR/XMLHttpRequest/#the-open-method
I'll note that that specification lacks any security considerations at =
this point, and that calling out the same origin policy more prominently =
(and talking about DNS rebinding) sound like they would be fine and =
timely additions to that spec.
Additionally, I suspect that in-depth review from the HTTP Working Group =
would be an extremely valuable for this spec.
HTML5 defines a number of relevant policies:
http://dev.w3.org/html5/spec/Overview.html#security
http://dev.w3.org/html5/spec/Overview.html#security-1
http://dev.w3.org/html5/spec/Overview.html#security-2
=
http://dev.w3.org/html5/spec/Overview.html#relaxing-the-same-origin-restri=
ction
=
http://dev.w3.org/html5/spec/Overview.html#security-and-privacy-considerat=
ions
=
http://dev.w3.org/html5/spec/Overview.html#security-with-canvas-elements
There are a few more places. Unfortunately, the easiest way to identify =
all cases in which HTML5 explicitly specifies a security policy seems to =
be searching for the "SECURITY_ERR" exception.
Regards,
- --
Thomas Roessler, W3C <tlr@w3.org>
On 25 Nov 2009, at 16:39, Tyler Close wrote:
> AFAICT, HTTPbis says nothing about the Same Origin Policy (SOP), yet
> this policy is a major constraint on the behavior of many HTTP user
> agents, restricting what HTTP requests can be sent and what HTTP
> responses can be delivered. SOP is not defined by any standard. Should
> HTTPbis step up?
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
>
------- Message 6
Date: Wed, 25 Nov 2009 12:26:28 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 9:27 AM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de> wrote
:
>> That being said, defining this in a spec probably *is* a good idea. Did you
>> just volunteer? Note that to produce a spec you actual IETF WG is required.
>
> ;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
> least. Documenting SOP is a *big* task. I understand why it makes you
> worry about slipping deadlines. So, should the charter be revised to
> exclude the primary security policy that governs use of HTTP? ;)
The same-origin policy is defined here:
http://tools.ietf.org/html/draft-abarth-origin
Adam
------- Message 7
Date: Wed, 25 Nov 2009 12:30:04 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
- --001636e0b727a5fb1d047937edde
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Nov 25, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Nov 25, 2009 at 9:27 AM, Tyler Close <tyler.close@gmail.com> wrote:
>> On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de> wrot
e:
>>> That being said, defining this in a spec probably *is* a good idea. Did you
>>> just volunteer? Note that to produce a spec you actual IETF WG is required.
>>
>> ;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
>> least. Documenting SOP is a *big* task. I understand why it makes you
>> worry about slipping deadlines. So, should the charter be revised to
>> exclude the primary security policy that governs use of HTTP? ;)
>
> The same-origin policy is defined here:
>
> http://tools.ietf.org/html/draft-abarth-origin
Actually, that draft is out of date. I've just uploaded a new draft,
which I've also attached to this message.
Adam
[ attached spec elided. see: http://tools.ietf.org/html/draft-abarth-origin
specifically, -06 is the rev Adam is referring to above. ]
------- Message 8
Date: Wed, 25 Nov 2009 13:18:37 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 12:30 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Nov 25, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Wed, Nov 25, 2009 at 9:27 AM, Tyler Close <tyler.close@gmail.com> wro=
te:
>>> On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de>=
wrote:
>>>> That being said, defining this in a spec probably *is* a good idea. Di=
d you
>>>> just volunteer? Note that to produce a spec you actual IETF WG is requ=
ired.
>>>
>>> ;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
>>> least. Documenting SOP is a *big* task. I understand why it makes you
>>> worry about slipping deadlines. So, should the charter be revised to
>>> exclude the primary security policy that governs use of HTTP? ;)
>>
>> The same-origin policy is defined here:
>>
>> http://tools.ietf.org/html/draft-abarth-origin
>
> Actually, that draft is out of date. =A0I've just uploaded a new draft,
> which I've also attached to this message.
That I-D defines an identifier for an origin, but not the Same Origin
Policy. For example, what document says: a HTTP PUT request cannot be
sent cross-origin.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 9
Date: Wed, 25 Nov 2009 13:25:40 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 1:18 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 12:30 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Wed, Nov 25, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> On Wed, Nov 25, 2009 at 9:27 AM, Tyler Close <tyler.close@gmail.com> wr=
ote:
>>>> On Wed, Nov 25, 2009 at 7:50 AM, Julian Reschke <julian.reschke@gmx.de=
> wrote:
>>>>> That being said, defining this in a spec probably *is* a good idea. D=
id you
>>>>> just volunteer? Note that to produce a spec you actual IETF WG is req=
uired.
>>>>
>>>> ;) No, I wasn't trying to throw myself on that grenade. ;) Not yet at
>>>> least. Documenting SOP is a *big* task. I understand why it makes you
>>>> worry about slipping deadlines. So, should the charter be revised to
>>>> exclude the primary security policy that governs use of HTTP? ;)
>>>
>>> The same-origin policy is defined here:
>>>
>>> http://tools.ietf.org/html/draft-abarth-origin
>>
>> Actually, that draft is out of date. =A0I've just uploaded a new draft,
>> which I've also attached to this message.
>
> That I-D defines an identifier for an origin, but not the Same Origin
> Policy. For example, what document says: a HTTP PUT request cannot be
> sent cross-origin.
Whether one can send an HTTP PUT request to another origin depends on
which API is being used. For the HTML Form element, the HTML
specification contains this requirement. For the XMLHttpRequest API,
the XMLHttpRequest specification contains the requirement.
The essence of the same-origin policy is the "sameness" relation
(i.e., how to compute it on URLs), which is what's contained in that
draft. The details of what actions are restricted to the "same"
origin are details best left to the application layer.
Adam
------- Message 10
Date: Wed, 25 Nov 2009 22:28:58 +0100
From: Thomas Roessler <tlr@w3.org>
To: Tyler Close <tyler.close@gmail.com>
cc: Thomas Roessler <tlr@w3.org>,
Adam Barth <w3c@adambarth.com>,
Julian Reschke <julian.reschke@gmx.de>,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On 25 Nov 2009, at 22:18, Tyler Close wrote:
> That I-D defines an identifier for an origin, but not the Same Origin
> Policy.
It also defines what the "equality" operator in the same-origin policy =
means.
> For example, what document says: a HTTP PUT request cannot be
> sent cross-origin.
XMLHttpRequest, for the purposes of HTTP PUT requests caused through =
that API.
No spec, for form submissions, since the policy doesn't hold for these.
------- Message 11
Date: Wed, 25 Nov 2009 13:34:58 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 1:25 PM, Adam Barth <w3c@adambarth.com> wrote:
> Whether one can send an HTTP PUT request to another origin depends on
> which API is being used. =A0For the HTML Form element, the HTML
> specification contains this requirement. =A0For the XMLHttpRequest API,
> the XMLHttpRequest specification contains the requirement.
>
> The essence of the same-origin policy is the "sameness" relation
> (i.e., how to compute it on URLs), which is what's contained in that
> draft. =A0The details of what actions are restricted to the "same"
> origin are details best left to the application layer.
My impression is that the undefined consensus understanding of the
Same Origin Policy incorporates the rule that no API (not just a
specific API, such as HTML form) can allow a cross-origin PUT, unless
the target resource has somehow opted out of SOP protection. This
rule, and others like it, are the source of much of the complexity in
CORS. These rules are not left to the application layer.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 12
Date: Wed, 25 Nov 2009 13:54:12 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 1:34 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 1:25 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Whether one can send an HTTP PUT request to another origin depends on
>> which API is being used. =A0For the HTML Form element, the HTML
>> specification contains this requirement. =A0For the XMLHttpRequest API,
>> the XMLHttpRequest specification contains the requirement.
>>
>> The essence of the same-origin policy is the "sameness" relation
>> (i.e., how to compute it on URLs), which is what's contained in that
>> draft. =A0The details of what actions are restricted to the "same"
>> origin are details best left to the application layer.
>
> My impression is that the undefined consensus understanding of the
> Same Origin Policy incorporates the rule that no API (not just a
> specific API, such as HTML form) can allow a cross-origin PUT, unless
> the target resource has somehow opted out of SOP protection.
I think you're confusing two things:
1) What is an origin?
2) What restrictions ought we to place on cross-origin interactions?
draft-abarth-origin answers question (1), and the answer to this
question has been quite stable for a while as an equivalence relation
on URL/URI/IRIs. Humorously, the relation has been more stable than
the things it relates!
The answer to question (2) is much less stable and depends on a lot of
application layer issues. For example, consider the HTML Canvas
Element. HTML5 lets you draw an image from an arbitrary origin onto
the canvas, but drawing a cross-origin image changes the behavior of
the toDataURL API.
I don't think there's a way to spec the answer to (2) at the protocol
layer. The restrictions are inherently application-dependent.
> This
> rule, and others like it, are the source of much of the complexity in
> CORS. These rules are not left to the application layer.
Indeed. Security in the application layer is quite complex. That's
what makes life interesting. :)
Adam
------- Message 13
Date: Wed, 25 Nov 2009 13:56:23 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com> wrote:
> I think you're confusing two things:
>
> 1) What is an origin?
> 2) What restrictions ought we to place on cross-origin interactions?
I should also note that the answer to question (2) has very little to
do with HTTP. For example, the restrictions on interacting with
cross-origin images in an HTML Canvas apply just as well when the HTML
document is retrieved over FTP and the image is retrieved over Gopher.
Adam
------- Message 14
Date: Wed, 25 Nov 2009 14:34:03 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Nov 25, 2009 at 1:34 PM, Tyler Close <tyler.close@gmail.com> wrot=
e:
>> My impression is that the undefined consensus understanding of the
>> Same Origin Policy incorporates the rule that no API (not just a
>> specific API, such as HTML form) can allow a cross-origin PUT, unless
>> the target resource has somehow opted out of SOP protection.
>
> I think you're confusing two things:
>
> 1) What is an origin?
> 2) What restrictions ought we to place on cross-origin interactions?
No, I think I understand the difference between a thing and what you
can do with that thing. I think my point comes down to a rephrasing of
2):
2) What restrictions have been placed on cross-origin interactions and
must forever be obeyed by all APIs?
>> This
>> rule, and others like it, are the source of much of the complexity in
>> CORS. These rules are not left to the application layer.
>
> Indeed. =A0Security in the application layer is quite complex. =A0That's
> what makes life interesting. =A0:)
So are you agreeing that there do exist SOP rules that the application
layer must obey? If so, should we document those rules?
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 15
Date: Wed, 25 Nov 2009 15:12:19 -0800
From: Maciej Stachowiak <mjs@apple.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Nov 25, 2009, at 1:34 PM, Tyler Close wrote:
> On Wed, Nov 25, 2009 at 1:25 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Whether one can send an HTTP PUT request to another origin depends on
>> which API is being used. For the HTML Form element, the HTML
>> specification contains this requirement. For the XMLHttpRequest API,
>> the XMLHttpRequest specification contains the requirement.
>>
>> The essence of the same-origin policy is the "sameness" relation
>> (i.e., how to compute it on URLs), which is what's contained in that
>> draft. The details of what actions are restricted to the "same"
>> origin are details best left to the application layer.
>
> My impression is that the undefined consensus understanding of the
> Same Origin Policy incorporates the rule that no API (not just a
> specific API, such as HTML form) can allow a cross-origin PUT, unless
> the target resource has somehow opted out of SOP protection. This
> rule, and others like it, are the source of much of the complexity in
> CORS. These rules are not left to the application layer.
CORS attempts to follow this rule: the only requests that can be
issued cross-origin without explicit opt-in (preflight) are ones that
could have been issued by following a link or submitting a form. It is
assumed that just the ability to issue such a request (without reading
the response) would not create new vulnerabilities. This is the reason
custom methods and headers are not allowed without preflight. It is
also the reason Content-Type is restricted to a small whitelist
without preflight.
In some cases this boundary may be drawn in an overly conservative
way; but preflight is always available as an alternative. In general
this is probably a reasonable rule for new networking facilities. I'm
not sure it's the right answer for every networking API; for example,
WebSocket has a different way to avoid exposing existing servers,
namely requiring a very specific handshake sequence. But the general
principle is to avoid exposing servers to requests that are not
already possible, unless there is explicit opt-in or the source of the
request is same-origin with the server (which is taken as presumptive
opt-in).
Regards,
Maciej
------- Message 16
Date: Thu, 26 Nov 2009 10:17:04 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
To: Tyler Close <tyler.close@gmail.com>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On 2009/11/26 6:34, Tyler Close wrote:
> My impression is that the undefined consensus understanding of the
> Same Origin Policy incorporates the rule that no API (not just a
> specific API, such as HTML form) can allow a cross-origin PUT, unless
> the target resource has somehow opted out of SOP protection. This
> rule, and others like it, are the source of much of the complexity in
> CORS. These rules are not left to the application layer.
If I write something like a webbot, I can execute whatever PUT requests
(or other HTTP requests) I want, or can't I? An API such as libcurl
(http://curl.haxx.se/libcurl/) doesn't contain any such restrictions, or
does it?
Regards, Martin.
- --
#-# Martin J. D=FCrst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
------- Message 17
Date: Wed, 25 Nov 2009 17:55:41 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 2:34 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Indeed. =A0Security in the application layer is quite complex. =A0That's
>> what makes life interesting. =A0:)
>
> So are you agreeing that there do exist SOP rules that the application
> layer must obey? If so, should we document those rules?
Yes. At the application layer.
I'm not even sure you can articulate the policy coherently without
referring to application-layer concepts. How would you explain the
restrictions on images in the HTML Canvas element in terms of HTTP
protocol messages?
Adam
------- Message 18
Date: Mon, 30 Nov 2009 11:00:56 -0800
From: Tyler Close <tyler.close@gmail.com>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 5:17 PM, "Martin J. D=FCrst"
<duerst@it.aoyama.ac.jp> wrote:
> On 2009/11/26 6:34, Tyler Close wrote:
>
>> My impression is that the undefined consensus understanding of the
>> Same Origin Policy incorporates the rule that no API (not just a
>> specific API, such as HTML form) can allow a cross-origin PUT, unless
>> the target resource has somehow opted out of SOP protection. This
>> rule, and others like it, are the source of much of the complexity in
>> CORS. These rules are not left to the application layer.
>
> If I write something like a webbot, I can execute whatever PUT requests (=
or
> other HTTP requests) I want, or can't I?
Depending on how your webbot obtains the target URL, it may be
violating the target resource's expectation for protection under SOP.
For example, ...
> An API such as libcurl
> (http://curl.haxx.se/libcurl/) doesn't contain any such restrictions, or
> does it?
If you use libcurl to send a PUT request and the target resource
responds with a 307, which libcurl then automatically follows, you may
have violated the target resource's expectation of protection under
SOP. Consider a webbot that sends a PUT request to a resource on the
open Internet, which responds with a 307 to a resource behind the same
firewall as the webbot. The webbot has essentially punched a hole in
the firewall.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 19
Date: Mon, 30 Nov 2009 11:25:05 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Nov 25, 2009 at 2:34 PM, Tyler Close <tyler.close@gmail.com> wrot=
e:
>> On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> Indeed. =A0Security in the application layer is quite complex. =A0That'=
s
>>> what makes life interesting. =A0:)
>>
>> So are you agreeing that there do exist SOP rules that the application
>> layer must obey? If so, should we document those rules?
>
> Yes. =A0At the application layer.
Perhaps we're just talking past each other here. I'll try again...
When creating a new application layer API, the designers must take
into account the SOP protection expected by resources. Currently,
these expectations aren't documented anywhere. In the status-quo, the
application layer API is expected to magically know all the SOP
restrictions and then document how it enforces them. I'm just
suggesting that it would be a good thing to remove some of the magic
here by writing down the SOP restrictions, leaving the application API
with only the task of documenting its enforcement mechanism.
> I'm not even sure you can articulate the policy coherently without
> referring to application-layer concepts. =A0How would you explain the
> restrictions on images in the HTML Canvas element in terms of HTTP
> protocol messages?
The response to a GET request must not be made accessible to content
from another origin, unless the target resource has explicitly
indicated otherwise. The HTML <script> tag is a notable violation of
this restriction for content matching a particular syntax. Otherwise,
this rule seems widely enforced.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 20
Date: Mon, 30 Nov 2009 11:51:03 -0800
From: "Mark S. Miller" <erights@google.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wrote:
> The response to a GET request must not be made accessible to content
> from another origin, unless the target resource has explicitly
> indicated otherwise. The HTML <script> tag is a notable violation of
> this restriction for content matching a particular syntax. Otherwise,
> this rule seems widely enforced.
Other exceptions I'm aware of:
* size of images fetched using img tags.
* port scanning by differential error behavior
What other exceptions remain?
- --
Cheers,
--MarkM
------- Message 21
Date: Mon, 30 Nov 2009 12:17:38 -0800
From: Maciej Stachowiak <mjs@apple.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Nov 30, 2009, at 11:25 AM, Tyler Close wrote:
> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Wed, Nov 25, 2009 at 2:34 PM, Tyler Close
>> <tyler.close@gmail.com> wrote:
>>> On Wed, Nov 25, 2009 at 1:54 PM, Adam Barth <w3c@adambarth.com>
>>> wrote:
>>>> Indeed. Security in the application layer is quite complex.
>>>> That's
>>>> what makes life interesting. :)
>>>
>>> So are you agreeing that there do exist SOP rules that the
>>> application
>>> layer must obey? If so, should we document those rules?
>>
>> Yes. At the application layer.
>
> Perhaps we're just talking past each other here. I'll try again...
>
> When creating a new application layer API, the designers must take
> into account the SOP protection expected by resources. Currently,
> these expectations aren't documented anywhere. In the status-quo, the
> application layer API is expected to magically know all the SOP
> restrictions and then document how it enforces them. I'm just
> suggesting that it would be a good thing to remove some of the magic
> here by writing down the SOP restrictions, leaving the application API
> with only the task of documenting its enforcement mechanism.
It's important to understand that the same-origin policy is a concept
specific to a certain kind of client, not to a particular network
protocol. It's more of an HTML-level concept than an HTTP-level
concept. In particular, a browser loading a document over FTP or
Gopher would still enforce the same-origin policy in the same way. But
a low-level HTTP client library would not enforce the same-origin
policy at all.
>
>> I'm not even sure you can articulate the policy coherently without
>> referring to application-layer concepts. How would you explain the
>> restrictions on images in the HTML Canvas element in terms of HTTP
>> protocol messages?
>
> The response to a GET request must not be made accessible to content
> from another origin, unless the target resource has explicitly
> indicated otherwise. The HTML <script> tag is a notable violation of
> this restriction for content matching a particular syntax. Otherwise,
> this rule seems widely enforced.
That's a bit of an oversimplification. How much of the response you
can get depends on the embedding context:
cross-origin <script> --> contents executed as JavaScript, which may
let you read some of the contents depending on the nature of what is
returned.
cross-origin <link rel="stylesheet"> --> contents applied as a
stylesheet, all of the rules in the stylesheet can be read via CSS
cross-origin <img> --> if a valid image in some known format, height
and width can be determined; also, can be drawn to <canvas>, but then
reading the pixels of that canvas is disallowed
cross-origin <video> --> same as <img> plus you can get the duration.
cross-origin <iframe> --> the only way to communicate is via
postMessage()
cross-origin XMLHttpRequest --> nothing about the response is
available (unless the server opts in)
Same-origin policy differences are primarily about the embedding
context, not the networking-level details. All of these examples would
behave the same for FTP or Gopher or whatever other network protocol
is supported. In fact, classically the same-origin policy was all
about scripting access to the DOM, in that scripting access to the DOM
contents cross-origin frames is denied. It only started to affect
networking as such with the advent of XMLHttpRequest.
It would be good to gather the distributed knowledge about the same-
origin policy and make recommendations for new embedding or networking
facilities. But it's not really about HTTP, and would not make sense
as part of the HTTPbis effort.
Regards,
Maciej
------- Message 22
Date: Mon, 30 Nov 2009 22:00:26 +0100
From: Daniel Stenberg <daniel@haxx.se>
To: Tyler Close <tyler.close@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, 30 Nov 2009, Tyler Close wrote:
>> An API such as libcurl (http://curl.haxx.se/libcurl/) doesn't contain any
>> such restrictions, or does it?
>
> If you use libcurl to send a PUT request and the target resource responds
> with a 307, which libcurl then automatically follows
libcurl only "automatically" follows that if the app told it to act like that.
It follows no redirects by default. I know that's not the topic here but I
thought I'd clarify.
> Consider a webbot that sends a PUT request to a resource on the open
> Internet, which responds with a 307 to a resource behind the same firewall
> as the webbot. The webbot has essentially punched a hole in the firewall.
If a server does that I would consider that server/page to be a security
problem or flaw. Even evil guys can run webbots I believe.
- --
/ daniel.haxx.se
------- Message 23
Date: Mon, 30 Nov 2009 14:24:44 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
Hi Daniel,
Thanks for engaging with this example. I think it's a useful one
because it makes it clear that this issue is independent of HTML...
On Mon, Nov 30, 2009 at 1:00 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 30 Nov 2009, Tyler Close wrote:
>> Consider a webbot that sends a PUT request to a resource on the open
>> Internet, which responds with a 307 to a resource behind the same firewall
>> as the webbot. The webbot has essentially punched a hole in the firewall.
>
> If a server does that I would consider that server/page to be a security
> problem or flaw. Even evil guys can run webbots I believe.
In this scenario, the webbot and the person executing it are good
guys. The initial PUT request target resource is an evil guy, beyond
the control of good guys. The 307 redirect target resource is a good
guy. The webbot and the redirect target live behind the same firewall.
The evil resource lives outside the firewall. For the protection of
the good guy resource, the webbot must enforce the SOP, so that the
redirect is not followed. No HTML is involved in this scenario. Whose
specification of the SOP is the webbot enforcing? Of what assistance
should libcurl be in enforcing the SOP?
Note that it may be legitimate for a good guy PUT request target
resource to respond with a 307 redirect to a resource that is not
protected by a firewall. So you can't just say: don't follow any
redirects. Some redirects are safe and some may not be, depending on
the provided Location header.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 24
Date: Mon, 30 Nov 2009 23:34:02 +0100
From: Daniel Stenberg <daniel@haxx.se>
To: Tyler Close <tyler.close@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, 30 Nov 2009, Tyler Close wrote:
> The 307 redirect target resource is a good guy. The webbot and the redirect
> target live behind the same firewall. The evil resource lives outside the
> firewall. For the protection of the good guy resource, the webbot must
> enforce the SOP, so that the redirect is not followed. No HTML is involved
> in this scenario. Whose specification of the SOP is the webbot enforcing? Of
> what assistance should libcurl be in enforcing the SOP?
Oh right. I think understand what you're saying now. You want the HTTP client
to somehow detect that it isn't allowed to follow redirects to that target (in
that manner) and stop because a SOP somehow says so.
How do you suggest that would be told to the client?
Couldn't the TARGET here rather use Referer (or Origin or what not) to detect
that there's a redirect coming from externally and ignore it?
It clearly can't be HTTPbis material though, since in my eyes it seems to be a
rather major extension or change of what HTTP is and what it allows today.
- --
/ daniel.haxx.se
------- Message 25
Date: Tue, 01 Dec 2009 09:52:34 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Tyler Close <tyler.close@gmail.com>,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: RE: HTTPbis and the Same Origin Policy
> The 307 redirect target resource is a good guy. The webbot and the redirect
> target live behind the same firewall. The evil resource lives outside the
> firewall. For the protection of the good guy resource, the webbot must
> enforce the SOP, so that the redirect is not followed.
This actually is covered by the HTTP spec (1.1 and HTTPbis).
For instance, 8.3.8 307 Temporary Redirect says:
If the 307 status code is received in response to a request method
that is known to be "safe", as defined in Section 7.1.1, then the
request MAY be automatically redirected by the user agent without
confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
[http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.8]
At the HTTP layer it is not a same-origin issue, but a wider issue with methods
that are not "safe".
James Manger
------- Message 26
Date: Mon, 30 Nov 2009 14:54:25 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 2:34 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 30 Nov 2009, Tyler Close wrote:
>
>> The 307 redirect target resource is a good guy. The webbot and the
>> redirect target live behind the same firewall. The evil resource lives
>> outside the firewall. For the protection of the good guy resource, the
>> webbot must enforce the SOP, so that the redirect is not followed. No HTML
>> is involved in this scenario. Whose specification of the SOP is the webbot
>> enforcing? Of what assistance should libcurl be in enforcing the SOP?
>
> Oh right. I think understand what you're saying now. You want the HTTP
> client to somehow detect that it isn't allowed to follow redirects to that
> target (in that manner) and stop because a SOP somehow says so.
Yes.
> How do you suggest that would be told to the client?
The SOP rule is something like: Don't follow a cross-domain redirect
of a PUT request, unless the redirect target has opted out of SOP
protection.
So, upon seeing the 307 redirect, libcurl would report an error if the
origin of the Request-URI does not match the origin of the URL in the
Location header; otherwise, the redirect is followed. Until there's a
standard way for a resource to opt out of SOP, that's the best that
can be done.
> Couldn't the TARGET here rather use Referer (or Origin or what not) to
> detect that there's a redirect coming from externally and ignore it?
It could, but it doesn't. Today, the target resource expects the SOP
to protect it from non-same-origin PUT requests.
> It clearly can't be HTTPbis material though, since in my eyes it seems to be
> a rather major extension or change of what HTTP is and what it allows today.
The thing is, it's not an extension or a change. It's the status-quo.
Existing resources depend upon clients enforcing the SOP. We've just
left it unspecified what those protections are. Currently, these
protections are a widely relied upon oral tradition.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 27
Date: Mon, 30 Nov 2009 16:20:23 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wrote=
:
> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>> Yes. =A0At the application layer.
>
> Perhaps we're just talking past each other here. I'll try again...
>
> When creating a new application layer API, the designers must take
> into account the SOP protection expected by resources. Currently,
> these expectations aren't documented anywhere. In the status-quo, the
> application layer API is expected to magically know all the SOP
> restrictions and then document how it enforces them. I'm just
> suggesting that it would be a good thing to remove some of the magic
> here by writing down the SOP restrictions, leaving the application API
> with only the task of documenting its enforcement mechanism.
I agree with everything you're saying, but you haven't explained why
this documentation should be at the protocol layer instead of the
application layer.
>> I'm not even sure you can articulate the policy coherently without
>> referring to application-layer concepts. =A0How would you explain the
>> restrictions on images in the HTML Canvas element in terms of HTTP
>> protocol messages?
>
> The response to a GET request must not be made accessible to content
> from another origin, unless the target resource has explicitly
> indicated otherwise. The HTML <script> tag is a notable violation of
> this restriction for content matching a particular syntax. Otherwise,
> this rule seems widely enforced.
Maciej already responded to this point, but this is a drastic over
simplification.
Adam
------- Message 28
Date: Mon, 30 Nov 2009 17:11:07 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wro=
te:
>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> Yes. =A0At the application layer.
>>
>> Perhaps we're just talking past each other here. I'll try again...
>>
>> When creating a new application layer API, the designers must take
>> into account the SOP protection expected by resources. Currently,
>> these expectations aren't documented anywhere. In the status-quo, the
>> application layer API is expected to magically know all the SOP
>> restrictions and then document how it enforces them. I'm just
>> suggesting that it would be a good thing to remove some of the magic
>> here by writing down the SOP restrictions, leaving the application API
>> with only the task of documenting its enforcement mechanism.
>
> I agree with everything you're saying, but you haven't explained why
> this documentation should be at the protocol layer instead of the
> application layer.
1. To document the constraints that all user agents must enforce. The
restrictions apply to all APIs in the entire application layer, not
just some application APIs. HTTP is the layer below the application
API, where constraints upon all user agents are specified.
2. To document the security model that server-side resources are
written to. A HTTP resource expects the SOP to apply regardless of the
API used to generate requests. A HTTP resource is not a <img>
resource, or a <link> resource, or a curl resource, just an HTTP
resource. A resource does not expect the security model to change
based on the API used to produce the request. In many cases, this
distinction is not even knowable based on the content of the HTTP
request.
3. Although some parts of SOP also apply to other protocols, such as
ftp, other parts are specific to HTTP, such as: rules around request
headers, redirects, the distinctions between POST and PUT, etc.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 29
Date: Mon, 30 Nov 2009 17:23:47 -0800
From: Adam Barth <w3c@adambarth.com>
To: Tyler Close <tyler.close@gmail.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wr=
ote:
>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> Yes. =A0At the application layer.
>>>
>>> Perhaps we're just talking past each other here. I'll try again...
>>>
>>> When creating a new application layer API, the designers must take
>>> into account the SOP protection expected by resources. Currently,
>>> these expectations aren't documented anywhere. In the status-quo, the
>>> application layer API is expected to magically know all the SOP
>>> restrictions and then document how it enforces them. I'm just
>>> suggesting that it would be a good thing to remove some of the magic
>>> here by writing down the SOP restrictions, leaving the application API
>>> with only the task of documenting its enforcement mechanism.
>>
>> I agree with everything you're saying, but you haven't explained why
>> this documentation should be at the protocol layer instead of the
>> application layer.
>
> 1. To document the constraints that all user agents must enforce. The
> restrictions apply to all APIs in the entire application layer, not
> just some application APIs. HTTP is the layer below the application
> API, where constraints upon all user agents are specified.
Not all user agents must enforce these rules. For example, why
shouldn't wget be able to send PUT requests to any resource it likes?
Why should my SIP telephone follow these rules?
> 2. To document the security model that server-side resources are
> written to. A HTTP resource expects the SOP to apply regardless of the
> API used to generate requests. A HTTP resource is not a <img>
> resource, or a <link> resource, or a curl resource, just an HTTP
> resource. A resource does not expect the security model to change
> based on the API used to produce the request. In many cases, this
> distinction is not even knowable based on the content of the HTTP
> request.
If you assume the SOP will apply regardless of which application-layer
API is used, you'll be sorely mistaken. You need to understand the
application layer to understand the security consideration. For
example, it's fine to store certain kinds of secrets in XML documents,
but it's a security vulnerability to store the same kinds of secrets
in ECMAScript documents.
You say "In many cases, this distinction is not even knowable based on
the content of the HTTP request." That's precisely why these concepts
don't make sense at the protocol layer!
> 3. Although some parts of SOP also apply to other protocols, such as
> ftp, other parts are specific to HTTP, such as: rules around request
> headers, redirects, the distinctions between POST and PUT, etc.
The vast majority of the SOP is independent of HTTP. You're right
that some application layer APIs restrict what kinds of HTTP requests
can be made on behalf of various origins, but that's only a tiny part
of the story.
You seem to be picking an choosing which points you reply to. The
basic points you have yet to address are these:
1) The same-origin policy applies regardless of which protocols are
used (e.g, FTP, Gopher, HTTP).
2) The same-origin policy applies differently to different
application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).
Those are just facts of the world. It might be nice to live in a
world where the security considerations for building an HTTP server
were limited to understanding HTTP, but that's not the word in which
we live. You also need to understand applications of HTTP to get
security right. Security is hard.
Adam
------- Message 30
Date: Mon, 30 Nov 2009 18:05:28 -0800
From: Tyler Close <tyler.close@gmail.com>
To: Adam Barth <w3c@adambarth.com>
cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-
wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 5:23 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@gmail.com> wrot=
e:
>> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> w=
rote:
>>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>>> Yes. =A0At the application layer.
>>>>
>>>> Perhaps we're just talking past each other here. I'll try again...
>>>>
>>>> When creating a new application layer API, the designers must take
>>>> into account the SOP protection expected by resources. Currently,
>>>> these expectations aren't documented anywhere. In the status-quo, the
>>>> application layer API is expected to magically know all the SOP
>>>> restrictions and then document how it enforces them. I'm just
>>>> suggesting that it would be a good thing to remove some of the magic
>>>> here by writing down the SOP restrictions, leaving the application API
>>>> with only the task of documenting its enforcement mechanism.
>>>
>>> I agree with everything you're saying, but you haven't explained why
>>> this documentation should be at the protocol layer instead of the
>>> application layer.
>>
>> 1. To document the constraints that all user agents must enforce. The
>> restrictions apply to all APIs in the entire application layer, not
>> just some application APIs. HTTP is the layer below the application
>> API, where constraints upon all user agents are specified.
>
> Not all user agents must enforce these rules. =A0For example, why
> shouldn't wget be able to send PUT requests to any resource it likes?
See:
http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0272.html
> Why should my SIP telephone follow these rules?
Because I want to plug in a SIP telephone behind my firewall without
endangering all my intranet resources.
>> 2. To document the security model that server-side resources are
>> written to. A HTTP resource expects the SOP to apply regardless of the
>> API used to generate requests. A HTTP resource is not a <img>
>> resource, or a <link> resource, or a curl resource, just an HTTP
>> resource. A resource does not expect the security model to change
>> based on the API used to produce the request. In many cases, this
>> distinction is not even knowable based on the content of the HTTP
>> request.
>
> If you assume the SOP will apply regardless of which application-layer
> API is used, you'll be sorely mistaken. =A0You need to understand the
> application layer to understand the security consideration.
But the application layer is potentially infinite in size and
continues to grow long after a server-side resource is deployed.
> =A0For
> example, it's fine to store certain kinds of secrets in XML documents,
> but it's a security vulnerability to store the same kinds of secrets
> in ECMAScript documents.
Exactly the kind of obscure fact that HTTP resource authors need to
know. So let's document them.
> You say "In many cases, this distinction is not even knowable based on
> the content of the HTTP request." =A0That's precisely why these concepts
> don't make sense at the protocol layer!
I suspect we're not understanding each other at a fundamental level.
The resource makes its response based on the request. If the
distinction between APIs is not knowable based on the content of the
request, the response must be made based on the most permissive
security model of any of the possible APIs. To provide this lower
bound, the security model must be fixed by a specification that
applies to all APIs, such as HTTP.
>> 3. Although some parts of SOP also apply to other protocols, such as
>> ftp, other parts are specific to HTTP, such as: rules around request
>> headers, redirects, the distinctions between POST and PUT, etc.
>
> The vast majority of the SOP is independent of HTTP. =A0You're right
> that some application layer APIs restrict what kinds of HTTP requests
> can be made on behalf of various origins, but that's only a tiny part
> of the story.
>
> You seem to be picking an choosing which points you reply to. =A0The
> basic points you have yet to address are these:
I was trying to respond to everything. For example...
> 1) The same-origin policy applies regardless of which protocols are
> used (e.g, FTP, Gopher, HTTP).
was covered by my point 3 above...
> 2) The same-origin policy applies differently to different
> application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).
was covered by my point 2 above.
> Those are just facts of the world. =A0It might be nice to live in a
> world where the security considerations for building an HTTP server
> were limited to understanding HTTP, but that's not the word in which
> we live.
I agree, that's what I'm suggesting we fix. Currently, authors of HTTP
resources don't have a specification of the security model. They
should be provided with one.
>=A0You also need to understand applications of HTTP to get
> security right.
If the application layer is unconstrained, that's an impossible task.
We need to specify the constraints on the application layer to make
security possible.
> =A0Security is hard.
Let's not make it impossible.
- --Tyler
- --
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
------- Message 31
Date: Mon, 30 Nov 2009 18:41:11 -0800
From: Maciej Stachowiak <mjs@apple.com>
To: Adam Barth <w3c@adambarth.com>
cc: Tyler Close <tyler.close@gmail.com>,
Julian Reschke <julian.reschke@gmx.de>,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Nov 30, 2009, at 5:23 PM, Adam Barth wrote:
> 1) The same-origin policy applies regardless of which protocols are
> used (e.g, FTP, Gopher, HTTP).
> 2) The same-origin policy applies differently to different
> application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).
3) The same-origin policy is originally and primarily about scripting,
not networking. It has only lately and incidentally come to encompass
networking as well, largely to prevent working around the restrictions
on client-side scripting in the browser. It's impossible to explain
the restrictions on networking without reference to the original
scripting context.
Regards,
Maciej
------- Message 32
Date: Tue, 01 Dec 2009 14:25:38 +1100
From: Mark Nottingham <mnot@mnot.net>
To: Tyler Close <tyler.close@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>,
Thomas Roessler <tlr@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
Tyler,
This is important, but as mentioned firmly out of the scope of the =
HTTPbis WG.
There's currently a lot of discussion along these lines both at the IETF =
and the W3C, and I expect that a new mailing list will be announced =
shortly to serve as a home for topics like this.
Cheers,
On 01/12/2009, at 1:05 PM, Tyler Close wrote:
> On Mon, Nov 30, 2009 at 5:23 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@gmail.com> =
wrote:
>>> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> =
wrote:
>>>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close =
<tyler.close@gmail.com> wrote:
>>>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> =
wrote:
>>>>>> Yes. At the application layer.
>>>>>
>>>>> Perhaps we're just talking past each other here. I'll try again...
>>>>>
>>>>> When creating a new application layer API, the designers must take
>>>>> into account the SOP protection expected by resources. Currently,
>>>>> these expectations aren't documented anywhere. In the status-quo, =
the
>>>>> application layer API is expected to magically know all the SOP
>>>>> restrictions and then document how it enforces them. I'm just
>>>>> suggesting that it would be a good thing to remove some of the =
magic
>>>>> here by writing down the SOP restrictions, leaving the application =
API
>>>>> with only the task of documenting its enforcement mechanism.
>>>>
>>>> I agree with everything you're saying, but you haven't explained =
why
>>>> this documentation should be at the protocol layer instead of the
>>>> application layer.
>>>
>>> 1. To document the constraints that all user agents must enforce. =
The
>>> restrictions apply to all APIs in the entire application layer, not
>>> just some application APIs. HTTP is the layer below the application
>>> API, where constraints upon all user agents are specified.
>>
>> Not all user agents must enforce these rules. For example, why
>> shouldn't wget be able to send PUT requests to any resource it likes?
>
> See:
>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0272.html
>
>> Why should my SIP telephone follow these rules?
>
> Because I want to plug in a SIP telephone behind my firewall without
> endangering all my intranet resources.
>
>>> 2. To document the security model that server-side resources are
>>> written to. A HTTP resource expects the SOP to apply regardless of =
the
>>> API used to generate requests. A HTTP resource is not a <img>
>>> resource, or a <link> resource, or a curl resource, just an HTTP
>>> resource. A resource does not expect the security model to change
>>> based on the API used to produce the request. In many cases, this
>>> distinction is not even knowable based on the content of the HTTP
>>> request.
>>
>> If you assume the SOP will apply regardless of which =
application-layer
>> API is used, you'll be sorely mistaken. You need to understand the
>> application layer to understand the security consideration.
>
> But the application layer is potentially infinite in size and
> continues to grow long after a server-side resource is deployed.
>
>> For
>> example, it's fine to store certain kinds of secrets in XML =
documents,
>> but it's a security vulnerability to store the same kinds of secrets
>> in ECMAScript documents.
>
> Exactly the kind of obscure fact that HTTP resource authors need to
> know. So let's document them.
>
>> You say "In many cases, this distinction is not even knowable based =
on
>> the content of the HTTP request." That's precisely why these =
concepts
>> don't make sense at the protocol layer!
>
> I suspect we're not understanding each other at a fundamental level.
> The resource makes its response based on the request. If the
> distinction between APIs is not knowable based on the content of the
> request, the response must be made based on the most permissive
> security model of any of the possible APIs. To provide this lower
> bound, the security model must be fixed by a specification that
> applies to all APIs, such as HTTP.
>
>>> 3. Although some parts of SOP also apply to other protocols, such as
>>> ftp, other parts are specific to HTTP, such as: rules around request
>>> headers, redirects, the distinctions between POST and PUT, etc.
>>
>> The vast majority of the SOP is independent of HTTP. You're right
>> that some application layer APIs restrict what kinds of HTTP requests
>> can be made on behalf of various origins, but that's only a tiny part
>> of the story.
>>
>> You seem to be picking an choosing which points you reply to. The
>> basic points you have yet to address are these:
>
> I was trying to respond to everything. For example...
>
>> 1) The same-origin policy applies regardless of which protocols are
>> used (e.g, FTP, Gopher, HTTP).
>
> was covered by my point 3 above...
>
>> 2) The same-origin policy applies differently to different
>> application-layer APIs (e.g., XMLHttpRequest, <canvas>, @font-face).
>
> was covered by my point 2 above.
>
>> Those are just facts of the world. It might be nice to live in a
>> world where the security considerations for building an HTTP server
>> were limited to understanding HTTP, but that's not the word in which
>> we live.
>
> I agree, that's what I'm suggesting we fix. Currently, authors of HTTP
> resources don't have a specification of the security model. They
> should be provided with one.
>
>> You also need to understand applications of HTTP to get
>> security right.
>
> If the application layer is unconstrained, that's an impossible task.
> We need to specify the constraints on the application layer to make
> security possible.
>
>> Security is hard.
>
> Let's not make it impossible.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
- --
Mark Nottingham http://www.mnot.net/
------- Message 33
Date: Mon, 30 Nov 2009 19:52:23 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
I also had noticed of late that the "Same Origin Policy" is essentially
undocumented, and is communicated by oral and in-the-code tradition (as Tyler
notes) -- so I'm happy to see Tyler bring it up.
I agree with the sentiment that it isn't something that is appropriate to
document in the main-line httpbis I-Ds, although I nominally believe it
deserves mention in draft-ietf-httpbis-security-properties (which I & Barry
Leiba are ostensibly editing (new draft will be out before Anaheim)).
It appears to me that the "Browser Security Handbook"
<http://code.google.com/p/browsersec/> is an appropriate place at this time to
coalesce details wrt Same Origin Policies of various APIs, and that in fact is
what Michal is apparently doing. See..
Standard browser security features / Same-origin policy
http://code.google.com/p/browsersec/wiki/Part2#Standard_browser_security_featur
es
=JeffH
------- Message 34
Date: Mon, 30 Nov 2009 19:56:55 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
> The same-origin policy is originally and primarily about scripting...
Yah, in terms of references to "Same Origin Policy" and where the notion
originated, everything I can (more-or-less easily) find on the web seems to
ultimately point back to..
https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript
..and..
http://www-archive.mozilla.org/projects/security/components/same-origin.htm
l
=JeffH
------- Message 35
Date: Tue, 01 Dec 2009 13:28:20 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
To: Tyler Close <tyler.close@gmail.com>
cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>
,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On 2009/12/01 4:00, Tyler Close wrote:
> Consider a webbot that sends a PUT request to a resource on the
> open Internet, which responds with a 307 to a resource behind the same
> firewall as the webbot. The webbot has essentially punched a hole in
> the firewall.
Yes, the webbot has done this. One has to be very careful when running
stuff such as webbots, make sure they are either inside or outside the
firewall, but not both, unless you know exactly what you're doing. This
not only applies to PUTs, but also to GETs.
On the other hand, if I write (e.g. using libcurl or whatever) a
"webbot" that periodically checks the balance on one of my bank accounts
and transfers money from another bank account of mine if the balance on
the first bank account is low, then I don't see why anybody would want
to forbid this.
Regards, Martin.
- --
#-# Martin J. D=FCrst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
------- Message 36
Date: Mon, 30 Nov 2009 23:19:05 -0800
From: Adam Barth <w3c@adambarth.com>
To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
cc: Tyler Close <tyler.close@gmail.com>, Julian Reschke <julian.reschke@gm
x.de>,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 8:28 PM, "Martin J. D=FCrst"
<duerst@it.aoyama.ac.jp> wrote:
> On the other hand, if I write (e.g. using libcurl or whatever) a "webbot"
> that periodically checks the balance on one of my bank accounts and
> transfers money from another bank account of mine if the balance on the
> first bank account is low, then I don't see why anybody would want to for=
bid
> this.
As a point of amusement, I recently co-wrote a "stylebot" for the
WebKit project that violates the same-origin policy in precisely this
way (by shuffling data between a Bugzilla instance and another web
service).
Adam
------- Message 37
Date: Tue, 01 Dec 2009 10:00:22 -0500
From: Joe Gregorio <joe@bitworking.org>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
cc: Tyler Close <tyler.close@gmail.com>, HTTP Working Group <ietf-http-wg@
w3.org>
Subject: Re: HTTPbis and the Same Origin Policy
On Mon, Nov 30, 2009 at 5:52 PM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
>> The 307 redirect target resource is a good guy. The webbot and the redir=
ect
>> target live behind the same firewall. The evil resource lives outside th=
e
>> firewall. For the protection of the good guy resource, the webbot must
>> enforce the SOP, so that the redirect is not followed.
>
> This actually is covered by the HTTP spec (1.1 and HTTPbis).
> For instance, 8.3.8 307 Temporary Redirect says:
>
> =A0 If the 307 status code is received in response to a request method
> =A0 that is known to be "safe", as defined in Section 7.1.1, then the
> =A0 request MAY be automatically redirected by the user agent without
> =A0 confirmation. =A0Otherwise, the user agent MUST NOT automatically
> =A0 redirect the request unless it can be confirmed by the user, since
> =A0 this might change the conditions under which the request was issued.
>
> [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.=
3.8]
>
> At the HTTP layer it is not a same-origin issue, but a wider issue with m=
ethods that are not "safe".
I've covered these scenarios in httplib2 with the .folllow_redirects
and .follow_all_redirects options:
http://httplib2.googlecode.com/hg/doc/html/libhttplib2.html#httplib2.Htt=
p.follow_redirects
Tyler, are you asking for HTTP client libraries to provide something
more comprehensive than that?
Thanks,
-joe
>
>
> James Manger
>
------- End of Forwarded Messages
Received on Wednesday, 2 December 2009 20:19:46 UTC