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

Received on Tuesday, 1 December 2009 01:24:46 UTC