Web browser security is hard…
27.2.2006 / Uncategorized /
I can’t imagine using delicious without this fantastic tool called Director. It uses a nifty trick to plant its own UI over a user’s delicious bookmarks page:
This project uses the only reliable loophole for executing foreign Javascript code: the bookmarklet bootloader. It works by inserting a
element directly into the DOM, which is then immediately executed by the browser. The injected Javascript wipes the existing del.icio.us page and replaces the entire body with the direc.tor UI. At the same time, direc.tor makes an XmlHTTPRequest tohttp://del.icio.us/api/posts/allto get the XML listing of the user’s bookmarks, which is persisted through the lifetime of the direc.tor page.
(emphasis mine)
Isn’t this also a potential hole waiting to be exploited by a phisher? Firefox plugins (right now) hardly have any security checks other than a dialog that pops up at installation saying that bad things might happen. A malicious plugin could easily do the same thing that Director does.
This is exactly why security in a browser is hard: useful apps like Director use this functionality, but it also has some serious security implications. Can you expect a user to know the difference between “good uses” and “bad uses” of a particular part of browser functionality?
28.2.2006 at 12:27 am
Firefox extensions have always been a pain in the wrong places when the security of the browser architecture is taken as a whole. Trusting users to do the right thing doesn’t seem to have worked so far. But this is not a problem for the browser alone. A user who downloads and uses an extension that does not have enough following and is not open source is equal to a user who downloads a binary from an untrusted source and executes it on a machine. Firefox extension is just an ‘extension’ of that untrusted binary.