Blackhat USA 2009 – Day 1

Posted by Brett Hardin on 8th July 2009

Reading time: 3 – 5 minutes

Blackhat USA 2009   Day 1

Photo: Roadsidepictures

This is the first in a three-part-series on BlackHat USA 2009. (part 2)

A dark cloud is about to approach Las Vegas. The city of sin will soon get cold sweats at night when they realize what is approaching. At the end of July, Las Vegas will be pounced upon by hundreds of security professionals at the annual BlackHat convention.

BlackHat is the most well known computer and Internet security conference in the world. I always have a hard time deciding what talks to go see. I typically end up flagging way too many talks, and get burned out rather quickly. In addition, there are the security booze-hounds/gamblers that are very persuading in swaying you away from the talks.

This year, I thought I would try something different. I am listing the talks I want to see on this blog in an attempt to make sure I show up to them. We will see if this happens.

Day 1 – Wednesday – July 29th

[10:00am] Rod Beckstrom Rod Beckstrom on Twitter

Beckstrom’s Law: A Model for Valuing Networks and Security

[11:15am] Nathan Hamiel Blackhat USA 2009   Day 1, Shawn Moyer Blackhat USA 2009   Day 1

Weaponizing the Web: More Attacks on User-Generated Content

[1:45pm] Nitesh Dhanjani Nitesh Dhanjani on Twitter

Recoverable Advanced Metering Infrastructure / Psychotronica

[3:15pm] Mark Dowd Blackhat USA 2009   Day 1, Ryan Smith Blackhat USA 2009   Day 1, David Dewey

The Language of Trust: Exploiting Trust Relationships in Active Content

[4:45pm] Thomas H. Ptacek Blackhat USA 2009   Day 1, David Goldsmith Blackhat USA 2009   Day 1, Jeremy Rauch Blackhat USA 2009   Day 1

Hacking Capitalism ‘09: Vulnerabilities In Markets And Trading Platforms

[6:00pm] The Pwnie Awards Blackhat USA 2009   Day 1


8Jul

Injection Flaws

Posted by Brett Hardin on 8th July 2009

Reading time: 3 – 4 minutes

http://www.flickr.com/photos/justin_case/

Photo: Justin_Case

This is the second-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Injection Flaws

Injection flaws are a class of security vulnerability that allows a user to “break out” of the web application context. If your web application takes user input and inserts that user input into a back-end database, shell command, or operating system call, your application may be susceptible to an injection flaw.

A user exploits this by breaking out of the intended “context” and appends additional and often unintended functionality. By allowing injection flaws in your application you are allowing an attacker to create, read, update, or delete any arbitrary data available to the application.

Examples of Injection Flaws

There are many types of injection flaws. The most common being SQL injection. In addition there is LDAP injection, XML Injection, XPath Injection, OS command injection, and HTML injection. Injection flaws however are not limited to just these. If your web application inserts user input into any interpreter or process, your web application can contain these vulnerabilities. You can see an example of how an injection flaw works here.

How Do You Prevent Injection Flaws

Before calling an external function, verify that the data is what you expect. This is referred to as validation. For instance, if you expect your function to be passed a string that contains a user’s first name, should it contain any special characters? John is a valid name. But, J<o>hn isn’t. Both user names need to be ran through a validation function and in order for the web application to determine whether the data is what the developer expects.

There are certain exceptions however that can get you in trouble. Single Quotes (‘) are valid characters in people’s last names. However, if you allow a single quote in a last name field, you can be introducing SQL injection into your application.

In cases where you need to allow a single quote (‘), in addition to validation, you should also sanitize (encode) the input. Sanitizing the input is determining a way that the input can be transformed into “non-threatening” data. This needs to be done on a case by case basis.

For example, If you understand that the sanitized data will always be returned in a browser, you could simple HTML encode or URL encode the string. A quote becomes, ' (HTML encoding) or %27 (URL encoding).

When sanitizing input, it is important to make sure you decode the string before it is displayed to the user. It can be embarrassing if John O’Brien’s name is printed as: Tim O%27Brien

8Jul

SQL Injection – Primer

Posted by Brett Hardin on 7th July 2009

Reading time: 1 – 2 minutes

Photo: XKCD

Photo: XKCD

SQL Injection is an injection flaw where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user’s input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following SQL statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.

7Jul