Pete FreitagColdFusion 10 Security Enhancements Presentation
June 07, 2012
I've given a couple presentations now on the security enhancements in ColdFusion 10. The most recent was today at the Adobe ColdFusion Developer 2012, but I've also given it two other times for a Carahsoft webinar, and for the Carahsoft ColdFusion 10 Preview event in Washington DC. The slide deck was very similar for all three, but today's slides are the most up to date.
I hope you find it useful, there really are quite a few security enhancements in ColdFusion 10, so many that it's difficult to cover all of them in an hour!
Here's a short list of some of the enhancements (not even including all of them):
- Secure Profile in installation
- Weak password warnings in installation
- Hotfix Installer
- CF Admin IP restrictions
- Tomcat - lots of security folks review tomcat, JRun... not so much
- Session Cookie settings
- New SessionRotate() and SessionInvalidate() functions
- CFFile Upload accept allows file extensions, strict mode now checks file content mime type, not just the mime type the browser sends (though this can still be spoofed).
- Hash iterations
- HMAC Function
- CSRF Token Functions
- Ram disk application isolation
- And several more!
Like this? Follow me ↯
Tweet Follow @pfreitagYou might also like:
- ColdFusion 2020 Developer Week - Securing CF - May 22, 2020
- CFSummit 2016 Slides - October 17, 2016
- Securing Legacy CFML - dev.Objective() 2016 Slides - June 20, 2016
- Adobe eSeminar on FuseGuard - October 26, 2011
- Maximum Security CFML - cfObjective Slides - May 17, 2011
- Writing Secure CFML Slides from CFUnited 2010 - August 5, 2010
- Slides for NYCFUG Security Presentation - November 17, 2009
- Hardening ColdFusion - cfObjective 2009 Presentation Slides - July 6, 2009
Comments
I'd love to see a break down on the differences between xmlFormat(), htmlEditFormat() and encodeForHtml().
I've yet to see an breakdown on the exact differences (but I admit I haven't gone looking through the OWASP pages in a while.)
Adobe did a really poor job in the documentation of the encodeFor*() functions and updating htmlEditFormat() to discuss when each should be used.
I'm assuming htmlEditFormat() should be completely depreciated and you should always use the appropriate encodeFor* functions when outputting a string in your HTML for rendering.
Adobe just should have documented the default rules for how the strings get encoded for each function.
I've yet to see an breakdown on the exact differences (but I admit I haven't gone looking through the OWASP pages in a while.)
Adobe did a really poor job in the documentation of the encodeFor*() functions and updating htmlEditFormat() to discuss when each should be used.
I'm assuming htmlEditFormat() should be completely depreciated and you should always use the appropriate encodeFor* functions when outputting a string in your HTML for rendering.
Adobe just should have documented the default rules for how the strings get encoded for each function.
