Comments on: Firefox vs Internet Explorer… Who’s Really At Fault

By: Harry Johnston

Harry Johnston — Tue, 24 Jul 2007 03:38:36 +0000

Let me try again!

http://msdn2.microsoft.com/en-us/library/aa767914.aspx

By: Harry Johnston

Harry Johnston — Tue, 24 Jul 2007 03:38:06 +0000

Sorry, forgot the link:

By: Harry Johnston

Harry Johnston — Tue, 24 Jul 2007 03:37:38 +0000

Actually it turns out that this wouldn’t help, because the Windows specification for registering URI handlers requires that URIs be decoded before being passed to the handler. This means even a legal URI could take advantage of the vulnerability.

So Microsoft is right in saying they can’t fix the problem … not without potentially breaking third-party software that depends on the documented behavior.

Of course decoding the URI before passing it to the registered handler is a silly thing to do, but it’s probably too late to change now.

By: Harry Johnston

Harry Johnston — Sun, 22 Jul 2007 22:54:08 +0000

Further to my previous comment, it shouldn’t be assumed that the correct response to an invalid URI should be to normalize it and pass it to the handler. I think there’s a good case for simply rejecting illegal URIs outright.

That is, when the user clicks on the link – whether it is embedded in static HTML, generated by Javascript, or whatever – IE could simply advise the user that the link is invalid and refuse to attempt to follow it.

By: Harry Johnston

Harry Johnston — Sun, 22 Jul 2007 18:13:37 +0000

I don’t see what you mean by “the URI specification is pretty broad”. It makes it perfectly clear that only a specific set of characters are permitted unencoded in a URI; quote marks are not one of the permitted characters.

As far as I’m concerned, Windows/IE should not hand an illegal URI (such as one containing unencoded quote marks or spaces) to a registered URI handler; that’s just common sense.

By: Tyler Reguly

Tyler Reguly — Sun, 22 Jul 2007 15:45:17 +0000

That’s for the further clarification Larry,

I agree 100% that the recipient should validate the data, however as I said I don’t see a reason why you can’t have multi-tiered defense and the one passing the data can’t do the same. It may be undesirable but I see potential benefits in this case.

By: Larry Masinter

Larry Masinter — Sun, 22 Jul 2007 09:25:39 +0000

I don’t think I would come to the same conclusion you did from my remarks.

Sure, software that creates data is responsible for creating correct data. But the URI specification is pretty broad, and it’s not even clear that the interface in question isn’t more liberal than the RFC.

Any software that accepts data from another source is responsible for insuring that the data doesn’t cause a failure or a security vulnerability. Nothing that any standards group might say could reduce that responsibility.

“Normalization” of URIs in some circumstances is quite undesirable, and should be avoided until it’s necessary, preferably at the endpoints of the communication (when it is constructed and when it is parsed) rather than several times during intermediate phases.