Flash Hacks: Call Arbitrary JavaScript!

In the past I've been annoyed by the lack of HTTP header access in Flash. Turns out there are some hacks you can do to get around it. Let's say you want the URL of the web page that loaded the SWF. This would be the referrer of the HTTP request that loaded the SWF. Flash should provide access to that, but it doesn't because some browsers don't provide it this info. That's ok, you can get to it:

var hostPageUrl:String = ExternalInterface.call("window.location.href.toString");

That's right, you can "call" a JavaScript expression, not just a function defined on the page. Of course the key is that everything in JavaScript (and in ActionScript too) is a function. So any JavaScript expression is a function and thus invokable via ExternalInterface. You can see where this is going! Let's say you want the query string of the host page's URL:

var queryString:String = ExternalInterface.call("window.location.search.toString");

This will give you something like "?param=value&foo=bar..." What about the referrer of that page? 2EZ:

var referrer:String = ExternalInterface.call("document.referrer");

This is a classic case of Too Much Information, really. You are able to execute arbitrary JavaScript, ExternalInterface acts like an eval(). So you can do arbitrary badness like modify the DOM. You can also access cookies (document.cookie).

Of course the key to all of this is script access. The SWF needs to have it. If the SWF is from the same domain as the web page, it gets this by default. If not, then you need to set allowScriptAccess="always". That gives the SWF the keys to the kingdom, if you will. Of course you could use an IFrame for the SWF and sandbox it in.

Flash and HTTP Headers Redux

A few months ago I wrote about the lack of access to HTTP headers in Flash. I recently came across some other people talking about this. This has caused debate about Flex being able to support REST.

The opinion seems to be that Adobe does not allow this because not all browsers will provide this information to the Flash player. I have not seen a list of what browsers have this limitation, though I will speculate it must be older versions of popular browsers... Some of the evidence of this is that this is provided in AIR. In AIR, it is the runtime itself that makes HTTP requests. In a SWF running in a browser, the runtime relies on the browser. So restrictive browsers could be an issue on a SWF, but never for an AIR app.

Could another reason be security? In particular, cookies are passed back-and-forth via HTTP headers. There are numerous cases of cookies being stolen by malicious JavaScript, which has total access to HTTP headers. Adobe made a lot of significant security improvements between Flash Player 8 and 9. In a world of mashups, are they better off continuing to deny access to HTTP headers?

All of that being said, I recently ran across another case where this causes problems. I had a SWF that could be loaded by two different pages. It needed to show slightly different features depending and have a different look and feel depending on what page it was on. The easiest thing to do would have been for it to "know" what page was loading it by looking at the referrer on the HTTP request that loaded the SWF. This is a header of course, and thus not available. Instead a FlashVar could be passed in to tell the SWF what to show. That's a better way to do it, but required changing the code of the page hosting the SWF, which was not an option. The hack that had to be used was to have to logical copies of the same SWF, foo_A.swf an foo_B.swf. The SWF could then look at its this.loaderInfo.URL to figure out what to show.

Hacking My A950

About a year ago, I switched my wireless service to Verizon and bought a Samsung SCH-A950. It has a lot of nice features, but in typical Verizon fashion, some of these were crippled.

First off, it is a music player, but Verizon made it where it could only play WMA files, not MP3s. I had read that Samsung included an MP3 player, but Verizon just disabled.

Next, while it is a Bluetooth phone, it only supports Headset and Hands-free profiles. In particular, it does not support Dial-up networking. That's a real shame given the EVDO network it can connect to.

I had found this link on enabling MP3 and DUN, but it seemed like too much trouble. But today I cam across this gem. I enabled the "Hidden Menu" by simply punching in 1475369126874#*. From there it was easy to enable MP3 playback. I haven't tried the DUN option yet, since it's not over Bluetooth and thus it's not as interesting to me.