CF.Objective Notes -- Application Security Myth or Fact
July 06, 2012
Application Security: Myth or Fact -- Dave Ferguson
Everything you think you know, the FBI will tell you you're wrong
At its core, security is actually risk management
Managing all the risk that goes with putting something on the internet
Once you hook an app to the internet, it's immediately hackable
Security is fundamentally about protecting assets -- files, databases, etc.
Most applications don't have enough protection
Just because you have a login screen doesn't mean your app is secure
Any protection in place is probably insufficient
Get a 3rd party to see if your protection works
Don't just expect it to work, make sure it does
Security implementation is usually a place to protect server/network, not the application
Using Captcha to protect a form is not the same as anti-intrusion
it's more of an annoyance
There are apps that can inspect the captcha and extract what's in it. Captcha won't stop people that REALLY want to get in.
OWASP
group that cares about security, and that people have enough info to protect their apps
puts out a list of top 10 ways people hack sites (new list published every 3 years)
sql injection is #1 way to get your app hacked and destroyed
insecure direct object reference
url?id=5
...and you drop that 5 right into a query without looking at where it came from first
i use SSL so my app is secure -- MYTH
it gives hackers a secure tunnel to hack your system
because the entry/exit points aren't secure
but SSL will prevent some things like "man in the middle" attacks
May app is secure because i have a login screen -- MYTH
Session hijacking (ala if you are working at Starbucks and someone is sniffing cookies coming in through the router)
Can fix session hijacking in CF10 w/ "session rotate"
If the site is not "true SSL", SSL will break (ala if you have an image on your site that isn't coming in via SSL)
I'm using a framework, therefore my app is secure -- MYTH
Frameworks give your app structure, but not security.
We're using ORM, so SQL injection won't work on our site -- MYTH
Properly implemented ORM will help, but if your' using HQL, etc, you can still be injected
WE don't need to worry about security because our site has nothing of value -- MYTH
Value is perceptual
If someone else THINKS you have something highly valuable, it's likely to be hacked
Storing ANY data about a person makes your site a target
The global script protection setting is sufficient -- MYTH
Relying on script protection to save you is a fools errand
This setting strips out a few things, but should not be treated as a silver bullet
Our URL/Form vars are encrypted so they can't be tampered with -- MYTH
if a loose encryption is used, the encryption can be predicted
need to make it a REALLY complicated decryption
CF10 has a new library for some of that
(See Matt Gifford's press for more info on this.)
Thinking like a hacker will help protect my system -- FACT
Keep up w/ the current security trends, look at who is getting hacked and how/why
Remember that security is a frame of mind/practice, not a "once in a while" type of thing
Check OWASP or SecureIIS websites for current trends in hacking, new info, etc.
We're using anti-intrusion software so we're just fine -- MYTH
blocks KNOWN intrusion patterns
so if someone has a NEW pattern, the software is invalid
intruders will attempt to bypass blocking software
Ex:
ModSecurity
SecureIIS
FuseGuard
A couple of things to think about when writing code
If a section is supposed to be secure, make sure the security check is EVERYWHERE, not just the entry point (i.e. login screen)
Compartmentalize your code to minimize exposure
-- put all the Contact Manager code in 1 spot and make sure that no other sub systems interact with it, if possible
Use source control. Don't just comment out code, remove things that aren't being used
Remove dead files from the server
An undeleted file is an intrusion point waiting to happen
Treat all data from a client as "bad" until...forever
If data was XSS attacked, THEN you add security protection, you still have bad data IN your app. Check ALL data that EVER came from users, not just on the way into the database.
Don't leave it up to somebody else, don't leave security for the "other guys" to handle.
Security by obscurity gives you a false sense of security
Using hidden form fields is not a great way to protect your app
Chrome, Firefox, Charles, etc, can all be used to view that stuff easily
More advanced cryptography and other security enhancements in CF10.
ANYTHING that comes from a client can be spoofed
Can even use Charles to spoof the HTTP_REFERER and make it look like the request is coming from a different/same server
Everything you think you know, the FBI will tell you you're wrong
At its core, security is actually risk management
Managing all the risk that goes with putting something on the internet
Once you hook an app to the internet, it's immediately hackable
Security is fundamentally about protecting assets -- files, databases, etc.
Most applications don't have enough protection
Just because you have a login screen doesn't mean your app is secure
Any protection in place is probably insufficient
Get a 3rd party to see if your protection works
Don't just expect it to work, make sure it does
Security implementation is usually a place to protect server/network, not the application
Using Captcha to protect a form is not the same as anti-intrusion
it's more of an annoyance
There are apps that can inspect the captcha and extract what's in it. Captcha won't stop people that REALLY want to get in.
OWASP
group that cares about security, and that people have enough info to protect their apps
puts out a list of top 10 ways people hack sites (new list published every 3 years)
sql injection is #1 way to get your app hacked and destroyed
insecure direct object reference
url?id=5
...and you drop that 5 right into a query without looking at where it came from first
i use SSL so my app is secure -- MYTH
it gives hackers a secure tunnel to hack your system
because the entry/exit points aren't secure
but SSL will prevent some things like "man in the middle" attacks
May app is secure because i have a login screen -- MYTH
Session hijacking (ala if you are working at Starbucks and someone is sniffing cookies coming in through the router)
Can fix session hijacking in CF10 w/ "session rotate"
If the site is not "true SSL", SSL will break (ala if you have an image on your site that isn't coming in via SSL)
I'm using a framework, therefore my app is secure -- MYTH
Frameworks give your app structure, but not security.
We're using ORM, so SQL injection won't work on our site -- MYTH
Properly implemented ORM will help, but if your' using HQL, etc, you can still be injected
WE don't need to worry about security because our site has nothing of value -- MYTH
Value is perceptual
If someone else THINKS you have something highly valuable, it's likely to be hacked
Storing ANY data about a person makes your site a target
The global script protection setting is sufficient -- MYTH
Relying on script protection to save you is a fools errand
This setting strips out a few things, but should not be treated as a silver bullet
Our URL/Form vars are encrypted so they can't be tampered with -- MYTH
if a loose encryption is used, the encryption can be predicted
need to make it a REALLY complicated decryption
CF10 has a new library for some of that
(See Matt Gifford's press for more info on this.)
Thinking like a hacker will help protect my system -- FACT
Keep up w/ the current security trends, look at who is getting hacked and how/why
Remember that security is a frame of mind/practice, not a "once in a while" type of thing
Check OWASP or SecureIIS websites for current trends in hacking, new info, etc.
We're using anti-intrusion software so we're just fine -- MYTH
blocks KNOWN intrusion patterns
so if someone has a NEW pattern, the software is invalid
intruders will attempt to bypass blocking software
Ex:
ModSecurity
SecureIIS
FuseGuard
A couple of things to think about when writing code
If a section is supposed to be secure, make sure the security check is EVERYWHERE, not just the entry point (i.e. login screen)
Compartmentalize your code to minimize exposure
-- put all the Contact Manager code in 1 spot and make sure that no other sub systems interact with it, if possible
Use source control. Don't just comment out code, remove things that aren't being used
Remove dead files from the server
An undeleted file is an intrusion point waiting to happen
Treat all data from a client as "bad" until...forever
If data was XSS attacked, THEN you add security protection, you still have bad data IN your app. Check ALL data that EVER came from users, not just on the way into the database.
Don't leave it up to somebody else, don't leave security for the "other guys" to handle.
Security by obscurity gives you a false sense of security
Using hidden form fields is not a great way to protect your app
Chrome, Firefox, Charles, etc, can all be used to view that stuff easily
More advanced cryptography and other security enhancements in CF10.
ANYTHING that comes from a client can be spoofed
Can even use Charles to spoof the HTTP_REFERER and make it look like the request is coming from a different/same server