Hacks #97-100
With HTML-based web sites, a user can quickly download a site's source files and review them without permission (by definition, the HTML page is just a text file that is sent to the user's browser or any client that requests it). A web browser or "site-sucker" program can also easily download any text and images displayed on a web page. Unfortunately, copyright laws offer scant protection, especially outside the United States and Europe, so most site owners accept that content will be copied or try to adopt technological defenses against it. On the mild end of the spectrum, a developer might add a visual copyright watermark to her images, forcing would-be pirates to at least edit out the watermark to cover their tracks. On the more aggressive end of the spectrum, files can be invisibly digitally watermarked to prevent their playback on unauthorized systems (of course, all such digital protection is prone to cracking, and we don't deal with that extensive technical and politically charged subject here).
The SWF file format is binary, so it cannot be read as easily as a text file, but this offers little extra protection. It simply requires software designed to read the SWF file format, which Macromedia makes publicly available at http://www.macromedia.com/software/flash/open/licensing/fileformat. (The license is free, but the SWF format is still proprietary to Macromedia, not open source.) For those interested in writing software to create SWF files, see OpenSWF.org (http://www.openswf.org), a resource site for developers working with the SWF format.
A number of Flash SWF decompilers and content extractors?including ActionScript Viewer (http://buraks.com/asv), the first one to hit the market a few years back?are available.
So SWF files suffer from the same vulnerability as traditional web assets. There is no way to prevent the resourceful cracker from looking at your assets and code, so don't store sensitive information, such as passwords, in your SWF file. However, you can at least make theft more difficult for the cracker because many will give up rather quickly when faced with obstacles or pursue a more vulnerable site.
Aside from content theft, a bigger issue is security. In traditional web design, no sensitive information should appear in any downloadable files or any file that can easily be opened or copied. Instead, secure information should be transmitted directly between the client browser and the web server. Such transmitted data is not saved by the browser, but it can still be captured.
Flash doesn't implement its own security protocol but rather piggybacks onto the browser's support for encryption. So when you use URLs starting with the "https:" protocol, Flash uses the browser's HTTPS services, if available, to transmit the data. Therefore, you should ensure that the user's browser supports HTTPS and uses an HTTPS server to encrypt all transmitted information. For example, a so-called Password field (available as an option for Input Text fields via the Properties panel) offers no security. It simply obscures the input with asterisks but still allows the plain-text password to be transmitted to the server. Readers unfamiliar with over-the-wire security should understand that sending sensitive information, such as credit card numbers or passwords, as plain text instead of in encrypted form across an open channel is inviting trouble. A packet sniffer can easily intercept your client-server traffic as it wends its way across the Internet. Encrypted information can also be intercepted, but it can't be decoded as readily as plain text, so intercepting it does the cracker little good.
There are related security concerns when using adjuncts to Flash, such as Flash Communication Server MX (FlashCom server). A FlashCom stream, such as audio or video, should not be considered secure because the transmission protocol used (Real Time Messaging Protocol or RTMP) is not secure. FlashCom applications can still use a secure server for normal (non-media) HTTPS transmissions. The Macromedia Flash Communication Server MX Security Overview whitepaper at http://www.macromedia.com/devnet/mx/flashcom/articles/security_overview.html discusses FlashCom security.
Likewise, server-side code that is improperly protected can represent a security risk. When using Flash Remoting, developers can write their server-side code in various languages, including Server-Side ActionScript (SSAS), which is supported for ColdFusion and JRun installations. Like many server-side scripting languages, SSAS code is stored in a plain-text file on the server (the code is stored in ActionScript Remote files with an .asr extension). However, in their default configurations, many web servers, including Apache and Microsoft IIS, don't specify the .asr file extension in their list of nonbrowsable file types. Therefore, if a user browses to the URL of an .asr file, he can download it and read the code in plain text! This is a real security flaw because some ColdFusion and JRun developers use SSAS to query a database or work with the filesystem on the server. If a cracker can read the contents of an .asr file, he can learn about your database and file structure and likely exploit your system's vulnerabilities.
|
Flash security is a big topic that cannot be covered exhaustively here but is well documented elsewhere. The Macromedia Flash Developer Center security page at http://www.macromedia.com/devnet/mx/flash/security.html provides links to additional security whitepapers that cover Flash MX and Flash MX 2004 (Flash Player 6 and 7) and the security sandbox in which they operate (to prevent virus attacks, denial of service attacks, etc.).
Although Flash shares the same security issues as many other web technologies, Flash presents several special cases:
Flash Player 6 and 7 can retrieve data from a locally connected microphone or video camera. Flash can also store information on the local hard drive, but because Flash is a media delivery plugin, the stored information may be much larger than a typical browser cookie. Flash's privacy settings allow the user to limit Flash Player's access to the microphone, camera, and hard drive.
Macromedia's uses cross-domain policy files to control the ways in which Flash content on one domain can access content on another domain.
Flash can run as an application in a Standalone Player, independent of the browser as described under "Handling Local Executables."
