Adam Katz wrote:
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}\/\../
Yep - that works great for me and I understand the logic (I assume you
meant the protocol is a max of 8 chars as in "https://";).
or alternatively:
rawbody URI_HIDDEN /href=[^ >]{,99}\/\../i
Thank you John and Adam for the insightful discussion.
