Introduction

Most of the W3C specifications and documents are about presentation, and so it is to be expected that we should be concerned about security at the presentation level. In addition, the other groups that we work with are typically less concerned about this level (e.g. the IETF is more concerned about protocol security), and the W3C needs to take leadership. A number of issues arise in presentation, and more specifically, in the user interaction with the presentation. This page attempts to collect these issues.

Spoofing

Spoofing occurs when a web page (or something presented in accordance with W3C specifications) is authored to 'look and feel' like something else, and thereby entices the user into performing actions on a web page when they think they are working with something else. The most commonly cited is the case when a browser allows 'full screen browsing' and then a web page is authored to look like the desktop. It's not hard to present something that says 'A security problem has arisen; please re-enter your password', or to encourage 're-login' to bank accounts etc. Spoofing can also be done within a window, presenting something that looks as if the operating system had popped it up over the window (e.g. asking for a password) when it is, in fact, still within the window.

There is a discussion of this in a W3C document and a security page on one manifestation of this issue at Mitre.

UI Redressing (clickjacking)

It is sometimes possible to author pages which allow the user to think that they are interacting with a particular resource, when in fact their 'clicks' (and often keystrokes) are being hijacked from that resource and captured by something else. A transparent overlay over a bank log-in window might, for example, capture the password as it is typed in, and so on.

There is a page on this subject on Wikipedia.

IDN Spoofing

(This section might not have the appropriate title)

Even without using characters outside 'traditional ASCII' it is possible to write URLs that appear (visually) the same as or similar to other URLs, and thereby entice unwitting users to visit web sites other than the one they thought they were visiting (examples include WWW.G00GLE.C0M, www.appIe.com, and so on). With the use of full Unicode, the opportunities and problems become much wider. This is a subject of debate in both the IETF and the Unicode consortium.

There is a Wikipedia page on this issue.

There is a draft Unicode Tech Std #46, Unicode IDNA Compatibility Processing on this issue.

Other Unicode documents that discuss domain-name security (and other issues) include:

Unicode Tech Std #39, (deals with confusables), latest draft udpate at: Unicode Security Mechanisms
Unicode Tech Report #36, (deals with spoofing), latest draft update at: Unicode Security Considerations

IETF documents:

IDNA 2003 RFC 3490.
document index for IDNA bis.

Another variation of this is link manipulation. An example of this would be example.secure-login.com versus secure-login.example.com. Users can make the mistake of perceiving these as equivalent when the primary domain is very different. Wikipedia has a reference to this as well.

Login and Identity Issues

The increasing use of logins, and the varied ways in which they are shown to the user, and implemented, can result in some security issues. Login redirects like those used in OpenID and OAUTH, if not mediated by a trusted UI, habituate the user to a specific insidious kind of spoofing (diagrams and other explanations can be found in this PDF).

RTL/LTR unicode chars

A prompt like:

The website [URL] wants to be your default homepage, ok? [OK]

with this input:

http://example.net/?x=[RTL]x?detacsufbo/moc.elpmaxe.www//:ptth gnihtemos uoy wohs ot stnaw

will be shown in some browser's dialogs as:

The website wants to show you something http://www.example.com/obfuscated?x?ko ,egapemoh tluafed rouy eb ot stanw=x?/net.tackcradris//:ptth

Security Status of Web Pages

User agents are expected to show users if sites are "secure", and if not the reasons they aren't. Using HTTPS is not the only factor, using weak encryption methods, including insecure content (maybe just the favicon, or an XML file for a plugin), the method of access, certificate failures, protocol version, OCSP and CRL issues (including network issues) and EV status are other factors. Some user agents will also flag the security based on previous visits, or on centrally managed repositories or lists. Exactly what constitutes a secure page in corner cases is open for discussion, and user agents vary in what they display.

Doubleclicking

Many users are used to double clicking on items, and e.g. Flash games will often use this even on the Web. Double clicks can also be interpreted as two single clicks. If the frontmost page disappears on a first click, then the second click will be processed on whatever was behind it. This opens for attacks where the user can be tricked into clicking (i.e. allowing) something he wasn't planning to. Common protections against this in native UI is a timeout after focus before "dangerous" buttons (such as "Execute downloaded file") are enabled, while there are few protections against this on Web pages. This is related to clickjacking.