CF Summit notes - Application Security Best Practices, Part 1 - Jason Dean
October 28, 2013
I saw Jason give a version of this talk at a different conference some time ago. He was giving it again at CF Summit due to a last minute schedule change, and Jason stepped in to fill the empty slot. Jason is one of my favorite speakers, blending the right combo of humor and info, keeping everyone engaged the whole time. His slides are incredibly useful as well. I'm all for the occasional joke and kung fu picture in a slide deck, but when the WHOLE thing is that way, it makes the slides impossible to use later as a refresher. Also, Jason's continual cries of "Does ColdFusion do it the correct way by default? No? Adobe, fix that!" were hysterical, yet true. :)
-----
(David Eplher had an emergency and had to change his plans, so Jason stepped in to give a related talk, but not the exact same content.)
Dave's talk can be viewed here:
go.ncsu.edu/ncdevcon2013
now back to jason....
What is security?
security policy
etc
Assets
things like code files, images, config files, etc that you're trying to protect
Vulnerabilities
a weakness in your software that can be used against you
have a formal code review w/ your peers. look at the code discuss how it can be explode
the best eyes to look at your code are NOT yours
if needed, hire an expert
threats ---
a potential violation of security
need to know HOW your assets can be exploited
attacks
attacks are what get attention
threats vs attacks
threats exist, attacks HAPPEN
attacks occur when a hacker makes move against your app
so you need to attack your own app
try to think like a hacker
think how would you attack your app and DO it
use the automated tools
log your activities so you can reproduce it later
...run that same test again to see if your fixes were successful
DO NOT DO IT ON PRODUCTION :)
counter measures --
used to prevent potential exploits
some are out of the box features that just need to be used (cfqueryparam)
others need to be designed/built with a specific purpose in mind
counter measures themselves can have vulnerabilities so THEY need to be reviewed as well.
Ignorance, Assumptions and Laziness
ignorance --
as developers we need to be aware of the threats that are out there
if an attack is successful, we get blamed
we need to be aware of what's going on in our apps
and how they can be used against us
assumptions --
be careful of assumptions about users, hackers, etc
users:
do they all use the app correctly? can't assume that
have to assume users are also potential hackers
assume they are elite hackers and idiots at the same time and try to compensate for both
about hackers...
oh my site is for our local knitting club, they won't attack that
hackers attack for all SORTS of reasons
does the governor use your knitting site?
does he use the same password there as he does for his email?
does your site contain any identity theft info?
don't make assumptions about who the system is going to be used
users will do things you don't want them too
will enter letters in number fields,
will bookmark pages you'd rather they navigate too
they will NOT log out...never ever ever
won't close their browser
how will hackers use the site
try to bypass access controls
will try to inject code
will hope that you don't scope your variables
will pass in thousands of session tokens hoping to find one that works
will use those same automated tools to attack your site
assumptions about host / admin
work w/ the admin, ensure that servers are being patched
that secure connections are made in between servers
control what you can at the application level instead of at the server level
(particularly important during upgrade times)
Laziness
Security fail
excuse: "i don't have time to add that much security"
so what IS security?
what makes an app secure?
that depends
so who decides what is secure, and which solution do we need for our apps?
you do!
you decide what is secure
specifically, you work w/ the stake holders of the app and develop a security policy
security policy will contain a lot of WORDS (not CODE) to define/specify the definition/requirements of our app
rules / regulations / procedures
define things in our apps
who is responsible for patching the OS, ColdFusion, the automation tools?
who is responsible for encryption?
might all be the same person but it needs to be defined
who makes decisions about the data?
need someone in the org that can say "yes THAT person CAN have access to that data", etc
how will our API be implemented?
how will we verify proper auth for that?
how will files be retrieved?
procedures
for data backup plan
how often will backups be done, tested, etc
what do we do in a disaster?
do we have another location of exact dupes of code if a tornado hits our server room?
how do we keep running if something goes wrong?
best practices for sec. policy
should be clear and understandable
don't develop a policy you cannot live up to (or don't have the resources for)
start w/ something simple and add to it if you must
needs to be enforceable
needs to be consistent
needs to be well documented
needs to be flexible
-- sometimes something CANT live up to the policy. need some sort of exception waiver so people don't lose their job when some tasks CANT follow the policy but still need to happen
good ideas / best practices --
principle of least privileges
-- no user needs access to anything more than what they need to do their job
-- do developers need admin access on the server? no
-- does CF itself? no
-- almost NOBODY needs admin access on the server (and those that do, should also have non-admin accounts they can use for day to day stuff)
goal: to never have to log into the admin account on production. can i automate EVERYTHING, deployments updates, etc. then i NEVER have to log in as Admin. Admins are dangerous, even when they know what they're doing. we all do stupid things
automation tools are a great way to be able to remove some privileges for users
Git --> Jenkins and have Jenkins do the FTP / deploy stuff automagically so nobody has to touch the Prod server
Fail Securely
if you're going to fail, fail securely
white list security
define what is explicitly allowed iN, and everything else is denied access
defense in depth
more than 1 level of protection
don't trust third parties
3rd parties are not your spouse, you don't know where they've been
you don't know with whom they've been
their data can be compromised too
3rd party data needs to be validated just like any other user's data
if you're going to output it to the screen, encode it
should be treated just like any other user's data -- as garbage
avoid security by obscurity
-- if i make a funny url no one will find it
just won't tell anyone where to look
just won't tell anyone the encryption key
let's invent our own encryption algorithm
this is NOT security at all. it's JUST obscurity
3 people can keep a secret if 2 of them are dead - ben franklin
Fix it correctly
if you're going to fix it, do it right
patches are tough, especially security patches
do you want it done RIGHT? or do you want me to do it NOW?
well architected apps can make that easier
properly architected OO apps can make patching easier
web app firewalls can help here
when an attack occurs, it has a specific signature (often)
can say "block any attack that looks like THIS"
if you put in a quick patch, make time to go back an redo it properly
understand the trade-offs
security vs usability
sec vs performance sec. vs time/ money
security vs usability
set session time to 1 minute is more secure than 20 mites, but it's not very usable
want to find a compromise that works for everyone...but if i have t pick between making the app useable or more secure, which do i chose? it depends on the app.
requiring re-entry of a password for every operation is more secure, but harder to use
on amazon, if i change a credit card number, i have to re-enter my password even tho i'm already logged in
security vs performance
SSL / HTTPS is more secure but decreases performance
SSL handshake in particular is slow
will delay the initial connections
proper password security requires that you slow down the login process and heavy compute cycles
heavy evaluation can cause slowdowns but leads to better security
-- cfqueryparam is the only case where adding security INCREASES performance
security vs time / money
can't SEE sec features
often those aren't things the client gets excited about
doesn't have pretty colors
"i have to spend $$$ on WHAT?"
sometimes it's our job to convince them they NEED to spend money on this
need to understand that sec is worth it
but make sure you're not spending a dollar to protect 99 cents. find the value of the data you're protecting.
Positive Sec Mode
default deny white listing
opposite of negative security model
define what IS allowed
new attacks can still be stopped (whereas w/ black-list security, they can't)
"if it doesn't look like a valid request, block it"
client side validation is great for usability but does NOTHING for enhancing security
if it happens in JavaScript at ALL, it does NOTHING for security
most security vulnerabilities can be avoided if proper validation is in place
password security ---
store passwords secretly
-- the plain text password the user types in
-- needs to go over TLS/SSL
-- that is the LAST time that those passwords should EVER appear in plain text
-- if they ever appear in plain text again (or it's possible to do so, then your password security is WRONG)
do not use MD5!
not a great algorithm
but it's easier to look at in the code examples for this preso
Hash( "password", "MD5" )
MD5
-- everything spits out a 32 character log hash
-- via "hash digest"
-- the attempt is a unique digest for each string
but that doesn't happen w/ md5
SHA-256
SHA-512
...having 2 inputs with the same digest is much less likely with these lengths
hash collision -- when 2 strings result in the same digest
less likely with SHA 256 and 512 but can still happen
making a password secure--
Salting
each user should have their own salt
Hash( "password" & "salt1", "SHA-512")
so now EVERY password in our app will be unique, no duplicate values in the database, even after encryption
just remember to store the salt somewhere so you can re-auth the user later
better than hashing + salting is BCrypt (or SScript when it gets more mature and when it gets a Java library implementation)
standard hashing algos are REALLY fast
that's not a good thing
fast hashing makes brute force attacks easier
BCrypt is designed to slow down the process by introducing a work factor
-- BCrypt is designed for passwords
-- adaptable to change with new processor speeds
-- easier to implement than what we looked at earlier
ex:
install bcrypt jar file
PBKDF2
-- for government stuff
-- better than hashing/salting but harder to implement
-- doesn't require additional libraries
included w/ java 6
easily adjustable to make it stronger, etc.
can be used for generating keys for encrypting user data
considered less secret than BCrypt
-----
(David Eplher had an emergency and had to change his plans, so Jason stepped in to give a related talk, but not the exact same content.)
Dave's talk can be viewed here:
go.ncsu.edu/ncdevcon2013
now back to jason....
What is security?
security policy
etc
Assets
things like code files, images, config files, etc that you're trying to protect
Vulnerabilities
a weakness in your software that can be used against you
have a formal code review w/ your peers. look at the code discuss how it can be explode
the best eyes to look at your code are NOT yours
if needed, hire an expert
threats ---
a potential violation of security
need to know HOW your assets can be exploited
attacks
attacks are what get attention
threats vs attacks
threats exist, attacks HAPPEN
attacks occur when a hacker makes move against your app
so you need to attack your own app
try to think like a hacker
think how would you attack your app and DO it
use the automated tools
log your activities so you can reproduce it later
...run that same test again to see if your fixes were successful
DO NOT DO IT ON PRODUCTION :)
counter measures --
used to prevent potential exploits
some are out of the box features that just need to be used (cfqueryparam)
others need to be designed/built with a specific purpose in mind
counter measures themselves can have vulnerabilities so THEY need to be reviewed as well.
Ignorance, Assumptions and Laziness
ignorance --
as developers we need to be aware of the threats that are out there
if an attack is successful, we get blamed
we need to be aware of what's going on in our apps
and how they can be used against us
assumptions --
be careful of assumptions about users, hackers, etc
users:
do they all use the app correctly? can't assume that
have to assume users are also potential hackers
assume they are elite hackers and idiots at the same time and try to compensate for both
about hackers...
oh my site is for our local knitting club, they won't attack that
hackers attack for all SORTS of reasons
does the governor use your knitting site?
does he use the same password there as he does for his email?
does your site contain any identity theft info?
don't make assumptions about who the system is going to be used
users will do things you don't want them too
will enter letters in number fields,
will bookmark pages you'd rather they navigate too
they will NOT log out...never ever ever
won't close their browser
how will hackers use the site
try to bypass access controls
will try to inject code
will hope that you don't scope your variables
will pass in thousands of session tokens hoping to find one that works
will use those same automated tools to attack your site
assumptions about host / admin
work w/ the admin, ensure that servers are being patched
that secure connections are made in between servers
control what you can at the application level instead of at the server level
(particularly important during upgrade times)
Laziness
Security fail
excuse: "i don't have time to add that much security"
so what IS security?
what makes an app secure?
that depends
so who decides what is secure, and which solution do we need for our apps?
you do!
you decide what is secure
specifically, you work w/ the stake holders of the app and develop a security policy
security policy will contain a lot of WORDS (not CODE) to define/specify the definition/requirements of our app
rules / regulations / procedures
define things in our apps
who is responsible for patching the OS, ColdFusion, the automation tools?
who is responsible for encryption?
might all be the same person but it needs to be defined
who makes decisions about the data?
need someone in the org that can say "yes THAT person CAN have access to that data", etc
how will our API be implemented?
how will we verify proper auth for that?
how will files be retrieved?
procedures
for data backup plan
how often will backups be done, tested, etc
what do we do in a disaster?
do we have another location of exact dupes of code if a tornado hits our server room?
how do we keep running if something goes wrong?
best practices for sec. policy
should be clear and understandable
don't develop a policy you cannot live up to (or don't have the resources for)
start w/ something simple and add to it if you must
needs to be enforceable
needs to be consistent
needs to be well documented
needs to be flexible
-- sometimes something CANT live up to the policy. need some sort of exception waiver so people don't lose their job when some tasks CANT follow the policy but still need to happen
good ideas / best practices --
principle of least privileges
-- no user needs access to anything more than what they need to do their job
-- do developers need admin access on the server? no
-- does CF itself? no
-- almost NOBODY needs admin access on the server (and those that do, should also have non-admin accounts they can use for day to day stuff)
goal: to never have to log into the admin account on production. can i automate EVERYTHING, deployments updates, etc. then i NEVER have to log in as Admin. Admins are dangerous, even when they know what they're doing. we all do stupid things
automation tools are a great way to be able to remove some privileges for users
Git --> Jenkins and have Jenkins do the FTP / deploy stuff automagically so nobody has to touch the Prod server
Fail Securely
if you're going to fail, fail securely
white list security
define what is explicitly allowed iN, and everything else is denied access
defense in depth
more than 1 level of protection
don't trust third parties
3rd parties are not your spouse, you don't know where they've been
you don't know with whom they've been
their data can be compromised too
3rd party data needs to be validated just like any other user's data
if you're going to output it to the screen, encode it
should be treated just like any other user's data -- as garbage
avoid security by obscurity
-- if i make a funny url no one will find it
just won't tell anyone where to look
just won't tell anyone the encryption key
let's invent our own encryption algorithm
this is NOT security at all. it's JUST obscurity
3 people can keep a secret if 2 of them are dead - ben franklin
Fix it correctly
if you're going to fix it, do it right
patches are tough, especially security patches
do you want it done RIGHT? or do you want me to do it NOW?
well architected apps can make that easier
properly architected OO apps can make patching easier
web app firewalls can help here
when an attack occurs, it has a specific signature (often)
can say "block any attack that looks like THIS"
if you put in a quick patch, make time to go back an redo it properly
understand the trade-offs
security vs usability
sec vs performance sec. vs time/ money
security vs usability
set session time to 1 minute is more secure than 20 mites, but it's not very usable
want to find a compromise that works for everyone...but if i have t pick between making the app useable or more secure, which do i chose? it depends on the app.
requiring re-entry of a password for every operation is more secure, but harder to use
on amazon, if i change a credit card number, i have to re-enter my password even tho i'm already logged in
security vs performance
SSL / HTTPS is more secure but decreases performance
SSL handshake in particular is slow
will delay the initial connections
proper password security requires that you slow down the login process and heavy compute cycles
heavy evaluation can cause slowdowns but leads to better security
-- cfqueryparam is the only case where adding security INCREASES performance
security vs time / money
can't SEE sec features
often those aren't things the client gets excited about
doesn't have pretty colors
"i have to spend $$$ on WHAT?"
sometimes it's our job to convince them they NEED to spend money on this
need to understand that sec is worth it
but make sure you're not spending a dollar to protect 99 cents. find the value of the data you're protecting.
Positive Sec Mode
default deny white listing
opposite of negative security model
define what IS allowed
new attacks can still be stopped (whereas w/ black-list security, they can't)
"if it doesn't look like a valid request, block it"
client side validation is great for usability but does NOTHING for enhancing security
if it happens in JavaScript at ALL, it does NOTHING for security
most security vulnerabilities can be avoided if proper validation is in place
password security ---
store passwords secretly
-- the plain text password the user types in
-- needs to go over TLS/SSL
-- that is the LAST time that those passwords should EVER appear in plain text
-- if they ever appear in plain text again (or it's possible to do so, then your password security is WRONG)
do not use MD5!
not a great algorithm
but it's easier to look at in the code examples for this preso
Hash( "password", "MD5" )
MD5
-- everything spits out a 32 character log hash
-- via "hash digest"
-- the attempt is a unique digest for each string
but that doesn't happen w/ md5
SHA-256
SHA-512
...having 2 inputs with the same digest is much less likely with these lengths
hash collision -- when 2 strings result in the same digest
less likely with SHA 256 and 512 but can still happen
making a password secure--
Salting
each user should have their own salt
Hash( "password" & "salt1", "SHA-512")
so now EVERY password in our app will be unique, no duplicate values in the database, even after encryption
just remember to store the salt somewhere so you can re-auth the user later
better than hashing + salting is BCrypt (or SScript when it gets more mature and when it gets a Java library implementation)
standard hashing algos are REALLY fast
that's not a good thing
fast hashing makes brute force attacks easier
BCrypt is designed to slow down the process by introducing a work factor
-- BCrypt is designed for passwords
-- adaptable to change with new processor speeds
-- easier to implement than what we looked at earlier
ex:
install bcrypt jar file
PBKDF2
-- for government stuff
-- better than hashing/salting but harder to implement
-- doesn't require additional libraries
included w/ java 6
easily adjustable to make it stronger, etc.
can be used for generating keys for encrypting user data
considered less secret than BCrypt