Re: [origin] Thoughts and comments

On Sat, Jan 24, 2009 at 7:03 AM, Anne van Kesteren <annevk@opera.com> wrote:
> I'm wondering whether it's a good idea to define that the Origin header is
> always included for all those type of requests. Is that really what we want?
> Or do we want to use it for CORS, HTML form submission, and maybe future
> APIs that allow equivalent functionality? E.g., it does not seem important
> for curl or wget to support Origin, even though they sometimes perform POST
> requests as well.

It is important that the attacker can't trick the browser into sending
a POST request without an Origin header because Web sites are supposed
to treat those requests as if they came from non-supporting user
agents and let the request modify state.

We could explicitly define the notion of a participating user agent,
much as we do for servers.  This would let curl or wget ignore the
header since it's not important for them.

> As currently drafted it introduces a change as opposed to how Origin has
> been defined in CORS. Per your draft it will also be included for same
> origin requests.

Yes.  This is a change.  The presence of the Origin header with the
correct value is more confidence inspiring for those using the header
as a CSRF defense.  Also, if the header achieves widespread
deployment, server operators might choose to lock out legacy clients
by blocking state-changing requests that lack an Origin header.

> Another change is that you allow the value "null" to be
> used at will, which if implemented would make it less useful.

My intention was that other specifications, like CORS and HTML forms,
would require the Origin header to be non-null for particular APIs.
That way CORS would have the same functionality it has now.

> I don't understand you can come past step one in the section HTTP Server
> Behavior when you use an unsafe method. But then I have a hard time
> understanding the wording there in general so I may be missing something.

Oops.  That's a bug.  Fixed.  How can I improve the wording there to
make it more clear?

> Is the second algorithm in the HTTP Server Behavior section intended for
> content deployed on a participating server which is then rendered in a
> browsing context?

Yes.  I wasn't sure how to specify this cleanly at this layer of
abstraction.  I'd welcome any suggestions you have.

> As for the sections with definitions, how do we ensure consistency with the
> origin model in HTML5? Would HTML5 defer to this draft for computing an
> origin out of a URI? What about comparing origins?

That's the plan.  Ian and I are working out the cleanest way to do this.

> Unicode serialization of
> an origin is not used in the draft yet is defined. Is there a strategy
> behind this? It might help to outline that in the draft.

It didn't make sense to spec the ASCII serialization in one document
and the unicode serialization in another document.

Thanks for your feedback,
Adam

Received on Saturday, 24 January 2009 18:39:52 UTC