Cатсн²² (in)sесuяitу / ChrisJohnRiley

Injecting Simplicity not SQL – David Rook

Talk not aimed at specific vulnerabilities or new attack vectors.

AIM: Try and provide an answer to the problems in application security

• It’s broken lets fix it
• The current approach
• The principles of secure development
• The principles approach is working

Secure Development is broken

We aren’t progressing. SQL Injection is 10 years old, XSS is 11 years old. These are still problems after more than a decade.

SQL and XSS accounted for around 31.65% in 2010, and have accounted for around a third of all CVE numbers over the last few years.

Note: CVE numbers only show publicly available exploits

This shows a lack of application security progress.

WASC Web Application Security Statistics offers another option to the CVE numbers, but is again a limited dataset (around 33,000 sites checked)

Verizon Data Breach Investigations Report 2010 states that 89% of all data breaches are attributable to SQL Injection.

The Current Approach

Developers aren’t taught how to develop secure code, they’re taught how to exploit flaws using things like WebGoat. This doesn’t teach them how to prevent this however.

What if we used that method to teach driving. We don’t take a learner driver and teach them how to crash into a wall in a hope they learn how to avoid it. But that’s the method we’re using currently to teach developers.

The use of lists such as the OWASP Top 10 are contributing to the problem. They have their place, but for a developer looking to learn how to write secure code they cause confusion.

Between lists the terms don’t match. This adds to the confusion. By looking at the name it’s also hard to find what the real vulnerability is. Between the 3 major lists there are 45 entries (41 unique names). Web Developers pointed to these lists are confused.

Philosophical Application Security

Give a man a fish…..

Teach a developer about the vulnerability and he can protect against it.

Teach a developer how to develop secure code, and he can write secure code.

What do we need

Put the application security horse before the cart

The principles of secure developement

• Input Validation
• Output Validation
• Error Handling
• Authentication and Authorisation
• Session Management
• Secure Communications
• Secure Storage
• Secure Resource Access
• Auditing and logging

Input Filtering

Understand the data your application accepts and set data types. Understanding the input allows you to restrict input.

Find the input locations of your application. This is becoming harder and harder, but to secure an application you need to know where the data comes from.

Information to have about all your input points

• Type
• Length
• Size

Obviously the use of regex and white-listing is preferred, but not always possible (speed, complexity, …)

Canonicalisation  –> make sure to decode the string before validation

Demo –> Input Validation (See website for demo videos)

Output Validation

Understanding what you’re outputting to the user. Knowing where your data is going to end up.

Make sure it’s encoded correctly depending on where the output appears.

Make sure you’re filtering data that shouldn’t be displayed back (i.e. credit card numbers are totally are partially starred out)

Don’t rely on input validation alone. Where does your data come from?

Demo –> Input Validation (See website for demo videos)

Error Handling

Even the best programmer has to handle exceptions.

If you don’t handle exceptions then the information returned to the user can be really helpful to an attacker.

Returning ODBC or SQL error messages is good for an attacker.

No error handling == Information leakage

Demo –> Input Validation (See website for demo videos)

Authentication and Authorisation

When you’re designing the application, break it down into different sections and ensure that an authentication and authorisation check is in place. Beware of horizontal (user to other user) and vertical (user to admin) privilege escalation.

Are passwords right for your application? If not use something else.

If you are using passwords, make them complex and securely stored (hashes instead of clear text storage)

Password reset questions need to be something more complex than “mothers maiden name”

CAPTCHA –> Need to be implemented correctly. Can you bypass it and directly call the function/activity behind it?

Maybe re-authenticate for things like money transfer

Session Management

Make sure to use good tested SessionIDs. Use the biggest character set possible, with sufficient entropy.

Don’t roll your own, use a known and accepted system.

Protect SessionIDs using things like SSL/TLS.

Don’t pass a SessionID using clear text (don’t drop to HTTP after logon)

Issue a new SessionID for things like account transfers.

Make sure to set limits and expiration

Secure Communications

Protect data in transit

Avoid things like DES and SHA-0

SSLv2 is bad…. use TLS

Don’t mix secure and insecure together

Secure Storage

Protect data when stored

Use known and accepted encryption

Don’t store data in places where you can’t be confident it is secure –> Client side, isn’t secure

How strong should your storage protection be –> depends on what you’re securing

Store, rotate and destroy encryption keys –> policy and process in place

Secure Resource Access

A bit of a catchall for things that don’t fit elsewhere

Don’t rely on security through obscurity

Patching, setting permissions correctly and hardening your servers

Auditing and Logging

Log records you should be logging –> failed logons etc

Make sure the info is enough for your forensic/incident handling process

Don’t store things you shouldn’t –> credit card info, passwords etc.

Monitor for changes using tripwire

Conclusions

Follow a small, repeatable set of principles

Try not to focus on specific vulnerabilities

Make sure everybody know where and what they’re meant to be doing

If your secure development training doesn’t change the way your developers code, you’ve failed

Links:

• David Rook Twitter –> @securityninja
• Securityninja.co.uk
• Talk –> Slides
• Realex Payments