Applet may script when mayscript="false"

Wanda Web Developer wanted to update her web site with a nifty Java applet that she found on Google. Because she didn't know the author of the applet personally, she had some trepidation about whether it was safe to embed this third-party applet.

"This applet seems innocuous today, but what if it hijacks my user's sessions tomorrow?" she wondered.

Wanda read the Sun developer guide and discovered that the netscape.java.JSObject API could be used to script the containing page. To her delight, she discovered the mayscript property on the applet tag could be used to block this API, rendering it inaccessible to the applet. She embedded the untrustworthy applet with mayscript="false" and slept soundly that night, satisfied that she had done her part to keep the users' accounts out of harm's way.

Wanda awoke the next morning to discover that her web site had been hacked. It seems the mayscript property hadn't controlled the applet's ability to script the embedding page after all. Although the applet's attempts to script Wanda's web site using netscape.java.JSObject were thwarted, the applet's showDocument API was still left wide open. The malicious applet navigated the parent window to a javascript: URI, which executed with the privileges of Wanda's domain. Her users were helpless and unaware as the applet silently hijacked their sessions.

Wanda promised her users that she would find a new way to embed interactive third-party content without exposing them to scripting by the content author. She read the Flash Security Guide, where she learned that SWF movies can also script the containing page. Fortunately, the allowScriptAccess property can be used to limit the SWF movie's ability to script the containing page. However, Flash also provided a navigateToURL API that looked suspiciously similar to Java's showDocument. Determined not to disappoint her users again, Wanda created her own SWF movie with allowScriptAccess="never" and confirmed to her satisfaction that it was indeed unable to script the parent page, even when it used navigateToURL with a javascript: URI.

Wanda replaced the misbehaving Java applet with a slick new SWF movie. She was pleased to note that her users' web browsers no longer froze for 3 seconds every time they visited her site. Confident that she had verified the safety of her new embedding technique, she again slept soundly.

Unfortunately, Wanda's diligent analysis missed a much larger problem lurking in navigateToURL: CVE-2007-6244, a vulnerability that could be used to attack not only her own site but any site on the Internet. It turns out that navigateToURL has an optional second argument, which allows a SWF movie to choose a target window to navigate. Unfortunately, Flash Player checks only whether the movie can script the embedding page, not the target page. By navigating Wanda's site to a javascript: URI, the attacker could have executed arbitrary script in the context of her site, hijacking her users' sessions once again.

Thankfully, Wanda's site was not attacked that night, nor any of the following nights. As of today, Adobe has patched Flash Player to handle javascript: URIs safely. But this would not be the last time Wanda would wrestle with navigateToURL and its cousins...