Re: [origin] Thoughts and comments

On Sat, 24 Jan 2009 19:39:10 +0100, Adam Barth <w3c@adambarth.com> wrote:
> 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.

Ok, I suppose that makes sense.


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

I think that would make sense.


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

Ok.


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

Ok.


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

It's ok now. I think the bug just tripped me.


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

Maybe talk about content or Web pages rather than a server? Dunno.


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

Ok.


One other thing, CORS currently requires codepoint for codepoint  
comparison between two origins. Your draft seems to suggest that servers  
should implement a different algorithm. Why can servers not use string  
comparison as well given that the origin they will get will always be the  
same for a given URL?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Wednesday, 4 February 2009 12:34:10 UTC