> On Wed, Jul 21, 2010 at 07:54:30AM -0500, Jared Johnson wrote: >> Unlike the other bits of "dodge this sort of munging" operations, >> examining my test results and asking uncle google has not made it clear >> to >> me what "inserted-semicolon munging" really is. Can anyone shed light >> on > > My memory of this is fuzzy, but my SVN log indicates it was an attempt to > deal > with a style of munging that exploited different browser behavior on > encountering semicolons in the hostname component of URLs. At the time, > the > form I was considering was "http://domain;.com/";. Under firefox, the > semicolon is taken to mean the end of the hostname and the start of the > path, > thus triggering the implied-.com behavior and ending up at > "http://domain.com/;.com/";. I forget what IE does/did, but given the > IE/FF > market share balance in 2005 when I added that feature, it was probably > similar.
Do you happen to remember whether at the time you were looking at real spam volume, or just a possible attack? My latest effort is still a bit in question; (1) http://domain;.jkl and http://domain/ are just as possible to trigger the implied-.com behavior; (2) this behavior seems to only be triggered when typing on the URL bar, and *not* when clicking a link. My colleagues are in favor of just dropping the test, unless there's actually reason to believe we will see spammer URI's that try to take advantage of this. If so, it would probably be best to detect what they're trying to obfuscate based on actual data, since that's really the important thing -- if the spammer thinks spammerdomain;.net will go to spammerdomain.net, we should check spammerdomain.net, even if in reality it would go to spammerdomain.com :) If this was all theoretical to begin with, I'd be happy, at least in our code, to just skip the test entirely, and wait until we see something interesting in FN data. -Jared
