Loader.load vs Loader.loadBytes
DIGG IT!
10
Comments
Published
Wednesday, January 16, 2008
at
7:30 AM
.
There is a very important security distinction between using Loader.loadBytes and Loader.load that EVERYONE needs to understand.
Loader.load loads content (PNG,GIF,JPG,SWF) into the security context of the url being loaded.
Loader.loadBytes injects bytes (PNG, GIF, JPG, SWF) into the security context of your application!!!
Loader.loadBytes is much like eval() and if used improperly it can inject a security hole into your application. Much like eval() it is very useful and allows you to do all sorts of great stuff but it can also cut your arm off and melt your tennis shoes.
So how harmful can it be, lets look at a simple example:
Load a PNG file from domain.com into your Flex app:
GOOD: Do this with Loader.load and you are safe as can be.
BAD: Do this with Loader.loadBytes and the injected image bytes will be processed like they were native code. If someone renames a .SWF file into .PNG, they have successfully injected data directly into your application running in AIR or Flash Player. If this SWF file were in AIR, it would have the ability to use any AIR apis and would create problems.
Note: The AIR team is looking at a minor API change for Loader to default loadBytes content into a security sandbox with an optional to override the new default behavior.
There are a few nice use cases for loadBytes in AIR:
- Obsfucate a SWF file - Load a binary file and reorganize the bytes into a functional SWF before loading into your application. You could use TEA encryption or a simple bit shifting pattern across the ByteArray.
- Provide try/buy functionality - Create 2 SWF files one trial and one purchased (encrypted) and provide the encryption key during software licensing.
Be careful when you use loadBytes, it can inject a security issue into your application if you do not know what you are loading. I will be updating my post on Progressive Image Loading as this methodology uses loadBytes and has risk.
Keep loading!
Ted :)
I lost my arm, tennis shoes, AND left nut to Loader.loadBytes
Loader.loadBytes ran off with both my girlfriend and my dog.
Ted, You should change this blog title. I think this is very important information.
It should also be mentioned that Loader.loadBytes is very useful for embedding SWF's if you want to AS to be preserved.
I don't play tennis so I think I'm safe.
I have a question. I have a flash animation that will read some XML. Inside the XML there are embeded PNG images in CDATA sections. They are base64 encoded. Now I use the Flex base64 decoder to decode the data into a ByteArray, and then I use the Loader.loadBytes to display the PNG.
It looks like you're saying this is bad. If so, then how do I take that CDATA and get the BitmapData?
Correct me if I'm wrong please... but I think the point is that the security issue comes up when you use loadBytes on data files not in your control. That is, if I'm loading my own files I won't make them do bad things. I think this might also clarify demi's question.
I disagree with you in considering this a legitimate form of obfuscation. If the key is discovered and the network packets are sniffed it's pretty easy to unpack everything (I think).
SWF-over-socket has the same problem I believe. Both these approaches are underestimating the caginess of hackers, who are willing to save a swf and log the network traffic, only to unencrypt it sometime down the road.
AIR apps might be able to use this because they can also maybe be installed with a fully-compiled (i.e. from C) client-side app running that does the decryption for it and communicated via shared memory or something else.
I recently started an open source flash decompiler project with the goal of eventually making an obfuscator for AS3/Flash9/Flex2. It's written in AS3 to make it easy for people in the Flash community to contribute.
I have no faith that all flex apps won't be decompiled someday soon. I'm sure that MS and Google will both have decompiled versions of Buzzword in the near future (if they don't already).
Personally I think Adobe can and should do more with respect to obfuscation. It might sound paranoid, but I'm starting to think that Adobe wants Flex apps to be decompilable across the board because that will help companies steal flex code from other companies and eventually help flex spread. I wouldn't even suspect this if I didn't know just how easy it is for Adobe to make an obfuscating version of their compiler.
It looks like they have solved the security issue in Flex3: you're not allowed anymore to load executable code...
Ok, but what if I use a intermediary SWF as a separate security domain and use trustContent="false"?.
Step 1: use SWFLoader to load the a second SWF as non-trusted.
Step 2: Pass it some parameters ( via query string maybe? ) so that the SWF knows which image URL to call.
Step 3: Non-trusted SWF loads the image. ( hofully inside it's own separate security sandbox ? )