Thursday, July 15, 2010
brett.jpgBrett presented a talk on some of the "Not so common code vulnerabilities".

The theme of his talk was that we shouldn't trust user input.

My notes:

A security vulnerability in an app - a weakness that allows a user to perform an action that was unintended.

AppTrends graph ( - input validation is the cause of everything (XSS, SQL injection, etc)

Frameworks won't protect you (e.g. .NET, PHP, Java frameworks).

Frameworks can promote bad practices, or have bugs in them themselves.

- Spring Framework - override class loaded
- Struts2 - execute arbitrary java code

Examples of problems:

Trusting filenames / urls from the user

Using 302 Redirects as a security measure - returning secure

content below the redirect by mistake

Captchas: Tell whether it's a human or computer. Bad implementations where people have rolled their own and make it easy for computer to answer

Online shopping: Response from DPS comes in a browser redirect, so you can intercept it, and add extra stuff to the shopping cart after paying, but before the website thinks the order is finished.

Flash: Parameters for a flash movie can be entered in the url as well. Movie hosted on our site can end up displaying images or other content from our attack website.

Forgotten password: Stored proc truncates email address to 100 characters when looking up the user, but application uses the whole string. This can lead to an attacker receiving the forgotten password email.

Java object serialisation: Object is serialised into a cookie using Base64 encoding. Ooops: It contains something sensitive like a password.

PHP app in a security appliance used by a .mil: Shell out to a system command using a url parameter passed via an unauthenticated user.

Cookies: storing security data in a cookie - example of LoginAttempts - an attacker can modify the cookie to their hearts content.

Cookie: remember me functionality - store random token in the database and send it to the user as a cookie, so they can log in automatically. Vulnerability: flawed if null was stored in both the db and the cookie.


Never trust the users input

Input validation is the key.

You can use hidden form fields or cookies, as long as the backend input validation is secure. You can't trust that the frontend is doing things correctly.

Backend should:
- Validate the data
- Ensure the user is authorised to access the data

Data comes in many forms (upper / lower case, encoded etc)

- Decode the data, or reject it if a normal user wouldn't send it

Ensure data conforms to the correct format
- Check length, type, min / max values
- Alphanumeric / valid date only

Reject invalid data, rather than attempting to fix it up.

Beware writing your own data sanitisation functions - needs to be well tested and document. Use OWASP or language features if possible.

- Easy to write bad sanitisation. Examples of bad url testing,

XSS works without script


- Review your code. Have "Code Review Parties"
- Have peer reviews
- Have standards, and stick to them

Questions to Brett:

Should we still trust CAPTCHA?

Still effective at the moment, but can be broken.

Comments are closed.