Demystifying/Abusing Flash Cookies

Flash Cookies (aka Local SharedObjects) are increasingly being leveraged by developers as a powerful alternative to HTTP cookies, yet there seems to be significant confusion as to what they are capable of and what security/privacy risks they may expose. I feel that most users are at least familiar with cookies in general, and to some extent this technology has taken a bad rap as a privacy concern. While cookies certainly can lead to privacy concerns, we should keep in mind that they have become a key component in today's rich web applications, enabling persistence which is leveraged for authentication, user preferences, etc. As end users have become increasingly uncomfortable of the existence of data which permits sites to track their web clicks, they have begun disabling cookies within their browsers or adopting applications which permit the blocking of cookies. Yet, what many don't realize, is that the same tracking features they are trying to avoid are not only alive and well, but exist in a much more powerful form, thanks to Flash cookies.

Local SharedObjects were first introduced in Flash Player 6.0 in March 2002, so they've been around for a while. Combine this with the fact that (thanks largely to YouTube) Adobe is able to claim being present on 99% of Internet enabled desktops and Flash becomes a de-facto standard client side platform. Flash Cookies offer developers more flexibility than their HTTP based counterparts in virtually every category:

• Storage Capacity - By default, sites can store up to 100K of data on a local file system and no explicit consent is required form the end user. HTTP cookies can likewise store data without asking permission but are limited to 4K in most browser implementations.
• Expiry - HTTP cookies are either session based, meaning that they are wiped upon exiting the application/browser or have an explicit expiration date. Flash cookies on the other hand, by default have no expiration.
• File Format - Flash cookies are stored in a binary format, but contain text based data, so they're easy to read directly from the file system, so long as you know where they're stored (see below). There are also a variety of LSO readers that can be used.

LSO Storage Locations

• Windows XP
  • $user\Application Data\Macromedia\Flash Player\#SharedObjects
• Windows Vista
  • $user\AppData\Roaming\Macromedia\Flash Player\#SharedObjects
• Mac OS X
  • ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects
• Linux
  • /home/$user/.macromedia/Flash_Player/#SharedObjects

From a developers perspective, the greatest advantage of Flash cookies appears to be the fact that users aren't overly familiar with them an wouldn't know how to delete them even if they were. In fact it wasn't until Flash Player 8.0 was released that Adobe actually added a Settings Manager to permit users to see and manage the Flash cookies on their system. This is the same control panel which was previously vulnerable to clickjacking. Browser privacy features which permit users to wipe local content including HTTP cookies do not presently touch Flash cookies, although I wouldn't be surprised to see this change over time.

Common security concerns for HTTP cookies outside of privacy involve cookie hijacking or injection or more generically, the ability to read from or write to a user's cookies. This is a significant threat given that cookies maintain persistence for authentication purposes and it is especially concerning given the prevalence of cross-site scripting vulnerabilities which facilitate such attacks.

Is cookie hijacking/injection possible with Flash cookies as can be done with HTTP cookies? The answer is yes, so long as the attacker has an ability to upload Flash content to the target domain. While this is a significant hurdle, the prevalence of Flash on the web and the acceptance of user supplied content on web sites, means that this isn't as difficult a challenge as you might think. As with HTTP cookies, Flash cookies enforce a same origin policy. Flash cookies can also restrict access based on the path where the Flash cookies are deployed. For example, a site where users have personal content (e.g. domain.com/user_page/), which stored all file uploads in one place (e.g. domain.com/all_files/) instead or user specific locations (e.g. domain.com/user_page/all_files/) could expose itself to attack. If Flash content can be uploaded, an attacker simply needs to build a Flash file which can read from/write to an existing LSO. While the name of the LSO is required, this is a trivial challenge as such data is already stored on the client side. The following ActionScript code sample permits writing to a Flash cookie:

package {

import flash.net.SharedObject;
import flash.display.Sprite;

public class zscaler extends Sprite {
private var user:SharedObject;
private var firstname :String;
private var lastname:String;
public function zscaler() {

user = SharedObject.getLocal("zscaler");
firstname = "Michael”;
lastname = "Sutton";

user.data.firstname = firstname;
user.data.lastname = lastname;

user.flush();
}
}
}

Once the code is written, it must be compiled into a *.swf file, which can be done using freely available tools such as the Adobe Flex 3 SDK, which includes a Flash compiler. In the above example, an LSO named zscaler is created which has two variables (firstname and lastname). Reading from an existing Flash cookie is equally as easy:

…
public function zscaler() {
var label:TextField;

user = SharedObject.getLocal("zscaler");

firstname = user.data.firstname;
lastname = user.data.lastname;

label = new TextField();
label.autoSize = TextFieldAutoSize.LEFT;
label.background = true;
label.border = true;
label.text = "Firstname: " + firstname + "\nLastname: " + lastname;

addChild(label);

user.flush();
}
…

The code has been abbreviated as it's largely identical to the previous sample. In this case, we once again call getLocal() using the name of an existing LSO and then simply read existing data (e.g. user.data.firstname). The example will display the contents of these variables in a text box.

If you're curious to know how many sites are leveraging Flash cookies, simply check the Website Storage Settings panel in your Adobe Flash Player Settings Manager. I suspect you'll be surprised to see how many sites are leveraging this technology. Also take time to browse through the content of these LSOs. Given the larger storage capacities available, you may find some interesting and perhaps insecure content.

Take care.

- michael