CF Summit Notes: Application Security and ColdFusion 11 -- Jason Dean
October 19, 2014
Application Security and ColdFusion 11 -- Jason Dean
Adobe doesn't have a great reputation with regards to security
it's undeserved.
Adobe security is good and getting better
Concurrent User Logins
allow / disallow concurrent logins
TLS / SSL Web Sockets
Secure Profile
in CF10 can only activate at install time
in cf11 can turn on/off whenever you want
but don't just turn it on and assume you're done
Crypto -- If you're using CFMX_COMPAT you are doing encryption WRONG
you NEED to specify an algorithm
Secure Profile does NOT lock down your web server
it also doesn't protect you from bad code
still need to project against SQL injection, etc
it doesn't set up any IP restrictions
you need to do this yourself
so use best coding practices and the CF lockdown guide
Sandbox Security has been around a LONG time.
its been improved
it uses the location of your files to determine what the execution of those files have access to
"only files in /foo can talk to this datasource, these java classes, these files, etc"
Previously all this was only in CF Enterprise, now in CF 10+ it's in Standard too
but was limited to a single sandbox per server
cf11 provides MULTIPLE sandboxes
encrypted email --
CF11 makes it pretty easy
CF can now send encrypted emails
the syntax and settings are pretty easy
PBKDF2
can use a pass phrase to create an encryption key
most people use it for password hashing / storage
instead of something like SHA256 or SHA512
it is NIST approved (important to gov't people)
doesn't not require additional libraries (bcrypt does), PBKDF2 already exists in Java 6+
best practice - use different keys for diff't purposes. don't use the same key for 2 different "things"
a key of ANY length can be created from a pass phrase
this can make key mgmt easier
don't need to store the key, can just store the pass phrase
allows you to make user-specific keys more easily
allows you to use crypto without persistently storing keys
XSS -- cross site scripting
new XSS features in CF11
XSS is still VERY prevalent
it's confusing
it's also confusing to implement counter measures
data and code contexts
data context - for display on a page
code - for execution
XSS involves breaking out of data context and into a code context
or by changing a code context to behave differently
each context must be handled differently
use HTTPOnl cookies so javascript doesn't have access to the session cookie
the "script protect" checkbox hardly does anything at all. just turn it off. you need must better protection than that.
ESAPI
available in fully-patched instance of CF8+
Contexts --
several different ones in which we need to be aware
each needs to be handled in a special way
cannot use 1 encoding method for all of the contexts
cannot just use HTMLEditFormat() for everything -- that is wrong
you can choose to escape the input by:
using EASPI directly (cf9 and below)
using ESAPI4CF (cf8 or 9)
using the CF functions that use the ESAPI encoder internally (cf10+)
(CF9 end of life in 3 months!)
HTML Elements Context
most common context for showing data
encodeForHTML()
HTML Attribute Context
encodeForHTMLAttribute()
encodeForHTML() will not encode spaces. subtly different
javaScript events (on click, onmouseover) are NOT in the HTML Attribute context. those are executable, part of javascript context.
JavaScript Context --
a few different ones
in a
Adobe doesn't have a great reputation with regards to security
it's undeserved.
Adobe security is good and getting better
Concurrent User Logins
allow / disallow concurrent logins
TLS / SSL Web Sockets
Secure Profile
in CF10 can only activate at install time
in cf11 can turn on/off whenever you want
but don't just turn it on and assume you're done
Crypto -- If you're using CFMX_COMPAT you are doing encryption WRONG
you NEED to specify an algorithm
Secure Profile does NOT lock down your web server
it also doesn't protect you from bad code
still need to project against SQL injection, etc
it doesn't set up any IP restrictions
you need to do this yourself
so use best coding practices and the CF lockdown guide
Sandbox Security has been around a LONG time.
its been improved
it uses the location of your files to determine what the execution of those files have access to
"only files in /foo can talk to this datasource, these java classes, these files, etc"
Previously all this was only in CF Enterprise, now in CF 10+ it's in Standard too
but was limited to a single sandbox per server
cf11 provides MULTIPLE sandboxes
encrypted email --
CF11 makes it pretty easy
CF can now send encrypted emails
the syntax and settings are pretty easy
PBKDF2
can use a pass phrase to create an encryption key
most people use it for password hashing / storage
instead of something like SHA256 or SHA512
it is NIST approved (important to gov't people)
doesn't not require additional libraries (bcrypt does), PBKDF2 already exists in Java 6+
best practice - use different keys for diff't purposes. don't use the same key for 2 different "things"
a key of ANY length can be created from a pass phrase
this can make key mgmt easier
don't need to store the key, can just store the pass phrase
allows you to make user-specific keys more easily
allows you to use crypto without persistently storing keys
XSS -- cross site scripting
new XSS features in CF11
XSS is still VERY prevalent
it's confusing
it's also confusing to implement counter measures
data and code contexts
data context - for display on a page
code - for execution
XSS involves breaking out of data context and into a code context
or by changing a code context to behave differently
each context must be handled differently
use HTTPOnl cookies so javascript doesn't have access to the session cookie
the "script protect" checkbox hardly does anything at all. just turn it off. you need must better protection than that.
ESAPI
available in fully-patched instance of CF8+
Contexts --
several different ones in which we need to be aware
each needs to be handled in a special way
cannot use 1 encoding method for all of the contexts
cannot just use HTMLEditFormat() for everything -- that is wrong
you can choose to escape the input by:
using EASPI directly (cf9 and below)
using ESAPI4CF (cf8 or 9)
using the CF functions that use the ESAPI encoder internally (cf10+)
(CF9 end of life in 3 months!)
HTML Elements Context
most common context for showing data
encodeForHTML()
HTML Attribute Context
encodeForHTMLAttribute()
encodeForHTML() will not encode spaces. subtly different
javaScript events (on click, onmouseover) are NOT in the HTML Attribute context. those are executable, part of javascript context.
JavaScript Context --
a few different ones
in a