mysql_real_escape_string not working with genuine mysql injection I found

Now, obviously, I can't post the actual code that retrieves my admin login details, but the format of the code used is like this:

/webpage.php?id=79+and+1=-1+union+/*asd*/+select+1,2,3,password_details,5,6,7,8,9,10,11,12,13,14,15,16+from+databasename/**/.table+limit+0,1--

On the page that loads the string with a _GET I added this code at the top:

foreach ($_GET as $key => $value) {
     $_GET[$key] = mysql_real_escape_string($value);
}

But, when I eventually _GET("id"), it is no different than if I hadn't processed it with mysql_real_escape_string.

The page loads just fine and arrogantly displays my login details like a... well... like a massive c*nt.

How can I universally stop injections occurring?

If I use (int), it's fine, but there are many other queries else where on the site where I need to _GET  a string, for which the above injection code will get through despite mysql_real_escape_string.

Help, please.

* u

mysql_real_escape_string() just escapes quotes that could let someone break out of a quoted string.  Your query is probably assuming that id is an integer, and is using the value unquoted in that string.  Since it's not a string and not quoted, mysql_real_escape_string() won't do anything since you're already in a vulnerable part of the query and that injection string doesn't use any escapable characters.

To clean that up, make sure that id is an integer with intval().  Also, you could do a check/fail using filter_var() so you can log the hacking attempt and start blocking IP addresses or something.

mysql_real_escape_string, as it name indicates, is only effective at escaping string data being put into a query.

For numerical data, you must validate the data as being a number or more simply cast it as a number.

You also need to store your passwords using a 'salt' (nonsense string pre/appended to the actual password) and hashing them (md5 or sha). Storing passwords and other data as plain text is the same thing that just allowed Sony to loose all of their customer's information.

You can't treat all incoming data the same. It has to be validated and handled based on what the valid and/or invalid values are expected to be. A string needs to be handled differently than a numeric value.

The way to handle that properly is to validate that $_GET['id'] is numeric, and cast it as an integer before allowing it into the query string. You should also not put values that are expected to be numeric in quotes in the DB query string.

if( !ctype_digit($_GET['id']) ) {
     // there are non-valid characters in the variable, so throw an error.
     die( 'There has been a database error.');
} else {
     $id = (int) $_GET['id'];
}

Great, I think I've got it sorted!

I went through all the files, searched for every instance of _GET, _POST and _REQUEST, and depending on their data type (int or string) I have applied mysql_real_escape_string to strings, and (int) to ints.

I hope this will be enough to stop the same hacker from ever hacking again.

The last 2 days have been hell.

Cunt.

How can I encrypt my username and password when used in strings?

I think there is only 1 instance of this in my code.