W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: HTTPbis and the Same Origin Policy

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Dec 2009 14:25:38 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Thomas Roessler <tlr@w3.org>
Message-Id: <14285F38-3D00-4EE5-8241-4B57B28E63BE@mnot.net>
To: Tyler Close <tyler.close@gmail.com>

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.


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/
Received on Tuesday, 1 December 2009 03:26:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC