Monday, November 5th, 2007

URI Comparison Functions

Category: Articles, IE

It is nice to see a post on IEBlog that isn’t about ES4 ;) Dave Risney provides just that as he details the perils of comparing URIs, a common cause for security exploits and errors in general.

Investigating URI parsing related issues in various products, I’ve run across many instances of code erroneously attempting to compare two URIs for equality. In some cases the author writes their own comparison and seems to be unaware of URI semantics and in other cases the author delegates to a Windows provided function that doesn’t quite work for the author’s scenario. In this blog post I’ll describe some of the unmanaged URI comparison functions available to Win32 developers, and a few common mistakes to avoid.

The latest URI RFC 3986 does an excellent job of describing a ladder of URI comparisons. The range on the ladder trades off comparison speed for number of false negatives. False negative in this case means that the URI comparison function says two URIs are not equivalent when they are.  However, nowhere on the ladder will a comparison generate a false positive. That is, a URI comparison function should never incorrectly report that two URIs are equivalent.

To summarize, IUri::IsEqual is a good Scheme-Based Normalization URI comparison function, UrlCompare and CoInternetCompareUrl should be avoided for fear of security bugs, and with no better choices a simple case sensitive string comparison will suffice.

Posted by Dion Almaer at 7:30 am

2.6 rating from 11 votes


Comments feed TrackBack URI

Um… in the RSS i got a TON of SPAM links before the main content ;)

Comment by poofeq — November 5, 2007

Me too, and in another RSS item. Looks like you guys have been hacked.

Comment by Matthew Pennell — November 5, 2007

Yeap me too. seems like the RSS has been hacked.

Comment by f0vela — November 5, 2007

Have a look at the screen dumps of google reader here:

Comment by Dan Eastwell — November 5, 2007

Super long URI’s?

Comment by Edwin — November 5, 2007


Comment by Adrian — November 5, 2007

probably the spam was detected and removed.

but this is interesting.

Comment by Anirudh — November 5, 2007

It wasn’t removed, if you have the web developer toolbar, for example, turn off styles (Ctrl-Shift-S) for those on windows, you’ll still see all the spam.

Comment by James Asher — November 5, 2007

Spam is still there, just hidden with CSS.

Comment by francesco — November 5, 2007

You can see the spam in the source view of this page, too, btw. Do a view source and look for “lauren that Greg Kinnear” to see it… hidden via a styled font tag.

Comment by Jason — November 5, 2007

i stopped reading after the 20th spam link ;))

Comment by add — November 5, 2007

Time to change your password, guys. You’ve been pwn3d by some spammer.

Comment by Joe Grossberg — November 5, 2007

Yep. same on bloglines.
Funky, uh?

Comment by Porta — November 5, 2007

kjhkjhkhl kjh k hkjh jk hkh k hkl jh lhkhl lhjhkljhklhjkh

Comment by plautus — November 5, 2007

Ajaxian got pwned

Comment by Mike — November 5, 2007


Not a fun thing to see in my inbox, hope you guys get it resolved

Comment by Takuan Daikon — November 5, 2007

A problem with all of the spam is also – what else has or can be crammed into this page? What is next? Malicious payloads? Malformed things people think are the dreaded quicktime and it is something different?

As has been noted elsewhere, it would be highly recommended to at least post about what has been done to re-secure things. How it happened etc. would also be good…

Comment by benb — November 5, 2007

Leave a comment

You must be logged in to post a comment.