ColdFusion 10 Security Enhancements Presentation
By Pete Freitag
Update: If you are looking for more up to date CF security info, checkout my ColdFusion Security Training course.
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!
ColdFusion 10 Security Enhancements Presentation was first published on June 07, 2012.
If you like reading about coldfusion, security, cf10, presentations, or slides then you might also like:
- ColdFusion Summit 2024 Slides: 20 ways to secure CF
- Speaking at ColdFusion Summit Online Next Week
- ColdFusion Summit 2022 Slides
- ColdFusion 2020 Developer Week - Securing CF
The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.
Try Fixinator
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.