Repository navigation
Conversation
| @@ -0,0 +1,3 @@ | |||
| SecurityError: Error #2146: Security sandbox violation: file:///test.swf cannot call navigateToURL because the HTML/container parameter allowNetworking has the value none. | |||
There was a problem hiding this comment.
How did you get these outputs? I.e. how to configure the standalone player to change the value of "allow networking"?
We do have an executor for Flash Player, so ideally we would configure the player there when the setting is enabled.
There was a problem hiding this comment.
That is not possible, as mentioned in the description.
Do we have a runner for Flash inside the browser?
There was a problem hiding this comment.
We don't, but we could add a web runner.
In order to make it clearer from the tests perspective I would do the following changes:
- load the SWF via http and not files (we have the localhost directory, but not sure if we can load the root SWF this way),
- add a second test.toml property that specifies which version of flash should be used to run this test in (e.g. `flashplayer_edition = "sa"/"web"),
- filter out web tests for now in the executor.
There was a problem hiding this comment.
Of course log_fetch is problematic here as well, but that's preexisting. If you can assert in a different way that no request was made it would be better (e.g. via event listeners).
There was a problem hiding this comment.
To be clear: this is not blocking, a lot of other tests cannot be executed OOTB in flash player as well
danielhjacobs
added
A-avm2
Ruffle gave Flash files script access to the page by default. When loading a URL, it sets `allowScriptAccess` to `samedomain`, which is true when the SWF is served from the site's own domain. This let any Flash post call `ExternalInterface` to run JavaScript as the viewer and hijack their account. It also allowed `navigateToURL` and unrestricted network access. Fix it by disabling script access, networking, and URL opening in the Ruffle config, and by running the player inside an `<iframe sandbox="allow-scripts" srcdoc="...">`. The sandboxed frame has an opaque origin, so even if Ruffle has a bug, a malicious Flash file can't access the user's cookies, session, or the parent page. Because the frame's origin is `null`, Ruffle's fetches for the .wasm and .swf files now count as cross-origin. For this reason, the shipped nginx for the prod image now sends `Access-Control-Allow-Origin: *` for .wasm and .swf files only. CDNs serving flash files might need to have their caches purged and/or add this header to these extensions.
ff230ca to
6ee46c2
Compare
6ee46c2 to
a1cc151
Compare
Description
Part of #25100 and #3044.
This is the first step towards more correctly implementing the
allowNetworkingsetting (Restricting networking APIs) that can be used with<object>or<embed>tags. This is mostly just some preliminary architectural work. As a proof of concept I implemented throwing in AVM2'snavigateToURL. I think next we should probably expose this to the desktop app.Afterwards of course all the APIs listed in the Adobe documentation need to be restricted.
Testing
This feature is only available when running the Flash Player inside a browser, so this isn't directly testable with something like
flashplayerdebugger. I did test this using https://hub.docker.com/r/jchprj/play-adobe-flash-after-eol.Checklist