headers
Adam Barth | 1 Dec 2009 01:20

Re: HTTPbis and the Same Origin Policy

On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@...> wrote:
> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@...> 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.

>> 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.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tyler Close | 1 Dec 2009 02:11
Picon

Re: HTTPbis and the Same Origin Policy

On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@...> wrote:
> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@...> wrote:
>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@...> 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.

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Adam Barth | 1 Dec 2009 02:23

Re: HTTPbis and the Same Origin Policy

On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@...> wrote:
> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@...> wrote:
>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close
<tyler.close@...> wrote:
>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@...> 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?
Why should my SIP telephone follow these rules?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tyler Close | 1 Dec 2009 03:05
Picon

Re: HTTPbis and the Same Origin Policy

On Mon, Nov 30, 2009 at 5:23 PM, Adam Barth <w3c@...> wrote:
> On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@...> wrote:
>> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@...> wrote:
>>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close
<tyler.close@...> wrote:
>>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@...> 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?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Maciej Stachowiak | 1 Dec 2009 03:41
Picon
Favicon

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>,  <at> 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
Permalink | Reply | 0 comments |
headers
William A. Rowe Jr. | 1 Dec 2009 03:43

Re: #131: Connection limits (proposal)

Mark Nottingham wrote:
> There hasn't been any discussion since, and in the meantime the editors have incorporated the proposal
with the modification below;
>   http://trac.tools.ietf.org/wg/httpbis/trac/changeset/715
> 
> Unless I hear objection I'll close the issue.
> 
> 
> On 20/10/2009, at 9:32 AM, Mark Nottingham wrote:
>>
>> """
>> Note that servers might reject traffic that they deem abusive, including an excessive number of
connections from a client.
>> ""

+1 to this alternate phrasing.
Permalink | Reply | 0 comments |
headers
Mark Nottingham | 1 Dec 2009 04:25
Favicon
Gravatar

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@...> wrote:
>> On Mon, Nov 30, 2009 at 5:11 PM, Tyler Close <tyler.close@...> wrote:
>>> On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@...> wrote:
>>>> On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close
<tyler.close@...> wrote:
>>>>> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@...> 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.
>>>>
(Continue reading)

Permalink | Reply | 4 comments |
headers
=JeffH | 1 Dec 2009 04:56

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.html

=JeffH
Permalink | Reply | 0 comments |
headers
=JeffH | 1 Dec 2009 04:52

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_features

=JeffH
Permalink | Reply | 0 comments |
headers
Martin J. Dürst | 1 Dec 2009 05:28
Picon
Gravatar

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ürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...
Permalink | Reply | 2 comments |

Gmane