Firefox Click-to-Play Helps Protect Our Customers

The Adobe team has worked hard to improve patch adoption by delivering background updaters for Flash Player and Adobe Reader. In addition, we have worked with partners, such as Microsoft and Google, to reduce update fatigue by delivering patches through existing update mechanisms. However, one of the hardest challenges in protecting end users is reaching what is sometimes referred to as the “long tail” in an update graph. These are the users who, for various reasons, have not updated their systems in several months or even years. Reaching these last few end users can be difficult if they have disabled their update mechanisms. Unfortunately, they are also the users who are most likely to be successfully attacked.

Yesterday, Mozilla announced an update to the Firefox click-to-play feature that will warn users when they try to play plugin content with an out-of-date browser plugin. Since Mozilla will now be assisting plugin vendors in reminding these users to update, we will hopefully be able to convert more of them to patched versions. At the same time, Mozilla is helping to protect these users from those who would use older vulnerabilities to infect their systems. We support Mozilla in their efforts to protect and inform our mutual customers.

Adobe is a Sponsor for the Nation’s Largest Student Cyber Security Competition

ASSET team members Karthik Raman, Bronwen Matthews and I recently attended the NYU Poly CSAW IX Cyber Security competition  in Brooklyn, New York. The annual event first took place in 2003 and has since grown from a small, local cyber security competition to a worldwide event. This year, more than 10,000 students from high school to Ph.D level registered to compete in a total of seven CSAW challenges.

Karthik and I contributed four Web challenges to the “Capture the Flag” competition, which were designed to be similar to real-world scenarios hackers face. The challenges were related to commonly found bugs, but required the hacker to deduce the nature of the bug without much feedback from the website. The students responded with a pragmatic approach to the problems, and the competition was won by a team from Carnegie Mellon University. There was also an embedded systems challenge, a forensics challenge and an applied research competition.

Adobe sponsored the “Security Awareness” video challenge, open to high school and college students worldwide. The contest challenged students to develop a consumer-friendly educational video on an important security topic with the theme: “Securing Every Device, Everywhere.” Adobe provided access to the free version of Adobe Creative Cloud for all participants, enabling them to use our latest video production tools. Guest judges from the security teams at Adobe, Microsoft, VMWare, Facebook, and the NSA selected the final winners. The first place winner of the challenge this year was Ethan Bain of the Illinois Mathematics and Science Academy in Aurora, Illinois. You can watch his winning video here.

The first day of the event focused on mobile security, with presentations from Dan Guido, Vincenzo Iozzo and Dino Dai Zovi from Trail of Bits, as well as Mike Arpaia.  Other presenters included:  Collin Mulliner of Northeastern University, Jon Oberheide of DUO Security, and Chris Rohlf of LeafSR.

Ryan Naraine from Kaspersky Lab moderated an interesting panel discussion entitled: “If a Cybercriminal is Determined to Hack You, Can You Do Anything About it?” Panelists included representatives from Kaspersky, Harvard University IT and NYU Poly.

The high school students competed in a challenging, live security quiz, sponsored by DHS. (We played along in the audience. Let’s just say we got most of the answers right.)

It was a fun couple of days. We met some excellent students doing interesting and important work in security. It is reassuring to know that the next wave of security researchers coming out of some of our high schools and colleges are way ahead of the game in cyber security.

Rajat Shah
Security Researcher
Adobe Secure Software Engineering Team (ASSET)

BSIMM Community Conference 2012

Last week, ASSET team members Jim Hong, Josh Kebbel-Wyen and I attended the BSIMM Community Conference 2012, which took place in Galloway, NJ. This year, despite hurricane Sandy, the conference had about 90 attendees representing 30 organizations.

The Building Security In Maturity Model (BSIMM) is a data-driven descriptive model of existing security initiatives across various companies. Adobe was one of the nine original participants in measurements for the first version of BSIMM and has participated in subsequent BSIMM surveys.

This year, participants such as Intel, Symantec and JP Morgan Chase held talks during the conference, covering topics such as strategy, architecture analysis, training and penetration testing, with each talk describing how the organizations had customized the best practice in their particular environment.

In addition to the talks, there were three parallel workshops on Security Fraud, Third Party Security Controls and Agile Methods in SSDLs. These workshops provided discussion on the nuances of security and how each organization deals with the challenges associated with them.

The talks and workshop were informative but of equal or maybe even greater value, was the opportunity to network and compare notes on security initiatives and best practices with peers from across participating organizations. The benefit from this kind of interaction is immense.

Mohit Kalra
Senior Manager Secure Software Engineering

 

New Security Capabilities in Adobe Reader and Acrobat XI Now Available!

This week, Adobe released the next generation of Adobe Reader XI and Acrobat XI with improved security features, among many other enhancements.

Adobe Reader X represented a milestone release in terms of security with the introduction of Adobe Reader Protected Mode (aka “sandboxing”), which created a more secure environment for our customers. We followed the Adobe Reader X release with the introduction of Adobe Acrobat X (10.1) Protected View. Since we added sandbox protection to Adobe Reader and Acrobat, we have not seen any exploits in the wild that break out of the Adobe Reader and Acrobat X sandbox.

Over the last year, we have continued to work on adding security capabilities to Adobe Reader and Acrobat, and today, we are very excited to present Adobe Reader and Acrobat XI with a number of new or enhanced security features.

Adobe Reader XI Protected Mode (Enhanced)

In our Adobe Reader X sandbox implementation, the sandboxing architecture’s primary focus was on “write protection” to prevent the attacker from installing malware on the user’s machine and from monitoring the user’s keystrokes when the user interacts with another program.

In Adobe Reader XI, we have added data theft prevention capabilities by extending the sandbox to restrict read-only activities to help protect against attackers seeking to read sensitive information on the user’s computer.

Adobe Reader Protected View (New) and Adobe Acrobat Protected View (Enhanced)

To provide an additional layer of defense and strengthen the sandbox protection in Adobe Reader and Acrobat even further, we have implemented a separate desktop and WinStation in Adobe Reader and Acrobat XI, which will block, for instance, screen scraping attacks. For additional insights into implementing a separate desktop to provide an additional layer of defense, see David LeBlanc’s Web log entry Practical Windows Sandboxing – Part 3. For details on WinStations and desktops in general, click here.

This mode effectively introduces a new Protected View in Adobe Reader and enhances the Protected View implementation in Adobe Acrobat even further. Protected View behaves identically for Adobe Reader and Acrobat, whether viewing PDF files in the standalone product or in the browser. For more information, administrators can refer to the Enterprise Toolkit for Acrobat Users.

Force ASLR Support in Adobe Reader/Acrobat XI

Adobe Reader and Acrobat leverage platform mitigations such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), etc. In Adobe Reader and Acrobat XI, we have enabled support for Force ASLR on Windows 7 and Windows 8. Force ASLR improves the effectiveness of existing ASLR implementations by ensuring that all DLLs loaded by Adobe Reader or Acrobat XI, including legacy DLLs without ASLR enabled, are randomized. By enabling Force ASLR in Adobe Reader and Acrobat XI, we are making it even more difficult for an attacker to exploit vulnerabilities. For more information on ASLR and Force ASLR, please refer to Microsoft’s Knowledge Base article on the topic.

PDF Whitelisting Framework

For high-assurance, managed enterprise environments, we’ve added the Adobe PDF Whitelisting Framework, which allows administrators to selectively enable advanced functionality, such as JavaScript for specific PDF files, sites or hosts, on both Windows and Mac OS.

Support for Elliptic Curve Cryptography

And last but not least, we have added support for Elliptic Curve Cryptography (ECC) for digital signatures in the area of content security. Users can now embed long-term validation information automatically when using certificate signatures and use certificate signatures that support elliptic curve cryptography (ECC)-based credentials.

We’re excited about these additional security capabilities in Adobe Reader and Acrobat XI, which mark the latest in our continued endeavor to help protect our customers by providing a safer working environment.

Priyank Choudhury
Security Researcher, Adobe Secure Software Engineering Team (ASSET)

Inappropriate Use of Adobe Code Signing Certificate

We recently received two malicious utilities that appeared to be digitally signed using a valid Adobe code signing certificate. The discovery of these utilities was isolated to a single source. As soon as we verified the signatures, we immediately decommissioned the existing Adobe code signing infrastructure and initiated a forensics investigation to determine how these signatures were created. We have identified a compromised build server with access to the Adobe code signing infrastructure. We are proceeding with plans to revoke the certificate and publish updates for existing Adobe software signed using the impacted certificate. This only affects the Adobe software signed with the impacted certificate that runs on the Windows platform and three Adobe AIR applications* that run on both Windows and Macintosh. The revocation does not impact any other Adobe software for Macintosh or other platforms.

Sophisticated threat actors use malicious utilities like the signed samples during highly targeted attacks for privilege escalation and lateral movement within an environment following an initial machine compromise. As a result, we believe the vast majority of users are not at risk.  We have shared the samples via the Microsoft Active Protection Program (MAPP) so that security vendors can detect and block the malicious utilities.

Customers should not notice anything out of the ordinary during the certificate revocation process.  Details about what to expect and a utility to help determine what steps, if any, a user can take are available on the support page on Adobe.com.

Sample Details

The first malicious utility we received is pwdump7 v7.1.  This utility extracts password hashes from the Windows OS and is sometimes used as a single file that statically links the OpenSSL library libeay32.dll.  The sample we received included two separate and individually signed files. We believe the second malicious utility, myGeeksmail.dll, is a malicious ISAPI filter. Unlike the first utility, we are not aware of any publicly available versions of this ISAPI filter. More details describing the impacted certificate and the malicious utilities, including MD5 hash values for the files, are included in the Adobe security advisory.

In addition to working with your security vendors to ensure you have the latest updates containing protections against these utilities, system administrators for managed desktop Windows OS environments can create a Software Restriction Policy (SRP—via Group Policy) that disallows the execution of the malicious utilities and blocks them on the basis of the individual file hashes.

Our internal testing indicates that moving the impacted Adobe certificate to the Windows Untrusted Certificate Store does not block threat actors from executing the malicious utilities on a victim machine. However, this configuration does have a negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.

Adobe Code Signing Infrastructure

The private keys associated with the Adobe code signing certificates were stored in Hardware Security Modules (HSMs) kept in physically secure facilities. All entities authorized to request digital signatures were provisioned according to an established procedure that verified the identity of the entity and verified that the release engineering environment met the relevant assurance criteria. All code signing requests were submitted via mutually authenticated Transport Layer Security (TLS) connections to the code signing service and were performed only if the requesting entity came from the originally provisioned IP address.

Within minutes of the initial triage of the first sample, we decommissioned our signing infrastructure and began a clean-room implementation of an interim signing service for re-signing components that were signed with the impacted key after July 10, 2012 and to continue code signing for regularly scheduled releases. The interim signing solution includes an offline human verification to ensure that all files scheduled for signature are valid Adobe software. We are in the process of designing and deploying a new, permanent signing solution.

Compromised Build Server

We have identified a compromised build server that required access to the code signing service as part of the build process. Although the details of the machine’s configuration were not to Adobe corporate standards for a build server, this was not caught during the normal provisioning process. We are investigating why our code signing access provisioning process in this case failed to identify these deficiencies. The compromised build server did not have rights to any public key infrastructure (PKI) functions other than the ability to make code signing requests to the code signing service.

Our forensic investigation is ongoing. To date we have identified malware on the build server and the likely mechanism used to first gain access to the build server. We also have forensic evidence linking the build server to the signing of the malicious utilities. We can confirm that the private key required for generating valid digital signatures was not extracted from the HSM. We believe the threat actors established a foothold on a different Adobe machine and then leveraged standard advanced persistent threat (APT) tactics to gain access to the build server and request signatures for the malicious utilities from the code signing service via the standard protocol used for valid Adobe software.

The build server used a dedicated account to access source code required for the build. This account had access to only one product. The build server had no access to Adobe source code for any other products and specifically did not have access to any of Adobe’s ubiquitous desktop runtimes such as Flash Player, Adobe Reader, Shockwave Player, or Adobe AIR. We have reviewed every commit made to the source repository the machine did have access to and confirmed that no source code changes or code insertions were made by the build server account. There is no evidence to date that any source code was stolen.

Next Steps

The revocation of the impacted certificate for all code signed after July 10, 2012 is planned for 1:15 pm PDT (GMT -7:00) on Thursday October 4, 2012. To determine what this means for current installations and what corrective steps (if any) are necessary, please refer to the support page on Adobe.com. The certificate revocation itself will be included in the certificate revocation list (CRL) published by VeriSign; no end user or administrator action is required to receive the updated CRL.

Through this process we learned a great deal about current issues with code signing and the impact of the inappropriate use of a code signing certificate. We plan to share our lessons learned as well as foster a conversation within the industry about the best way to protect users and minimize the impact on users in cases where the revocation of a certificate becomes necessary (as in this example). Please stay tuned for more details in the coming weeks.

* Adobe Muse and Adobe Story AIR applications as well as Acrobat.com desktop services

Collaboration for Better Software Security

At Adobe we have found that building working relationships between developers and vulnerability researchers is to the benefit of everyone–including, and especially, the general public. We will be speaking this week on this topic at the SOURCE Seattle 2012 conference. In our talk we’ll share case studies of successful developer-researcher collaboration by examining examples of security incidents including bug reports, zero-day attacks, and incident response.

If you’re going to be at SOURCE Seattle please drop by our talk: “Why Developers and Vulnerability Researchers Should Collaborate” at 12:10pm on Thursday, September 13. We’re eager to share what we have learned from our developer-researcher collaboration. And, of course, we especially look forward to catching up in hallway conversations!

Cheers,

Karthik Raman, Security Researcher, ASSET
David Rees, Lead Developer, Acrobat 3D

Adobe’s Support of “International Technology Upgrade Week”

Earlier today, Skype together with Norton by Symantec and TomTom kicked off “International Technology Upgrade Week,” a global initiative to encourage consumers to regularly download and install software updates. Keeping software up-to-date is probably the single-most important advice we can give to users—consumers and businesses alike. For details on this consumer-focused update initiative, we invite you to read the Adobe Reader blog post supporting this very important update initiative.

Join Skype, Norton by Symantec, TomTom and Adobe this week, and take the time to make sure your software is—and stays—up-to-date. For consumers outside of managed environments, choose automatic updates, if your software offers this option; or if it doesn’t, install updates when you first receive the update notification.

Inside Flash Player Protected Mode for Firefox

Today, we launched Flash Player Protected Mode for Firefox on Windows. Our Protected Mode implementation allows Flash Player to run as a low integrity process with several additional restrictions that prohibit the runtime from accessing sensitive resources. This approach is based on David LeBlanc’s Practical Windows Sandbox design and builds upon what Adobe created for the Adobe Reader X sandbox. By running the Flash Player as a restricted process, Adobe is making it more difficult for an attacker to turn a simple bug into a working exploit. This blog post will provide an overview of the technical implementation of the design.

When you first navigate to a page with Flash (SWF) content, you will notice that there are now three processes for Flash Player. This may seem odd at first, but there is a good reason for this approach. One of the goals for the design was to minimize the number of changes that were necessary in Firefox to support the sandbox. By keeping Flash Player and Firefox loosely coupled, both organizations can make changes to their respective code without the complexity of coordinating releases.

The first process under the Firefox instance is called “plugin-container.exe.” Firefox has run plugins in this separate process for quite some time, and we did not want to re-architect that implementation. With this design, the plugin container itself is only a thin shim that allows us to proxy NPAPI requests to the browser. We also use this process as our launching point for creating the broker process. Forking the broker as a separate process allows us to be independent of the browser and gives us the freedom to restrict the broker process in the future. From the broker process, we will launch the fully sandboxed process. The sandboxed process has significant restrictions applied to it. It is within the sandbox process that the Flash Player engine consumes and renders Web content.

The restrictions we apply to this sandboxed process come from the Windows OS. Windows Vista and Windows 7 provide the tools necessary to properly sandbox a process. For the Adobe Reader and Acrobat sandbox implementation introduced in 2010, Adobe spent significant engineering effort trying to approximate those same controls on Windows XP. Today, with Windows 8 just around the corner and Windows XP usage rapidly decreasing, it did not make sense for the Flash Player team to make that same engineering investment for Windows XP. Therefore, we’ve focused on making Protected Mode for Firefox available on Windows Vista and later.

For those operating systems, we take advantage of three major classes of controls:

The first control is that we run the sandboxed process at low integrity. By default, processes started by the user are executed at medium integrity. Running the process at a low integrity level prevents the process from writing to most areas of the user’s local profile and the registry which require a medium integrity level to access. This also allows us to take advantage of User Interface Privilege Isolation (UIPI) which prevents low integrity processes from sending windows messages to higher integrity processes.

The second class of controls applied to the sandboxed process is to restrict the capabilities of the access token. A process will inherit a list of available Security Identifiers (SIDs) from the user’s security profile. These SIDs represent the different OS groups to which the user belongs. The access token contains this list of SIDs along with a set of controls for those SIDs. The Windows OS will compare the SIDs in the access tokens to the group permissions of the target object (e.g a file) to determine if access is allowed. The Windows OS allows us to define how the process SIDs are used in that comparison.

In general, a sandboxed process will need to be able to access resources directly owned by the user. However, in most cases it is unlikely that the sandbox will need the extended set of resources available to the user via group permissions. As a concrete example, your company may have a contact list on a network share that is available to everyone within your “Employees” group. It isn’t your file but you can access it because you are in the “Employees” group for your company. The Flash Player sandbox process doesn’t need to be able to directly access that file.

We identified that our sandbox process will need to access OS resources using the following SIDs: BUILTIN\Users, Everyone, the User’s Logon SID, and NTAUTHORITY\INTERACTIVE. For any other SIDs that are inherited from the user, we set the deny-only attribute to prohibit the process from accessing the resource based solely on that SID. To continue the example of the contact list on the file share, the sandboxed process would not be able to access the contact list because the file is not owned by you and the deny-only attribute on the “Employees” group SID would prevent access using your group permission. Process privileges are also limited to only the SeChangeNotifyPrivilege, which is required for the process to be notified of file system changes and for certain APIs to work correctly. The graphic below shows the permissions applied to the sandboxed process.

The third control applied to the sandboxed process are job restrictions. As one example, we can prevent the sandboxed process from launching other processes by setting Active Processes to 1. We can also limit the sandbox’s ability to communicate with other processes by restricting access to USER Handles and Administrator Access. The USER Handles restriction complements UIPI by preventing the process from accessing user handles created by processes not associated with our job. Finally, we can limit the sandboxes ability to interfere with the OS by limiting access to System Parameters, Display Settings, Exit Windows and Desktop.

More information on job limits, privilege restrictions and UIPI can be found in Part 2 of Inside Adobe Reader Protected Mode.

Once you get past OS-provided controls, the next layer of defense is Flash Player broker controls.

The OS broker process runs at medium integrity and acts as a gatekeeper between the untrusted sandbox process and the operating system. The sandbox process must ask the OS broker process for access to sensitive resources that it may legitimately need. Some examples of resources that are managed by the broker include file system access, camera access, print access and clipboard access. For each resource request, the sandbox contains policies which define what can and cannot be accessed. For instance, the sandbox process can request file system access through the broker. However, the policy within the broker will limit access to the file system so that the sandbox can only write to a predetermined, specific set of file system paths. This prevents the sandbox from writing to arbitrary locations on the file system. As another example, the sandbox cannot launch applications directly. If Flash Player needs to launch the native control panel, the Flash Player engine must forward the request to the broker process. The broker will then handle the details of safely launching the native control panel. Access to other OS resources such as the camera are similarly controlled by the broker. This architecture ensures that the sandboxed process cannot directly access most parts of the operating system without that access first being verified by the broker.

Overall, the Flash Player sandbox process has been a journey of incremental improvements with each step bringing end-users a more secure environment. We started by supporting Protected Mode within Internet Explorer, which enabled Flash Player to run as a low integrity process with limited write capabilities. From there, we worked with Google on building the Chrome sandbox, which converted Flash Player to using a more robust broker implementation. This release of Flash Player Protected Mode for Firefox on Windows takes the Chrome implementation one step further by changing Flash Player to run with job limits on the process. With Flash Player Protected Mode being based on the same technology as Adobe Reader X, we are confident that this implementation will be a significant barrier and help prevent exploits via Flash Player for Firefox users. Going forward, we plan to continue to build on this infrastructure with more sandbox projects, such as our upcoming release of Flash Player for Chrome Pepper. As we combine these efforts with other efforts, such as the background updater, we are making it increasingly more difficult for Flash Player to be targeted for malicious purposes.

Peleus Uhley, Platform Security Strategist, ASSET
Rajesh Gwalani, Security Engineering Manager, Flash Runtime

Flash Player 11.3 delivers additional security capabilities for Mac and Firefox users

Today’s release of Flash Player 11.3 brings three important security improvements:

  • Flash Player Protected Mode (“sandboxing”) is now available for Firefox users on Windows.
  • For Mac users, this release will include the background updater for Mac OS X.
  • This release and all future Flash Player releases for Mac OS X will be signed with an Apple Developer ID, so that Flash Player can work with the new Gatekeeper technology for Mac OS X Mountain Lion (10.8).

Flash Player 11.3 brings the first production release of Flash Player Protected Mode for Firefox on Windows, which we first announced in February. This sandboxing technology is based on the same approach that is used within the Adobe Reader X Protected Mode sandbox. Flash Player Protected Mode for Firefox is another step in our efforts to raise the cost for attackers seeking to leverage a Flash Player bug in a working exploit that harms end-users. This approach has been very successful in protecting Adobe Reader X users, and we hope Flash Player Protected Mode will provide the same level of protection for Firefox users. For those interested in a more technical description of the sandbox, please see the blog post titled Inside Flash Player Protected Mode for Firefox authored by ASSET and the Flash Player team.

The background updater being delivered for Mac OS X uses the same design as the Flash Player updater on Windows. If the user chooses to accept background updates, then the Mac Launch Daemon will launch the background updater every hour to check for updates until it receives a response from the Adobe server. If the server responds that no update is available, the system will begin checking again 24 hours later. If a background update is available, the background updater can download and install the update without interrupting the end-user’s session with a prompt.

With Mac OS X Mountain Lion (10.8), Apple introduced a feature called “Gatekeeper,” which can help end-users distinguish trusted applications from potentially dangerous applications. Gatekeeper checks a developer’s unique Apple Developer ID to verify that an application is not known malware and that it hasn’t been tampered with. Starting with Flash Player 11.3, Adobe has started signing releases for Mac OS X using an Apple Developer ID certificate. Therefore, if the Gatekeeper setting is set to “Mac App Store and identified developers,” end-users will be able to install Flash Player without being blocked by Gatekeeper. If Gatekeeper blocks the installation of Flash Player with this setting, the end-user may have been subject to a phishing attack. That said, a reminder that Flash Player should only be downloaded from the www.adobe.com website.

ColdFusion 10 Provides Powerful New Security Tools

Today marks the release of ColdFusion 10. This release redefines many aspects of the ColdFusion 10 security model and incorporates the principles of the Adobe Secure Product Lifecycle (SPLC). With this release, we’ve worked to improve three major areas: Our goals were to improve patch adoption, improve the default configuration, and to make it easier for developers to create secure ColdFusion applications.

One of the most common reasons for a successful attack against a ColdFusion server is that it doesn’t have the latest security updates. In all fairness, this is not completely the administrator’s fault. Updating a ColdFusion server can be difficult due to the number of manual steps involved. Also, it is easy to miss a security update announcement. With ColdFusion 10, we make both of these steps easier. The ColdFusion 10 administration interface now incorporates a simple “Check For Updates” button. Alternatively, the server can be configured to automatically check for updates and send an email to the administrator once one becomes available.  Finally, the interface allows the developer to apply the patch through a single button click in the administrator interface. These features help make updating the server much more straightforward.

The second major area of improvement focused on making it easier for administrators to securely deploy ColdFusion 10. One of the most attractive characteristics of ColdFusion is that it has always been a simple development environment. Therefore, there were several features that favored making the early phases of development easier by leaving the complicated aspects disabled by default. The cost of this choice was that once developers were ready to deploy to production, they had to review a 35-page lockdown guide to enable and/or configure those more complicated features appropriately. With today’s release, we offer the option of starting the server in a secure-by-default configuration. This greatly simplifies the process of making a server production-ready with a secure configuration.

The last area of improvement focused on providing developers with an increased number of tools for creating secure ColdFusion applications. One example is that we have provided integrated OWASP ESAPI support in the platform. We originally started to include ESAPI in ColdFusion 9 just for our internal needs of addressing cross-site scripting (XSS). Once developers noticed the library in the update, they quickly developed several blogs on how to unofficially start using it in your ColdFusion code. Today’s release formally exposes several aspects of ESAPI through ColdFusion API’s to help developers avoid cross-site scripting vulnerabilities.

We also improved the session management capabilities in ColdFusion–another aspect of making it easier for developers to create ColdFusion applications. We have improved APIs to make it easier to set the HttpOnly and Secure flags on cookies. Session rotation has been improved through new SessionRotate and SessionInvalidate APIs.  To combat cross-site request forgery (CSRF) with active sessions, the ColdFusion team added an API for generating unique tokens for form requests. The team also added support for protecting against clickjacking attacks on active users by adding support for the X-FRAME-OPTIONS header.

ColdFusion 10 is a significant advancement in helping ColdFusion customers improve their secure product lifecycle processes. It is even easier to create secure content, deploy the content on a secure server and manage the server updates once it is deployed. This is only an introduction to the major security enhancements in ColdFusion 10. For more information on all the new security APIs for developers, please see the ColdFusion documentation on Security Enhancements in ColdFusion 10.  ColdFusion administrators should review the Administering Security and the Server Update sections for a complete list of server improvements.