Application Security - Myth or Fact Slides

Application

Security

@dfgrumpy

dave@dkferguson.com

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!

“I use SSL so my application is secure”

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

dave@dkferguson.com

http://blog.dkferguson.com

http://www.cfhour.com

Dave Ferguson