navigateToURL and custom header change

[chris.campbell]

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#navigateTo...()

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/

[chris.campbell]

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

[robertg32907211]

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

[JeanBonnot]

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]

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

[JeanBonnot]

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 ?

[loppsylu]

Jean,

Can you provide the workaround you did? Interested to see how you did it.

Jeff

[dolldivine]

Chris, I had posted essentially the same thing as Jean on the bug report form.

For me, I have already placed a giant "Sorry but nothing's working" error for logged in users, issued a bunch of refunds, and have begun brainstorming sessions with users on how to completely change my website's business model.  I think at this point I'd rather Adobe not go back or I'll have a panick attack.  Reading this I'm already starting one =(

Now I REALLY don't know what to do.. Start hiring a web developer for a completely different website... Hold off for this to get changed... Issue refunds.. Not issue refunds...  What should I ask users to do?

[chris.campbell]

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.)