Re: Extension HTTP methods

On Mon, 15 May 2006 02:16:15 -0700, Jim Ley <jim@jibbering.com> wrote:

> "Gorm Haug Eriksen" <gormer@opera.com>
>> I don't think these two methods are allowed in any implementations  
>> today so they shouldn't be in use. However, the biggest concern is that  
>> someone has implemented a HOBBIT method that do something insecure.
>
> And then creates a script on their webserver which sends a HOBBIT  
> request back to them?  What scenarios is this HOBBIT method relevant  
> other than in a Cross Site XHR environment?

Jim, I'm not sure it's safe and I'm not sure if it's unsafe. Are you? And  
security guys don't buy the argument that this is unsafe so then this can  
also be unsafe :)

>> I have spoken  with some security people and they are concerned  
>> although we in the group  see benefits in having arbitrary verbs.
>
> That's fine, security people can pick a security policy for their UA,  
> that shouldn't change that we in the specification allow any verb, just  
> as we don't disallow arbitrary headers because someone might invent one  
> that does something insecure.  Picking verbs is profiling HTTP, and I  
> really think that's a bad idea, and the specification does not generally  
> contain any security model, so why pick this one area to have one?

I don't see your point. The specification will of course allow any verb.  
However, the author can not relay on it and the specification should also  
address that fact?

>> I guess the problem is the vendors here.
>
> There are lots of other incompatibilities with the spec, that hasn't so  
> far led to us changing the spec, in fact the same f2f has relaxed the  
> rules on being compatible with implementations.  Unfortunately that  
> means pointing to the implementations and going that's what they do,  
> that's what we'll spec. isn't so easy, so now you've opened us up to  
> arguing it :-)

I don't know if the specification will change :) This is just an issue  
raised by the behaviour of some security guys that we couldn't address in  
the meeting. It's not a perfect solution and having a open discussion  
where the vendors talk about real concern is a good thing.

>>> Don't cripple XHR because of that.
>
>> I don't think it will be to much crippled. It would still be possible  
>> to use headers to signal.
>
> It would be crippled - it may need to be crippled for security reasons,  
> but I don't believe so, the HOBBIT scenario is not any more realistic  
> than a HOBBIT header, or a HOBBIT magic GETable URL.  Using headers to  
> signal is not RESTful, and very much not a solution.

I will not go into a discussion on what is RESTful or not, but I mailed  
Roy Fielding about this issue some time ago. Didn't get any response from  
him. Also, documents around the net that talk about REST mention this  
issue.

>> I don't think the idea is to forbid, but rather have a white-list that  
>> we all can agree on supporting. This list should contain all the verbs  
>> widely in use today.
>
> I don't agree on a "whitelist" that everyone can agree on supporting,  
> since if we put CHICKENS on a whitelist and a UA decides that is  
> actually insecure and blocks it, it should be free to do so, so the  
> whitelist will give us nothing, simply SHOULD support any VERB, and  
> you're free to block any you want for security reasons is a much more  
> sensible policy than a non mandatory whitelist.

The idea was to not have controversy verbs on the list, but thats probably  
naive and will end to seriously cripplings.

Cheers,

- Gorm

Received on Monday, 15 May 2006 11:56:22 UTC