I've been reading Firefox security bug reports over the years, and I've collected a list of things that can go wrong in security dialogs.
This is a class of attacks where you try to change the meaning that a security dialog has in a user's mind.
You might remember this dialog from the dark days of IE's dominance. The dialog includes the company's name, which is verified by a certificate authority, and the name of a program, which is whatever the site wants. Screenshot from Nick Lockard.
This is a dialog that you get if you download an app with a web browser, and then try to run it.
You might notice that the filename is shown in quotes, and filenames can't contain (straight) double quotes. But they can include single quotes...
Another problem with this dialog is the 'Open' button. It should be 'Launch' or 'Run' (or ideally 'Install').
Sorry, Apple, for the 0-day. Try this attack on your computer. Apple Radar: 8191203.
The attacker just needs to own "comsecure.ly" for this to work. To make this screenshot I put "127.0.0.1 download.mac.leopard.mac.download.mac.download.apple.comsecure.ly" in my /etc/hosts file, but someone who owned "comsecure.ly" could attack people this way. Apple Radar: 8191206
From Bug 214721
By "key text" i mean text that's crucial to the user's security decision. Maybe it's a filename extension or a domain name.
Screenshot from bug 479652 in Firefox's bug database.
Right-to-left mark makes text backwards, letting you control what's at the "beginning" or "end".
From bug 403464. My friend Pat told me about it. Could make it look like a dialog has exploded.
Unicode Combining marks can do strange things depending on your text rendering engine. (Accents, umlauts, especially heavy metal umlauts.)
Null can cause a string to be truncated, because of differing string representations.
Homographs can be used in spoofing where the attacker wants one string to look like another.
Want to ensure that the dialog's ability to communicate authentication and safety information cannot be impaired by a clever attacker. Test for common holes that affect dialogs that contain website-specified text.
Like clickjacking, but temporal rather than spatial. See Race conditions in security dialogs for details.
Mozilla has been experimenting with alternatives to dialogs. In a web browser: web sites can spam you with them; you feel like you have to make a decision right away; you can't close the tab to ignore it; you lose the sense of "place" that comes from the tab and address bar. You don't know what will happen if you deny.
Screenshot from Chrome 19 (dev) on Lion.
Info bars are in the "deny, but let the user undo the denial" camp. Info bars let you ignore the request as you read the page or close the tab. They have the advantage of not covering the page.
The API has to be async for this UI to work!
Screenshot from Firefox 13 (nightly) on Lion.
For some reason Mozilla has been moving from information bars to doorhangers. I think the idea is that it's going to be visually attached to the site identity button, so it's clear that you should consider it as being from the site, and you know how to get it back if you deny it. But it's less obvious that you can ignore the request; it kinda looks modal. And it's harder to just ignore because it covers part of the web site.
Sometimes, you can make the security decision part of a workflow. Instead of the site asking permission to do something, the UI allows the user to do it. Another example: file pickers as a sandbox exception.
Don't provide APIs to request permission for something the user could do on their own, such as bookmarking the page. Another example: maybe we don't need onbeforeunload warnings now that we have AJAX and localStorage and undo-close-tab. I filed bug 578828 for removing onbeforeunload support.