Embed Size (px)
Citation preview
Application
Security
@dfgrumpy
blog.dkferguson.com
www.cfhour.com
Dave Ferguson
Myth or Fact?
Obligatory “About Me” Slide
Working in field for a long, long time (15+ years)
Using ColdFusion since version 1.5
Adobe Community Professional
Sr. Developer for Nonfat Media
One of the voices of the <CFHour> ColdFusion podcast w/ Scott Stroz ( @boyzoid )
If you have a question
please ask it anytime
APPLICATION SECURITY?(isn’t that the network guy’s problem?)
Why should you care about
At its core, Security is about risk
management
Security is fundamentally
about protecting “assets”
Most applications don’t have
enough protection
Any protection in place is
probably insufficient
Security implementation is usually
in place to protect server /
network, not application
Using captcha to protect a form is
not the same as anti-intrusion
Once you understand the
perceived value of your
application, you will better
understand how to protect it
What does it mean to have
a secured application?
Some stuff for the
“Network Guy”
Viruses
Worms
Network intrusion
OS Compromise
OWASPOpen Web Application Security Project
OWASP Top 10 (as of 2010)
• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session
Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards
GAME TIME!
MYTH
SSL encrypts data in transit.
Entry and exit points are still unprotected.
Think of a tunnel through a mountain.
Anyone can enter either side but once
inside you can only interact with what is in
the tunnel.
SSL will prevent some things, such as a
“man in the middle” attack.
“My application is secure because I
have a login screen”
MYTH(for the most part)
If not implemented correctly, then this
becomes a myth.
Demo time…
“I don’t need to worry about security
because I am using (insert framework here)”
MYTH
Frameworks give structure to code.
Frameworks make writing secure software
easier by inherently enforcing certain coding
best practices.
Code written in a framework can still have the
same security holes as non-framework code
Frameworks can add some complexity which
requires developers to be more vigilant when
looking for possible attack vectors.
“Our data access layer is ORM so we
are safe from sql injection”
MYTH
Properly implemented ORM does protect
against injection.
However, utilizing HQL can expose the
system to injection.
Demo Time…
“We don’t need to worry about security because our site has nothing of value“
MYTH
Value is perceptual.
The true value of your application is what others deem its value is.
If an intruder believes your application is hiding something of value, they may try to find it.
Your site may only contain trivial data. However, does it contain data that could allow an attacker to get into other systems?
Storing any data about a person makes your site a target.
“The Global Script Protection setting in
the ColdFusion admin is sufficient”
MYTH
The keyword there is “sufficient”.
Relying on script protection to save you is a fool’s errand.
The setting will strip out some things but should not be treated as a silver bullet.
Demo Time…
“Our URL / form variables are encryptedso they can’t be tampered with”
MYTH
If a loose encryption is used, the
encryption could be predicted.
“Thinking like an attacker will help
protect my system”
FACT
Keep up to date on current security trends.
Take a step back when writing code and evaluate it for possible intrusion.
Remember that security is a practice or frame of mind, not a “once in a while” type thing.
“We are using anti-intrusion software
so we are just fine”
MYTH
Anti-intrusion software blocks known intrusion patterns.
They act as a filter to incoming data to stop potentially harmful requests from being processed.
Not 100% effective, as intruders will attempt to bypass blocking software.
Examples: ModSecurity
SecureIIS
FuseGuard
Demo time…
A Couple of things to always think
about when writing code
Tips for the future:
If a section is supposed to be
secure, make sure security is
checked on all pages, not just
entry points
Compartmentalize your
application to minimize exposure
if system is compromised
Reduce the attack surface and
remove unused sections or code
Don’t rely on a single security
layer, use “defense in depth” and
employ multiple security layers
Treat all data from a client as
bad until ... Forever.
Don’t leave security for the
other guy to handle
Security by obscurity gives you
a false sense of security
Thank You
Any
Questions?
@dfgrumpy
http://blog.dkferguson.com
http://www.cfhour.com
Dave Ferguson
