Wednesday, February 25, 2015

OWASP Attacks Part 3 Injection

Moved to New Site

This is the subject with the widest breadth. I'll not be able to cover every kind of injection attack out there, but I will still mention them so you can look them up if you are curious, but the subject of injection will probably span a few posts.

SQL Injection
This occurs when query parameters are acquired from the end user and they contain characters that will cause the SQL command to execute in a way that it was not intended.

Lets have an example, here is a little query:
select `social_security_no` from `sensitive_table` where `user_name` = 'jclark' and `password`= 'superSecret';

What would happen if someone created a user account with some non-alpha-numeric characters?
Something like user name = "*';--";

select `social_security_no` from `sensitive_table` where `user_name` = '*';--' and `password`= 'passwordPants';

Here you see the user name, with it's unescaped characters, will have a big impact on how this query executes.
The system will now select all the SSNs where username is equal to a wildcard character, and the -- will comment out the rest of the query.
So it will effectively return all the SSNs stored in the table.

There are several methods that can be used to help protect your queries.
Regular Expressions, PHP's PDO, PHP's addslashes(), .NET's  SqlParameter Class, and many more.

Blind SQL Injection
The term is derived from the fact that you may not be printing the data returned from the query out to the page, but the query is still running.
Check out the following pseudo-code:

try{ 
    sql_command = "select * from table where parameter='parm_from_url'";
    if(execute(sql_command)!=null)
        LoadPageOne();
}
catch(Exception ex){
    //show 404 page
}

You can see here that even though a page doesn't show data that is returned from the SQL command directly, there is still the indirect knowledge that is gained by which page loads. This allows an attacker to ultimately ask your database true or false questions.
Although slow, it it still a data leak that could lead to ruin.

Comment Injection Attack
Comment commands in code are super handy for developers, but if input from end users isn't properly parsed, large chucks of your code could become a comment and not run correctly anymore.
The goal of this attack is to get a program to disregard a portion of itself as a comment, causing a huge variety of outcomes. The goal usually is to bypass parameter sanitization 

We touched on this a little above. With the -- MySql comment character. There is also #, ,  and /*, for the different flavors of SQL. These will truncate the the rest of the SQL command so that the attackers query can execute without worrying about providing data for the rest of the parameters.

The PHP comments // and /* can cause problems if not properly escaped,i.e. \/\/ or \/*.

The most common one I've seen is an inability to handle the HTML comment opening tag <!--
Nothing gives me more join than dropping this meatball in a form and then seeing the page stop rendering half way down after submission.

Be sure to test your URL variables, form information, and even cookie information before allowing it to leave its dirty makes on your code and database. 

No comments:

Post a Comment