Issue with navigateToURL()

[flash345]

Since the recent update (32.0.0.255), navigateToURL() is not working. As per the security vulnerablity description it seems there is been changes to this method. Our application uses navigateToURL() to execute javascript. The work around to set "EnableInsecureActiveXNavigateToURL=1" may not be acceptable to all as name itself suggest to enable insecure navigation. We are looking for more information on this security update, such as any replacements/secure methods which can be used? Is adobe going to fix this issue ? Is it been acknowledged as a defect? Thanks

[jeromebillet]

I can reproduce this with Flash player 32.0.0.255 32bits version for IE but not with the 64 bits version neither the peperflash 32 bits version.

Settting EnableInsecureActiveXNavigateToURL=1 in mms.cfg file is a workaround.

But I can't find any information about this parameter.

[jeromebillet]

It seem that there is an other workaround using ExternalInterface and javascript function window.open:

ExternalInterface.call("window.open", url, window);

[jeromiec83223024 · Accepted solution]

In this instance, we aligned Flash Player's behavior with what would happen in JavaScript for an equivalent request.  Flash Player pre-dates HTML5 and modern JavaScript.  As good citizens in the ecosystem, we occasionally find ourselves in a position where we need to align to particulars in JavaScript's security strategy for the health of the larger ecosystem.  This is one of those cases. 

The most likely reason that this broke your content is because the URL in the call to NavigateToURL is no longer considered as coming from the same origin as the page hosting the SWF.

The right solution is to modify your content to handle the fact that the communication is no longer automatically permitted as a same-origin request.  Depending on what you're doing and what your preferences are, your approach to that would vary (e.g. if you're navigating to a file over UNC paths to the same host that's serving the parent page over HTTPS, then you might want to load that file over HTTPS to keep it same-origin).

Because pre-announcing these kinds of changes is effectively just declaring "use it, or lose it" to attackers, we don't.  The next best approach is to gate the legacy behavior behind a flag, so that for the tiny subset of users that are affected by this kind of change, they can buy some time while they sort the issue out in their application.  The goal with these kinds of things should always be to wean yourself off as soon as possible (that's why we chose the EnableInsecure* naming), but they exist as pain-relief that your operational teams can employ while you pursue any necessary engineering or architectural changes.

[flash345]

Thank You for providing details.

What we have observed is that there is a difference in behaviour when embedding the SWF in a browser compared to WebBrowser controller (.Net Component). The same application is working when opened in a browser but not working when launched in WebBrowser. Following is a defect which is similar to what we are looking for,

https://tracker.adobe.com/#/view/FP-4199035.

Please provide your inputs on  this defect. If this is a valid defect ?

Thank You.

[nickolas999]

Thank you for the response, I have a related question to this issue. We are trying to address application behaviour that has stopped working since 32.0.0.255. So understand that it is not detecting that our calls to navigateToURL are failing as not being in the same domain. 

Is there guidance or an example of how to approach this, ie could we use the crossdomain.xml policy to flag our interactions as being allowed until we can re-architect the application?

The other option is the ExternalInterface.call() as posted by jeromebillet, however not sure if that is viable longer term.

Thanks.