enforcing a stricter Flash security policy
Sunday, 16. September 2007, 23:12:54
Since Opera 9.5 'Kestrel' is in beta, it contains some experimental stuff. "Beta" means "things will be broken", and here's a case where it means "we've broken this on purpose": 9.5 contains a hack to make Flash content default to a more secure security policy.
Flash can communicate with JavaScript in a page. Since you may not trust some random Flash content in your site (think external ads or embedded media players) Macromedia (back when it was still known as Macromedia) came up with the allowScriptAccess attribute. When you embed an external Flash you should specify allowScriptAccess=samedomain as an embed attribute or PARAM to make sure the Flash isn't allowed to talk to JavaScript in the page.
The problem was that when Macromedia invented the allowScriptAccess attribute, there was already quite some Flash content out there, and most likely a lot of it relied on the non-enforcement of cross-domain security policies. They decided to make the Flash player default to always allowing script communication. Defaulting to the least secure option is bad, but they probably felt they had no choice if the alternative meant temporarily breaking thousands and thousands of Flash sites.
With 9.5 previews, if you forgot to add allowScriptAccess=samedomain, Opera will add it for you when invoking Flash. This will break sites, we're well aware of that, and we're already seeing some really high profile casualties. The point of enabling this hack was seeing how many broken sites we could find, to evaluate whether we should remove the hack again or keep it for Kestrel final..
A typical symptom is un-closeable Flash overlay ads, so please look out for those and report anything you come across! It's not unlikely that we will have to revert this feature, but meanwhile we'll keep breaking the web - one Flash site at a time.
Flash can communicate with JavaScript in a page. Since you may not trust some random Flash content in your site (think external ads or embedded media players) Macromedia (back when it was still known as Macromedia) came up with the allowScriptAccess attribute. When you embed an external Flash you should specify allowScriptAccess=samedomain as an embed attribute or PARAM to make sure the Flash isn't allowed to talk to JavaScript in the page.
The problem was that when Macromedia invented the allowScriptAccess attribute, there was already quite some Flash content out there, and most likely a lot of it relied on the non-enforcement of cross-domain security policies. They decided to make the Flash player default to always allowing script communication. Defaulting to the least secure option is bad, but they probably felt they had no choice if the alternative meant temporarily breaking thousands and thousands of Flash sites.
With 9.5 previews, if you forgot to add allowScriptAccess=samedomain, Opera will add it for you when invoking Flash. This will break sites, we're well aware of that, and we're already seeing some really high profile casualties. The point of enabling this hack was seeing how many broken sites we could find, to evaluate whether we should remove the hack again or keep it for Kestrel final..
A typical symptom is un-closeable Flash overlay ads, so please look out for those and report anything you come across! It's not unlikely that we will have to revert this feature, but meanwhile we'll keep breaking the web - one Flash site at a time.
the backtrace of an Y!Mail debug sessionfunction(p,a,c,k,e,r) de-mystify trick
You must be logged in to write a comment. if you're not a registered member, please 
By dduenker, # 16. September 2007, 23:30:49
By Darken, # 17. September 2007, 00:40:55
By Darken, # 17. September 2007, 02:29:52
The only difference between this and newer version is one added property for opt object so this should make no difference.
The only problem I see is that "Click to activate this object" is triggered for all flash objects. Even those added by UFO for example.
BTW: hallvors status: "Playing with soon usable JS debugger prototype
Hate you.
By d.i.z., # 17. September 2007, 09:05:11
Originally posted by d.i.z.:
Noticed that too. And what i'm really interested in is what does that 'soon usable' mean exactly: does it mean we'll soon be able to use it?
By profiT, # 17. September 2007, 10:56:57
By hallvors, # 17. September 2007, 12:51:24
By FataL, # 17. September 2007, 15:34:24
Originally posted by d.i.z.:
Same "problem" with UFO 3.22.
By Darken, # 17. September 2007, 22:31:01
http://www.pentaxian.com/
Doesn't work well under Opera (it's a flash based site).
By Drazick, # 18. September 2007, 10:46:26
www.smog.plwww.pudelek.pl
Floating ads should come up if you browse a bit.
These ads are served from o2.pl. This is quite big portal in Poland that made one of the most popular IM programs in here (Tlen). I expect to have ads from this company in a lot of pages.
And so the story repeats: http://zajec.net/bug/flash_xss .
IMO, if you really need this security measure, you should wait till one of the more popular browsers implement it. Or else, there will be more problems for Opera.
By d.i.z., # 19. September 2007, 19:12:54
Polish version of www.idg.com
This one uses adocean.pl ad company as far as I see from linked scripts.
I guess that polish sites are little of interest to you but whatever.
By d.i.z., # 19. September 2007, 21:06:17
Regarding your flash_xss test case:
- the JS security model doesn't work like that. An external JS file included in a page has complete access to the page, so we could not give the external flash access to the script from the same server without basically giving it 100% access.
I think we'll revert this security hack for HTTP pages but keep it for HTTPS. It might still break some sites but I think this issue is important.
By hallvors, # 20. September 2007, 00:10:35
Anyway, it shows the 'problem'.
By d.i.z., # 20. September 2007, 08:19:28