flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [DISCUSSION] TourDeFlex 1.2 RC 0
Date Thu, 06 Nov 2014 08:20:57 GMT
Going to try to consolidate this thread a bit.

On 11/5/14, 11:53 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

>> The Ardisia example sizing problem feels like a SecurityDomain issue.
>> After you force a resize with the divided box, the app scales down to
>> instead of resizing.  Third-party content may not size correctly unless
>> “import loaded” which I don’t think is the default.
>Tour De Flex uses mx:SWFLoader to load content and doesn't set
>trustContent (which defaults to false) so I believe that means that
>content isn't being "import loaded". [1] Setting it to true would make it
>"import load" but that has other implications. (see line 1896 of
>SWFloader.as which sets the loaded contents securityDomain to be
>the.current domain)  Scale content default s to true [2] so I'm not sure
>that explains the odd clipping.

If trustContent=false, the SWFLoader doesn’t know it loaded another Flex
SWF.  There is code in SWFLoader that tries to size loaded Flex SWFs
differently than other SWFs.

From your other post:

> There's already a wildcard cross domain file for Flexicious [1]

Gee, I sure hope Flexicious doesn’t also serve internal apps off this
domain.  A wildcard crossdomain.xml is equivalent to leaving the door
unlocked.  If the door is for a refrigerator and you are giving away free
beer, that’s great, but if it is the door to your house and you keep other
valuables in the house, you are more likely to get robbed.

>>And if import loaded, then SWFLoader should have trustContent=true, but
>>probably only when loading third-party, just to be careful, and maybe
>>its own whitelist of domains baked into the SWF.

>Which would mean we need to make a release every time we add a 3rd party
>example which is what we are trying to avoid in the first place.

We have to decide how secure we want to be.  If we accidentally leave a
hole where someone can inject a URL to load, it might get exploited.  If
we put a whitelist in an XML file on our server, that might be secure

> If (and I can't imagine this happening) we find that a 3rd party
> is doing something naughty we can just remove them from the 3rd party
> file until they fix the issue.

IIRC, there are two issues:

A) How hard do we have to try to prevent bad stuff from happening?  It is
fine to stop using a credit card reader that is stealing credit card
numbers once you know about it, but should we have made it harder for
someone to hack it?  It isn’t that the folks who have submitted examples
to us are evil, but what if one or more of them is some other popular
third-party library that turns out to have a security hole?

B) Similarly, the third-party may not trust Apache Flex TDF to be a good
secure host.  What if there is a security bug in Apache Flex SDKs or in
TDF?  Or in some other third-party example?  If FooCorp supplies us an
example that uses a third party library with a security hole, it could
attack the third-party example supplied by BarCorp.  BarCorp may prefer to
remain sandboxed for that reason.

Fundamentally, bad people suck, and there are too many of them out there.


View raw message