John Hardin wrote: >> http://pastebin.com/m1268fbe6 > > Thanks. Here's the problematic URI: > > http://../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55 > > in the unsunscribe link.
Which was actually: > <a href=3D=22=2E= > =2E/cd=2Easp?i=3D572550545=26UserID=3D4DFEDDHIIBCFBH55=22> And thus: > <a href="../cd.asp?i=572550545&UserID=4DFEDDHIIBCFBH55"> This is *very* different from prefacing that with "http://"; (which is apparently what the SA "uri" rule does). Note to developers: that's a bug. There should be some rule for noting relative paths in links (even if it's scored 0.001), just as (IMHO) there should be one for things like hrefs pointing at Windows paths or the file:/// protocol. > Granted, ".." is not a hidden directory. I think it's almost as bad, as it obfuscates URLs; let's assume you've got Microsoft's website whitelisted for some reason, or a spam filter blacklists http://black-hat.example.com/live-exploits/* ... http://pastebin.com/http://www.microsoft.com/../../../m1268fbe6 http://black-hat.example.com/cute-bunnies/../live-exploits/foo This may even suggest that the "right way" to do it is to have SA resolve the .. for us, handing the regex the corrected path. > Revised rule, to omit current directory and parent directory relative > URIs, while still hitting on "..." (which is pretty common): > > uri URI_HIDDEN /\/\.(?!\.\/)[^\/]/i Relative URIs are only safe when prefacing the URI. Requiring the protocol beforehand should do the trick. Since "http://"; is the implied protocol and is 8 chars, we get this: uri URI_HIDDEN /.{8}\/\../ or alternatively: rawbody URI_HIDDEN /href=[^ >]{,99}\/\../i
