Skip to main content
chris.campbell
Community Manager
Community Manager
May 20, 2014
Question

navigateToURL and custom header change

  • May 20, 2014
  • 2 replies
  • 15399 views

First, we apologize for the inconvenience the change to navigateToURL has caused you and your customers.  We typically do everything possible to keep existing content working but in this case we had no choice to make these changes given the security implications.

This change was necessary to fix a security vulnerability (CVE-2014-0516) related to Flash Player’s handling of custom request headers that could be abused to violate the cross domain security policy (reference http://helpx.adobe.com/security/products/flash-player/apsb14-14.html). Successful exploitation of CVE-2014-0516 could result in sensitive information disclosure.

We have a few suggested high level workarounds below.  In addition, we’d love to hear solutions from the community and if possible work with one or two developers to iterate on our suggestions and improve these workarounds for future documentation.  If you are interested in helping, please feel free to reach out to me at ccampbel@adobe.com.

ExternalInterface

We have blocked custom headers from navigateToUrl() when the URLRequest is a POST.

ActionScript could replace the use of navigateToUrl(url:URLRequest, name:String) with ExternalInterface.call(“jsNavigateToUrl”, url:String, name:String, headers:Array).

And the HTML could implement the javascript function jsNavigateToUrl(url, name, headers) which uses window.open() to request the new window from JavaScript instead of ActionScript.

NOTE: window.open() does not allow you to POST, but you can work around that using the stack overflow article window-open and pass parameters by post method.

Form Data or Url Parameters

The custom headers (that the player is now blocking) could be sent as form data, or url parameters.

The server could be recoded to accept this alternate delivery of the data.

If this isn’t an option (for instance, you are posting to a third party server), then your server can introduce a new url which processes the data in its new form before redirecting to the original url with the data delivered in its original form.

This mod_rewrite + mod_headers example explains something similar:

http://www.kahunaburger.com/2012/05/18/mod_rewrite-and-mod_headers-to-rewrite-headers/

In addition to Apache's mod_rewrite and mod_headers, HeliconTech makes mod_headers and mod_rewrite filters for IIS.

References:

http://helpx.adobe.com/security/products/flash-player/apsb14-14.html

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLRequest.html

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/package.html#navigateToURL()

http://stackoverflow.com/questions/3951768/window-open-and-pass-parameters-by-post-method

http://www.kahunaburger.com/2012/05/18/mod_rewrite-and-mod_headers-to-rewrite-headers/

This topic has been closed for replies.

2 replies

Participating Frequently
May 23, 2014

Chris,

Thank you for the writeup and explanations. Have you considered these solutions

  • instead of disallowing all headers, let the 'simple' headers through. This is the solution taken by Chrome/pepperflash with regard to navigateToURL cross domain issues. Please refer to W3C cross-origin sharing recommendation: http://www.w3.org/TR/cors/#simple-header
  • leverage crossdomain.xml/allow-http-request-headers so that full header are allowed for certain sites - in a controlled manner
chris.campbell
Community Manager
Community Manager
May 23, 2014

Hi Jean,

This is something we're considering.  However, it's not something we'll be able to implement quickly.  Given that, would this still be worthwhile to you if it were to be implemented in our July or August releases?  Again, not committing to this but it would be great to know if you need a fix now, or if it could wait for proper security reviews and testing.

Thanks,

Chris

Participating Frequently
May 27, 2014

Chris,

We are using a workaround for now. What is at stake is our confidence in the future of the Flash platform. Again, I would like to see your comment on the solution taken by pepperflash and the CORS recommendation on simple HTTP headers.

Have you been a bit heavy-handed perhaps ?

chris.campbell
Community Manager
Community Manager
May 22, 2014

I also would also like to recommend teams test against our public betas that we make available through labs.adobe.com.  These are typically updated once a week and can be found here:

Adobe Flash Player Beta

Adobe AIR Beta

Adobe Employee
May 22, 2014

Yes, we really want teams to test with our public betas. Flushing out issues prior to shipping is better for all of us.