Skip to main content
R
Rezmason
Participating Frequently
February 23, 2010
Question

TLF Sandbox Violations

  • February 23, 2010
  • 1 reply
  • 1809 views

Hey TLF Team,

I posted these two issues as comments on your blog, but I had a feeling that that wasn't the proper venue. Also, if anyone else discovers similar issues, now there's a place to post and discuss them.

The issues in question involve parts of the TLF that throw security sandbox violation errors when the framework is used in a SWF that's loaded from another security domain. By allowing the loaded SWF's domain to cross-site-script, these problems go away, but not all content can be trusted with cross-site-scripting. TLF contains an interface called ISandboxSupport, so I'm certain you guys have considered the issue already. This is just a list of errors that crop up in the current TLF version.

  1. SelectionManager.checkForDisplayed(), attempts to climb from the container's parents to the stage, to determine whether the container is in the display list. A current workaround is to make the container a subclass of Sprite, which overrides the parent getter to return the stage.
  2. ContainerController.getContainerController() also climbs the container's parents, looking for lord knows what. The only current workaround for this is to subclass ContainerController, rewrite getContainerController() so that it catches the error and override focusChangeHandler() to use the new getContainerController() function. Because most people don't have the TLF source, this workaround is relatively difficult for most people to work out.

If I find any more sandbox violations, I'll post them here, instead of cluttering up your blog.

This topic has been closed for replies.

1 reply

A
Anonymous
February 23, 2010

Thanks for the error list - I'll log bugs for them. I did see the blog comments, but you're correct that this forum has more people reading and responding to posts.

R
RezmasonAuthor
Participating Frequently
March 5, 2010

Another violation, this time in LinkElement.stageMouseMoveHandler. Apparently you're listening to root for mouseMove events (?!) and checking to find out whether the event's target is contained within a LinkElement. It does this by climbing up the display list until it reaches null; bumps into trusted content, which then throws the cross-site violation.

The only workaround is to not use links in TLFs in untrusted SWFs.

Edit: Another workaround is to override the parent getter on the untrusted SWF's main class to return null. This actually helps deal with a lot of similar situations.

This is probably out of line, but I think LinkElement.stageMouseMoveHandler() may be unnecessary, guys– it's potentially expensive, and it looks like it's there to overcome some problems with mouseOut events. Why not use rollOver and rollOut for LinkElements?

A
Anonymous
March 5, 2010

Thanks again - I'll log another bug.

And you're not anywhere near out of line - I'm extremely happy to get this kind of feedback. We've put the code out on open source so that people like you can show us how it can improve. I'll make sure that the engineers can justify stageMouseMoveHandler() and have them post a response.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices