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.
Sorry, Apple, for the 0-day. Try this attack on your computer. Apple Radar: 8191203.
Change the meaning of buttons: Suppose a dialog has "Save" and "Cancel" buttons, where "Save" is used to mean "download" and is the more dangerous action. An attacker might say "Your computer is under attack. Would you like to make a saving throw?" This attack doesn't even have to be in the dialog.
Sowing confusion: If you just put nonsense in, will users give up on understanding the dialog in its entirety -- and click the more dangerous action, thinking it to be jargon?
It's like a buffer overflow. When I say "key text", think filename extensions, which come at the end.
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
Null can cause a string to be truncated, because of differing string representations.
Right-to-left mark makes text backwards, letting you control what's at the "beginning" or "end".
Homographs can be used in spoofing where the attacker wants one string to look like another.
Combining marks can do strange things depending on your text rendering engine.
From bug 403464. My friend Pat told me about it. Could make it look like a dialog has exploded.
There are several parts of the story that may fit into the theme of "technology transfer".
Trying to convince UI designers and front-end developers to design and implement a safe ways to display hostnames and other untrusted text. So far I have been unsuccessful: I've gotten many promises, but Johnath and Blair keep getting distracted by other projects that seem more urgent.
The success of convincing the security team that dialogs are often a poor solution, and some of the alternatives-to-dialogs that Mozilla is trying: information bars, the site identity and permissions panel, and app tabs.
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.
Mozilla has been experimenting with alternatives to dialogs. Dialogs have lots of disadvantages: 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.
Sites don't really need to be able to suggest that you add them as a bookmark. It's only one click anyway.
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.
Instead, let users "do" those things, so the site doesn't have to ask the browser to ask the user for permission.
Screenshot from Firefox trunk (4.0b2pre) on Windows Vista.
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.