Browser Headers SQL injection?

knowj

Is it possible for a user to manipulate the browser headers to preform an injection attack on a database?

For instance most systems log the ip with any user activity. Would it be possible for this to be manipulated into a injection query?

etully

There are some areas where you could be vulnerable. Here's the broad rule of thumb: Don't trust anything that comes from the user's computer.

In order to understand where you could be vulnerable, you have to understand the general workflow of an HTTP request.

The browser headers are supplied by the web server and received by the user's computer. Not the other way around. So the user couldn't do anything to you with browser headers. (In some obscure universe, where the user is receiving web pages and storing them in a database, then sure, you could screw your users by planting SQL injection attacks in the browser headers but that's not your question).

The user's computer sends an HTTP request and puts headers in that. As you said, most web sites log some of this information but typically it's done in a flat text file so if you're running Apache out of the box, you're safe there.

If you are storing them in a SQL database, then you need to examine everything that comes in as part of those HTTP headers. Cookies are in the HTTP headers and definitely should be checked. User Agent (browser type and operating system) comes from the HTTP headers and definitely should be checked (again, only necessary if you are writing them to a database. Flat text file logging is safe which is how most people do it).

In your example, you mentioned the user's IP address. This information does not come from the HTTP headers. It comes from the TCP stack in your operating system which relays the IP to Apache which (A) safely writes it to a flat text file log and (😎 gives it to PHP to store in an environment variable. The user has no control over this - it doesn't come from the user's machine - and so it doesn't fall under the broad advice at the top of this post, "Don't trust anything that comes from the user's computer."

NogDog

In general, simply follow the rule suggested above of not trusting any external data. With regards to database injection, if you escape all externally supplied data via the applicable escaping mechanism for the database interface being used (e.g. mysql_real_escape_string()), then SQL injection cannot occur.

etully

if you escape all externally supplied data via the applicable escaping mechanism for the database interface being used (e.g. mysql_real_escape_string()), then SQL injection cannot occur.

This is incorrect.

Assume that there is a cookie on my machine called userid which is an integer.
Assume that I am an evil hacker who can change the value of cookies.

I change the value of the cookie from 12345 to:

12345 or id>0

Now what happens when I go to delete my account?

$id = mysql_real_escape_string("12345 or id>0");
$query = "delete from customers where id=$id";

dagon

etully, nogdog said external data, which would include a cookie

etully

dagon: Yes, I did hear him say external data (including cookies).

Please re-read my post. He said that if you use mysql_real_escape_string then SQL injection cannot occur and that is just dangerously wrong.

NogDog

Etully's comment is correct, however I didn't think about it as when I'm working with the MySQL interface (as opposed to prepared statements in MySQLi or PDO, which makes this even less of an issue) I habitually use sprintf() to build the query with the applicable place-holders, meaning any non-numeric value which got past my form validation for some reason would be essentially cast to that type anyway, eliminating the possibility of a supposed numeric value having a string appended to it as in his valid example problem.

$query = sprintf(
   "delete from customers where name='&#37;s' and id=%d",
   mysql_real_escape_string($_POST['name']),
   $_POST['id']
);

In essence this is similar to using a prepared statement in the way that it effectively casts the input value to the appropriate type.

knowj

So basically just use prepared statements and save yourself the heartache.

I never trust anything off the user but you can end up going overboard and stopping genuine users from entering their name for instance if they have certain characters in their name etc... It's getting a balance of protecting the system but not at the expense of the normal user.

This becomes more of a headake when you get into the realms of XXS.

Is it possible to inject into a prepared statement? or are they about as secure as you can get?

NogDog

I cannot see how to do the same sort of injection if you use prepared statements, as numeric placeholder values will be cast as such and string values will be automatically quoted and escaped.

etully

I cannot see how to do the same sort of injection if you use prepared statements, as numeric placeholder values will be cast as such and string values will be automatically quoted and escaped.

I agree. Using a combination of sprintf and mysql_real_escape_string will protect you against just about every SQL injection attack.

I know I'm beating a dead horse but I just want to stress that just because you use sprintf() and mysql_real_escape_string() doesn't mean you can turn your brain off and forget about validating customer input.

Here's my last example and then I'll drop it. Imagine you had radio buttons, male=1, female=2. Now imaging that the cost of your service is $50 plus $10 if you're male or $15 if you're female.

$cost = 50;
if ($gender==1) { $cost += 10 ; }
if ($gender==2) { $cost += 15 ; }

If you wrote the customer's gender to a database and the hacker-customer passed in "3" for his gender, sprintf(%d) would not see any problem with the "3" and IT WOULD ALLOW HARMFUL DATA TO BE WRITTEN TO YOUR DATABASE. In this example, someone could cheat you out of ten bucks. Not the end of the world. But it wouldn't be hard to come up with an example where bad data in your database could cause your web site to fail.

I'm just trying to say that using the sprintf() and mysql_real_escape_string() combo is not the whole cure for SQL injection. You still have to think.

(NogDog. I know you know this stuff. I just didn't want people doing a search on "SQL Injection" to find this thread and think they found a magic bullet.)

Ok. I'm done.

knowj

I find using either a switch or else statement usually works in that type of environment.

If the data entered is important it SHOULD BE handled by the server where it can be such as item prices within a store etc... at no point should the front end of the system come into contact with any form of input that contains the price which is a mistake that I see all to often in ajax systems where the developer doesn't understand the risks.

Where validation becomes more complex is with emails, names and addresses. They are an unbelievable amount of factors that can cause basic pattern matching to return false on what is essentially valid data.

Is a normal user going to realise they have to replace é from their name to e on an invalid name return because the developer is checking on ([a-z-]+) or something similar. I wouldn't class the above example as SQL injection though as the data is still in the form expected by the query.

In my opinion SQL injection is getting a query to perform a task different to its purposed implementation. The main thing I want to ensure I am protecting against is this type of attack and to do that you need to fully understand exactly what is from the client and what is from the server especially within the $_SERVER super global as there seems to be a combination of the two.

Are they any known exploits in which people have bypassed the mysql_real_escape_string's escape mechanism?

NogDog

Under the multi-layered approach to security, my typical layers consist of:

Trim and then validate all user inputs to be of the appropriate type, length, max values, etc. as applicable. Reject if invalid.
Cast numeric values to their database types.
Use prepared statements, or if stuck using an older DB interface build queries using sprintf() and the applicable place-holder types along with the applicable filtering mechanism for non-numeric values.
For critical applications, get another pair of eyes to do a code review.
Do negative testing and boundary conditions testing to make sure you didn't forget something.

laserlight

etully wrote:
If you wrote the customer's gender to a database and the hacker-customer passed in "3" for his gender, sprintf(%d) would not see any problem with the "3" and IT WOULD ALLOW HARMFUL DATA TO BE WRITTEN TO YOUR DATABASE.

... unless you have the appropriate constraints setup in the database. The SQL statement execution will then fail due to a constraint violation.