last updated: 25.August.2002
© 2001,2002 EyeonSecurity,
Redistribution of this document is permitted as long as the contents
are not changed and this copyright notice is included.
Web Applications consist of non-static web sites, which allow users to interact with the site itself. Examples of such sites include Hotmail, Yahoo, MSN communities and a long list of other sites. Most of the times, this interaction involves users being authenticated, to provide a multi-user environment.
In an online community such as deviantART, each member has his own section and web space, where he or she can upload artistic material, such as poetry, graphics (usually jpg format), photography, and of course, Flash movies. Logged on users (as well as anonymous ones) can also view other people’s work. This means that files and content are shared between different users. From a security point of view, this means that the shared content has to be trusted by both the owner of the content, and the person viewing the file.
– current methods
Most security aware Web Applications usually take either of the three approaches to disallow XSS attacks:
Some Web-Applications that allow Flash content to be uploaded specifically allow flash such as deviantART, others just allow files to be stored on the server for later retrieval, similar to FTP sites.
This document will describe how such content filtering can be easily bypassed because of lack of foresight in the Web Application design. The loophole described here consists of trusting Flash documents (or movies as referred by Macromedia), and therefore not treating this material as Active Content.
Ezboard (http://www.ezboard.com/) is probably one of the best well-known free online Bulletin Board Systems around. This BBS which is HTTP-based, allows its users to have their signatures in flash by making use of the EMBED tag. Therefore in our tests we edit our preferences and specify the following code in the signature:
The below screenshot illustrates the idea better.
This code will be added to each post the attacker submits on the Ezboard forum, allowing him to steal the user’s session cookie.
DeviantART which is a very popular website, encourages it’s users to submit flash animations and creations to be viewed by other site members. Of course a malicious user with intent to steal user accounts and possibly administrative accounts, would create a new account, upload a malicious Flash file and wait for the results. No demonstration is available for this site.
Two specific Forum (BBS) software, which are particularly vulnerable to this attack, are Ikonboard and YaBB. These particular forums allow only specific custom tags which are then parsed by the Web Application to produce the end result. However these forums allow flash animations to be embedded within the page by using the [flash] special tag, which is converted to the correct Object tag.
The above would be interpreted by the script and transformed to:
Of course these specific examples are not the only vulnerable systems around. Any online service, which allows Flash content to be inserted is vulnerable to XSS attacks. The vendors and services described in this section have been notified of the flaw before this document has been made public. This means that the specific examples outlined in this section might have been fixed when you are reading this.
Simple solution: DO NOT ALLOW FLASH FILES IN YOUR WEB APP.
However in most cases, the solution is not that simple. Consider the case for deviantART for example. Flash animations are part of the content of the site. Such content is considered critical for the Flash community within deviantART.
Possible solutions for:
Macromedia (Flash player developer)
Macromedia and EyeonSecurity have worked together to provide a solution for Web developers. It was suggested to allow Web designers to change the behavior of embedded Flash content within HTML pages. This solution addresses issues within forums and similar sites, but is designed not to break any exist animations/flash movies.
However such a solution does not address websites such as MSN Communities and deviantART. These sites allow users to upload SWF files rather than just link to them. Macromedia (as well as EoS) actively discourages web application design that allows users to upload unchecked Flash content.
Macromedia have released a bulletin about this issue on June 13, 2002.This document can be found at:
Web Developers and Web Designers
The above example will bypass any protection provided by the proposed solution, since there is no getURL(‘javascipt:whatever’) involved.
Yet another possibly more feasible solution would be to make use of a separate domain for storing and displaying the Flash movies. This method may also be used for other documents, such as HTML files, to allow Active Content without enabling attackers to obtain the session authentication by stealing the cookie. This means that if your domain is “securewebapplication.com”, you could store possibly malicious content on “securewebapplication.net”. Of course this means that the content of “securewebapplication.net” does not require session authentication and therefore this content is shared with anonymous users. It is important to note that the malicious content should only be displayed from a “sanitized” domain, meaning that if the flash document is contained in an HTML file, the HTML file has to be also displayed from the “sanitized” domain.
Suggestions for users of specific products/services
The response given by the product support of Ezboard was the following:
Unfortunately, it is very, very tough to make it impossible to make cookie stealing impossible. If we did, ezboard would not have nearly as many customization options as it currently does. Fortunately, we have a high security login setting which checks the user's IP address. If it is
selected, nobody else will be able to use the cookie to login while the real user is logged in.
This may a good solution, which addresses XSS issues, including the one described in this paper. However IP checking does not work well with Internet users behind proxies.
The solution response by Corey Chapman was:
We didn't build it as an option, but we've informed people to simply
comment out or delete the (I think 2) flash-rendering lines in
yabbc.pl. I'll probably build a disable feature in for the next
update, assuming there'll be one for this version.
This is quite straightforward solution. Of course we suggest also removing the Flash icon display when editing the message.
This product allows administrators to disable flash support, according to Andrew (Ikonboard).
This does open the
security hole that you mentioned, as people have used it before to
change people's avatars. The problem is that we can't just remove the
option as many users would be very unhappy with us. As it is right now
you can disable this option, and not allow flash on your board.
This sounds like a neat solution – however we did not test this feature.
For a demonstration of the issue described here check out:
XSS Faq by CgiSecurity.com
Information on Cross-Site Scripting Security Vulnerability by Microsoft
Understanding Malicious Content Mitigation for Web Developers
Malicious HTML Tags Embedded in Client Web Requests
Evolution of Cross-Site Scripting Attacks by iDefense
Web Application Security – General information
Open Web Application Security Project
Web Application Security - PowerPoint Presentation
Designer & Developer Center
Flash Kit – A Flash Developer Resource
OpenSWF.org – information about the Flash format
Bertrand Saint-Guillain for his ideas and e-mails about the problems in the suggested solutions. Bertrand Saint-Guillain is webmaster and designer of http://www.supersatori.com/
 What is a web application? http://davenet.userland.com/2000/03/12/whatIsAWebApplication
 Microsoft on XSS: http://www.microsoft.com/technet/security/topics/crssite.asp
 Thanks to Bertrand Saint-Guillain for pointing this out