TechNote (Archived)

Cross Site Scripting in Flash

If you develop web applications then you should be familiar with a common source of security issues known as cross site scripting (XSS). XSS problems can arise when an application accepts data from an untrusted source, and then displays it to a user within the web application. The application may be expecting only text, but an untrusted source may attack the application by providing script as well as text. Because the attacker's script is run within another developer's application, XSS is also known as script injection.

The archetypal example of an application that is vulnerable to XSS is a bulletin board application that accepts postings from users and then displays them to all of the users. If some users embed JavaScript in their postings, then that script will be executed by every user accessing the bulletin board. That script will run with the privileges of the bulletin board application, creating a security problem if the application has sensitive information that can be accessed by this script -- such as the user's cookies. This information can be retrieved and then transmitted to another location on the internet.

Flash Safety Features

There are a number of design factors that increase the inherent resistance of Flash applications to Cross Site Scripting.

Unlike many web enabled technologies, Flash uses a compiled scripting language. A compiled language cannot itself be vulnerable to XSS, so XSS is possible only if HTML and scripting features are used in an application.
Since the Flash Player's internal HTML engine doesn't provide a JavaScript engine, all potential XSS attacks require a user to actively select a hyperlink to run the script.
The Flash Player's sandbox security model prevents the transmission of sensitive information to other sites -- which will further decrease the possibility of successful XSS attacks.

Input Validation Considerations

Although numerous design considerations make XSS substantially more rare when developing Flash content, there are some places where improperly developed applications may have XSS concerns. It is imperative that Flash developers apply the same best practices for development when building Flash applications as when building an old-fashioned web application -- all input should be validated to make sure it is of the proper format and contains only expected data. In order to prevent XSS attacks, all input that is coming from untrusted sources (such as users) should be inspected to make sure that it doesn't contain script.

The following are some areas that Macromedia has identified as possible sources for XSS problems within Flash.

Untrusted URLs

Most Flash developers are familiar with the http:// or https:// style of URL, but you may not be aware that the URL format actually provides a wide variety of protocols. For example, the flash player provides support for javascript:// URLs -- a convenient mechanism for executing script from within the player.

It is rare that a developer will want to include a dynamically generated URL, but if that is necessary in your application, make sure that the data used to construct the URL cannot influence the protocol specification.

Untrusted HTML

Flash text can be rendered as HTML. Although the HTML engine does not provide direct support for JavaScript, it does provide facilities for including hyperlinks to URLs. The supported URLs include the javascript:// URL described above.

If you are developing a Flash application using HTML TextFields that accept data from untrusted sources, then data should be validated to prevent embedding javascript:// URLs.

Conclusion

Flash provides a number of safety features that make it resistant to Cross Site Scripting, one of the most common vulnerabilities in web-enabled applications. Nevertheless, developers should carefully validate any input from untrusted sources to make sure that it does not include script. This is especially true for applications which generate URLs or HTML from this input.

Macromedia would like to thank INSI for working with us on this TechNote.