- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 09 Jun 2006 10:56:20 +0200
- To: "Hallvord R. M. Steen" <hallvord@opera.com>
- CC: Mark Nottingham <mnot@yahoo-inc.com>, Mark Baker <distobj@acm.org>, Anne van Kesteren <annevk@opera.com>, Pete Kirkham <mach.elf@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>
Hallvord R. M. Steen schrieb: > 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. It would be really great if we could work based on facts instead of hearsay. The fact the IE7 right now rejects REPORT (which is both safe and idempotent, and which has been an IETF standards track protocol for over 4 years now) to me clearly indicates that the change involved at least one clueless person :-). >> 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. If this is the case, and if this is the reason it's not available in IE7, why didn't Microsoft bother to change it in IE6 as well? >> 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. Obviously to reply to this, time for investigation is needed. So far I'm not convinced that FOOBAR vs GET makes it harder for intermediates. > 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. Yes. But by disallowing "unknown" method names in XHR, the W3C would make it much harder for standards bodies to actually define protocols with new method names. Keep in mind that once user agents start to ship with a method name challenged XHR object, it may take a very long time until all relevant vendors have updated their user agents, and they are sufficiently deployed. So please leave this to those who actually control HTTP + extensions, which is the IETF. > [1] http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf (behind a registration page that wants my phone number. blech.) Best regards, Julian
Received on Friday, 9 June 2006 08:56:27 UTC