1
edit
Phishing Protection: Design Documentation: Difference between revisions
Jump to navigation
Jump to search
Phishing Protection: Design Documentation (view source)
Revision as of 06:04, 6 June 2006
, 6 June 2006→Active Adversaries
Jolivierld (talk | contribs) |
|||
| Line 276: | Line 276: | ||
TODO: discussion of what they can do, what we can do | 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 == | == Future Work == | ||