NavigateToURL and custom header change

Question

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 [email protected].
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.ht ml
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/

Answer 1

Our security model does not allow a movie to send HTTP headers across domains, unless the player has confirmed the receiving domain permits it with a cross domain policy file ( see Adobe ActionScript 3.0 * Website controls (policy files) ).
With navigateToUrl() we are unable to detect server-side redirects, so we are unable to confirm the actual recipient permits HTTP headers.  To resolve this, we elected to block HTTP headers from all navigateToUrl requests.
As noted by several customers, this has proved to be overly restrictive, so we are going to relax the restriction to allow simple headers with navigateToUrl requests.
Simple headers are defined by Cross-Origin Resource Sharing as
A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, ortext/plain.
In an upcoming Flash Player build, navigateToUrl() will be changed to throw the exception only when called with an URLRequest containing non-simple headers.  We're shooting to get this change in for our July release but this will of course depend on our testing results.  We'll be getting this into a public beta as soon as possible (possibly as soon as the next week or two.)