Archive for November, 2009

Flash content and the same-origin policy

Peleus here. Research was recently published that makes several claims regarding Flash content on sites that allow end-user uploads that I would like to address.  The topic raised is not news; it’s something that has been understood and discussed by the security community for years. Most importantly, this is not a vulnerability in Adobe Flash Player.  Web servers that choose to accept user-uploaded content also choose to accept the risks that go along with that functionality.  Flash Player’s behavior is consistent with other web technologies and the web browser security model. Several web technologies pose the same risk to servers that allow end-user uploads.


To really understand the issue, we need to take a step back and understand the same-origin policy. This policy basically states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other.  Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact. The same-origin policy is enforced by the web browser, and all web content must follow it.
The researchers noticed that there are many web applications that allow end-users to upload their own content to the same domain as the web application itself. According to the same-origin policy, this means that the web application trusts the end-user’s content in the same way that it trusts its own content. In most real world scenarios, this is not true. The web application does not trust end-user content and does not mean to grant end-user content any privileges on its domain. Quoting Law #4 of Microsoft’s
10 Immutable Laws of Security
, “If you allow a bad guy to upload programs to your web site, it’s not your web site anymore.” Microsoft originally published these laws in 2000 and TechNet Magazine revisited them in 2008 where they concluded, “Law 4, at least in spirit, still holds–in spite of some sites that are designed to permit people, bad and good, to upload programs to them.”
When Flash content (SWF), as well as any other web content, is hosted on the same domain as the surrounding HTML, the same-origin policy defines a trust relationship between the two. Proposals have been made to have Flash content assume there is never any trust and therefore ask permission for each and every request that it makes. This would break all legitimate deployments of Flash content on the web and require all administrators to change their configurations in order to start supporting Flash again. It also would not solve the problem. Flash content is not the only content-type that can execute JavaScript when clicked on by a user. Law #4 still holds. The fundamental problem is that the site is not properly handling the upload of arbitrary active content. Attackers can still attempt to upload other forms of server-side or client-side code in an effort to exploit the server.
The web has already widely deployed much better solutions. Sites solve the problem by hosting untrusted content on a different domain. If a site developer wants to host arbitrary uploaded content on a site and does not want SWF content to execute on their site, the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content. Developers may also choose to limit uploads to only the types of content that they plan to support.  These steps to properly managing user-generated active content uploads may be challenging, but good web security requires vigilance against this type of risk alongside all the other familiar web threats like CSS, CSRF, …
We understand that developers have many challenges when managing rich content, and we are
working with the industry in discussing and supporting solutions (such as Content-Security Policies) to minimize the risks and educate the community. Our goal is to enable all of our customers (end-users, developers, and web site owners) with solutions that will protect them from the critical risks they face.

Securely deploying cross-domain policy files

Peleus here. There has been a recent focus on cross-domain policy deployments in the media, so I thought this would be a good time to remind people of some best practices.  Cross-domain security was a focus of my recent presentation at the Microsoft BlueHat conference. I have also covered this topic within my Creating More Secure SWF Web Applications article.  With more plugin platforms adopting the format and similar controls being added to HTML5, it is becoming increasingly important to ensure the correct deployment of a cross-domain architecture.  Here are five best practices that should be followed to ensure a secure deployment.


1. Avoid full wildcard permissions (domain=”*”,  headers=”*”, to-ports=”*”).  There are only a small number of legitimate use cases for full wildcard (*) permissions.  If granting full permission is absolutely necessary, then the best practice is to create a sub-domain on your site whose explicit purpose is to serve cross-domain data.  Another option is to leverage Flash Player’s support of per-directory cross-domain permissions and place the data and the full wildcard cross-domain policy within a sub-directory of the site dedicated for that purpose.  Full wildcards on internal networks can also be dangerous since they can result in external content being granted access to internal resources. A full wildcard should also never applied to the headers attribute of the allow-http-request-headers-from element or the to-ports attribute of the allow-access-from element in production.  Once a wildcard permission has been deployed, it can be very challenging to restrict permissions at a later date because there is no easy way to identify what content depends on that permission.


2. Don’t use sub-domain wildcards (* with domains that allow user-uploaded content.  This issue has grown as an increasing number of sites on the web support hosting user generated content. Quoting Microsoft’s 10 Immutable Laws of Security, “Law #4: If you allow a bad guy to upload programs to your website, it’s not your website any more.”  Therefore, if you are granting cross-domain permission to * and hosts end-user content, then you are not trusting just  You are also trusting all the users who are permitted to upload content to  An attacker can upload a malicious SWF to, use the * permission to retrieve sensitive data from your site and then pass that data back to the attacker’s web site.


3. Avoid cross-domain permissions on sites that require authentication.  Any data that requires authentication for access probably should not be available to third-party domains.  Flash Player does not provide access to the header of an HTTP response.  Therefore developers may assume that SWF content cannot gain access to the session information stored within the cookie headers.  However, some architectures will add the session information as a parameter onto the end of a URL contained within the response body where an attacker can gain access to it.  Once an attacker has access to the session information of the victim, they can impersonate that user.


4. Cross-domain policies require periodic maintenance.  Your web site will grow and change over time and you will need to reevaluate the cross-domain permissions with respect those changes.  If you are granting permissions to domains outside of your control, then keep in contact with that party to ensure that the permissions are still necessary and that they are still used within the same context.  You can limit your risk by periodically removing excess permissions.


5. Cross-domain permissions are not the only method for sharing data between domains.  Rather than using the client to bridge two domains, consider using server-side code to make the cross-domain request via a server-to-server channel.  Server-side code can enforce stricter controls on the request and act as a proxy between the client and the second domain.  This has the trade-off of increasing traffic to the server but may allow for a more controlled channel.  Be sure to consider all of your options before determining the best solution.


Cross-domain policies are a part of the code that makes up your web application.  Like any other code, they require periodic maintenance and review to ensure security.  Cross-domain policies should follow the same principle of least privilege that you apply to code. Only the minimum permissions required for the architecture should be enabled.  The best architectures are simple and straightforward. Creating a sub-domain whose explicit purpose is to host cross-domain content can prevent unintentional disclosure. Overall, approach cross-domain policies as you would any other code. Following these best practices can help you secure your cross-domain deployment.


For further information and best practice guidance, please see:

AppSec DC

Hello, my name is Kyle Randolph and I’m a Senior Security Researcher and the Technical Lead of the ASSET team. I will be attending OWASP AppSec DC this week as part of our security community outreach effects. If you are a security researcher or an Adobe customer who’s attending the conference and interested in discussing Adobe security, please shoot me an email (krand at adobe dot com). Looking forward to discussing application security with other folks in the security community this week!

Straight Talk about PDF & Digital Signatures – ISSE 2009

Jim King, PDF Architect, senior principal scientist at Adobe and one of the key drivers behind the PDF format and its adoption and continuing development by ISO as a standard (ISO 32000), recently delivered a keynote presentation to the ISSE (Information Security Solutions Europe) 2009 Conference in The Hague, Netherlands.  He discussed the evolution of the PDF format and standard, and spent most of his talk introducing the new PAdES signature standard and what it encompasses.

During that conference, Jim sat down with Roger Dean, executive director of eema UK, for a conversation about PDF, the need for digital signatures, challenges of communicating the benefits of digital signatures, and finally a description of the PAdES standard.  This interview is now available below (and here)…enjoy!