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.
- 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
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
Posts
0 comments:
Post a Comment