Re: Extension HTTP methods

On Wed, 07 Jun 2006 23:46:09 +0200, Mark Nottingham <mnot@yahoo-inc.com>  
wrote:

> Blindly standardising what one vendor does doesn't make sense;

We can certainly assume they have thought long and hard about a change  
that WILL break existing content.

> do you know *why* they consider it a security feature?

I have heard the verb "CONNECT" brought up as an especially important one  
that scripts should not be allowed to send at random due to its usage to  
initiate HTTPS connections. I don't know enough about SSL to discuss abuse  
scenarios.

> The reputed security problems with various HTTP methods have been  
> brought up many times, but I have yet to see an explanation of how they  
> actually cause a security issue greater than supporting POST does.

If you look at the "request smuggling" [1] exploits there is plenty of  
scope for problems even in the naive implementations of HTTP GET/POST. If  
you can send a random verb you could probably "fake" a protocol with other  
conventions for how content is sent, thereby making it harder to secure  
proxies and servers against request smuggling.

I assume allowing random verbs for XHR will make it harder to develop HTTP  
or HTTP-compatible protocols in the future because Joe Web Developer will  
have used verbs in a random web app that might clash with a particular  
development of HTTP, and noone will find out until the server is upgraded  
to support the new HTTP version and the web app falls apart... Even though  
I don't know the security aspect in depth I can agree that extending HTTP  
with new verbs is up to some comittee in IETF or W3C, not something any  
random web developer should be doing because they can.

[1] http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf

-- 
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Received on Friday, 9 June 2006 08:37:13 UTC