The next version of Adobe Flash Player will offer a variety of new features and enhancements as well as some changes to the current behavior of Flash Player. Some of these changes may require existing content to be updated to comply with stricter security rules. Other changes introduce new abilities that were previously unavailable or restricted by security rules.
Please review the following security-related changes being made to Flash Player 10 beta. Use this list to determine whether you will need to make changes to your existing content for it to function correctly in the next Flash Player release. Changes that may require action * Policy <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head1> file strictness: Phase 2 * Socket <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head2> connection timeout * Upload <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head3> and download require user interaction New security-related features that are available * Local <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head4> save and load * Limited <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head5> full-screen keyboard input * Peer-to-peer <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes .html#head6> communication via RTMFP Policy file strictness: Phase 2 Adobe tightened the rules regarding Flash Player and cross-domain policy files starting with Flash Player 9,0,115,0. Due to the impact of these changes and how they would affect many existing websites, the changes took place over a series of three phases in multiple releases of Flash Player. Flash Player 9,0,115,0 implemented Phase 1. Following that, Flash Player 9,0,124,0 continued with Phase 1.5: strict rules for sockets only. Flash Player 10 will complete Phase 2 including cross-domain policy file changes for all other non-socket content (HTTP/HTTPS/FTP). The completion of Phase 2 changes the default behavior of the meta-policy for policy files. A meta-policy is a policy that dictates the behavior of policy files on a domain, enablng an administrator to exercise greater control over all policy files being used with that domain. The concept of meta-policies was introduced in Phase 1 with Flash Player 9,0,115,0. For that version of the player, the meta-policy used a default value of "all," which allowed all policy files on a domain to remain valid; this allowed the behavior to remain consistent with previous versions of the player. With Phase 2 in Flash Player 10 beta, the meta-policy default will change from "all" to "master-only." This will allow all master policy files (any policy file saved in the root of the domain with the name crossdomain.xml, such as http://example.com/crossdomain.xml) to continue to function as expected. However, all other policy files defined in alternate locations will require an explicit meta-policy for them to work. What is impacted? This change can potentially affect any SWF file accessing cross-domain content. This change affects SWF files of all versions played in Flash Player 10 beta and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected). What do I need to do? Read the article, Policy <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html> file changes in Flash Player 9. If you have not already, define a meta-policy for your domain. Even if you are only using a master policy file, it is recommended you still explicitly define a meta-policy. Meta-policies can be set in the master policy file within a site-control directive, or through headers sent by the server. If you depend on content from a domain outside of your control, you should contact that domain's administrator and make sure they have a meta-policy that is up to date. Socket connection timeout For ActionScript Socket and XMLSocket objects, all securityError events will be sent after a predetermined amount of time has elapsed since the call to connect(). This means that previously immediate securityError events will take longer to be dispatched, and also that connections that might earlier have succeeded after a long delay (for example, because of network congestion or outages) will instead result in a securityError event. The predetermined timeout is 20 seconds by default but can be specified by ActionScript developers using the new Socket.timeout and XMLSocket.timeout APIs. What is impacted? This change can potentially affect any SWF file that uses the Socket or XMLSocket classes. This change affects SWF files of all versions played in Flash Player 10 beta and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected). What do I need to do? Developers should be sure to account for the new error by listening for the SecurityErrorEvent.SECURITY_ERROR event from Socket and XMLSocket objects in their code. An explicit timeout may also be set. Longer timeouts favor greater robustness under marginal network conditions at the expense of longer delays in discovering failures. Shorter timeouts favor quicker discovery of failures at the expense of reduced robustness under marginal network conditions. Upload and download require user interaction In Flash Player 9, ActionScript could perform uploads and downloads at any time. With Flash Player 10 beta, the FileReference.browse and FileReference. download operations may be initiated only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or pressing the keyboard. What is impacted? This change can potentially affect any SWF file that makes use of Filereference.browse or FileReference.download. This change affects SWF files of all versions played in Flash Player 10 beta and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected). What do I need to do? Any existing content that invokes a browse dialog box using Filereference.browse or FileReference.download outside of an event triggered by user interaction will need to be updated. The dialog box will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user. Local save and load Flash Player developers will be able to allow users to save and load data from a playing SWF file to and from the user's hard drive using standard operating system browse dialog boxes. Previous implementations of this process required a server to manage the transfer of data from Flash Player to a user's computer. This will now be completely handled on the client side by Flash Player. What is impacted? This is a new feature for Flash Player 10 beta. Existing content will not be affected, but new content may be created for Flash Player 10 beta that makes use of this enhancement. What do I need to do? If you would like to make use of this feature, you will need to publish content for Flash Player 10 beta. Note: AIR developers already have access to File APIs which provide this functionality in Flash Player 9 content running inside an AIR application. Limited full-screen keyboard input Currently Flash Player does not allow keyboard input when displaying content in full-screen mode. Flash Player 10 beta will change this, allowing for a limited number of keys to be usable in full-screen mode. These include Tab, the Spacebar, and the (up, down, left, right) arrow keys. What is impacted? This change affects all SWF files played in Flash Player 10 beta or later. This includes SWF files published for earlier versions of Flash, so long as they are played within Flash Player 10 beta. This also affects non-app content in AIR. What do I need to do? It is likely that this change will not affect any existing content. However, you now have the opportunity to modify your content to make use of the new keyboard support to allow additional user interaction in full-screen mode. Note: App content in AIR can set the value of stage.displayState to StageDisplayState.FULL_SCREEN_INTERACTIVE for full keyboard support in full-screen mode. New network protocol: RTMFP RTMFP provides a UDP-based secure network transport alternative to RTMP between Flash Player and Flash Media Server. RTMFP also adds basic peer-to-peer capabilities that enable Flash Player instances to publish and play audio and video directly without relaying the media through an intermediate server. Flash Media Server is still required initially to establish these direct connections. What is impacted? This is a new feature for Flash Player 10 beta. Existing content will not be affected, but new content may be created for Flash Player 10 beta to make use of this enhancement. What do I have to do? If you would like to make use of this feature, you will need to publish content for Flash Player 10 beta that communicates with Flash Media Server supporting the RTMFP protocol. If you are the administrator of a network where this new feature will be used, you should become familiar with the security features of RTMFP, the direct peer-to-peer communication capabilities, and how it makes use of UDP, which may require changes to your network firewall configuration. Where to go from here For an overview of the changes coming in the next release of Flash Player, read Introducing <http://www.adobe.com/devnet/logged_in/jchurch_flashplayer10.html> Flash Player 10 beta. For a practical guide to what you need to know to work with the required changes that have been made to policy files in the upcoming version Flash Player, read Working <http://www.adobe.com/devnet/flashplayer/articles/fplayer9-10_security.html> with policy file changes in Flash Player 9 and Flash Player 10 beta. You should download the prerelease <http://www.adobe.com/go/DLFXP> version of Flash Player 10 beta from Adobe Labs. About the author Trevor McCauley is a quality engineer at Adobe Systems who works heavily with Flash and Fireworks. Prior to working at Adobe, he worked as a developer for a production company creating various kinds of multimedia and web-based content. In his free time, Trevor develops Flash and Fireworks content for his personal site, senocular.com <http://www.senocular.com/> , and moderates forums on popular Flash-related sites such as Kirupa.com <http://www.kirupa.com/> , ActionScript.org <http://www.actionScript.org> , FlashKit.com <http://www.flashkit.com/> , and UltraShock.com <http://www.ultrashock.com/> . [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
