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

Received on Tuesday, 1 December 2009 02:06:02 UTC