1
edit
Changes
→Active Adversaries
TODO: discussion of what they can do, what we can do
Snippet from Firefox bug 340061, which was lodged prior to discovering the stated "non-goals" in this wiki. Bug has been closed due to this but the brief narrative of the logical circumvention has been copied from there.
----
Allowing javascript redirects from a blacklisted site gives the attacker the
ability to keep changing the ultimate URL which serves the content to make sure
it isn't on the blacklist.
If the scam email (for example) points people to http://mydevserver/fish.htm,
then this URL could be added to the blacklist. The scammers could then change
fish.htm to redirect to haddock.htm, which could be responded to by adding all
of http://mydevserver/* to the blacklist.
But even then the attacker could change fish.htm again to redirect people to
http://someotherserver/fish.htm. They would always be able to keep changing the
URL of the eventual page to make sure it wasn't on the blacklist, but keep the
same entry point at http://mydevserver/fish.htm. Given that attackers get
access to the blacklist at the same time as everyone else, they could easily
make sure that the page was almost always not blacklisted (provided they have
enough URLs to use, which they usually do).
----
The simple solution to this is to block until an answer has been received from the blacklist lookup, but this would obviously cause unacceptable delays to all pages (in the case of a remote lookup instead of local blacklist). Is there a decent compromise?
== Future Work ==
