Page 1 of 1

mysql_real_escape_string question

Posted: Thu Apr 30, 2009 6:59 am
by Addos
I’m posting data from a Form in my search page to query my database on another page using:

Code: Select all

$therap = $_POST['me'];
$country = $_POST['you]; 
 
mysql_select_db($*, $**);
$query_rstResults = "SELECT * FROM blah
WHERE users = $country
AND type  = $therap " ;
To avoid a possible SQL attack should I use

Code: Select all

$therap = mysql_real_escape_string($_POST['me']);
$country = mysql_real_escape_string($_POST[‘you']);
Thanks for any advise.

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 7:04 am
by mattpointblank
Yes - any escaping is better than none, obviously. There are ways around mysql_real_escape_string however - it's worth using it in conjunction with other filters too - google SQL Injection Prevention for tips.

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 7:12 am
by requinix
mattpointblank wrote:There are ways around mysql_real_escape_string however
You've piqued my curiosity. Any examples of this?

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 10:15 am
by Addos
Thanks a mil
:wink:

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 11:17 am
by mattpointblank
tasairis wrote:
mattpointblank wrote:There are ways around mysql_real_escape_string however
You've piqued my curiosity. Any examples of this?
From this page (http://www.webappsec.org/projects/articles/091007.shtml)

Code: Select all

 
$userid = isset($_GET['id']) ? $_GET['id'] : 0;
$userid = mysql_real_escape_string($userid);
RunQuery("SELECT userid, username FROM sql_injection_test 
    WHERE userid=$userid");
---------[ Tests: ]------------------------------
1. id=0
2. id=1
3. id=2
4. id=3
5. id='
6. id=0 or 1
7. id=0 UNION ALL SELECT userid, CONCAT(username, ' ', password) 
    FROM sql_injection_test WHERE 1
8. id=0 UNION ALL SELECT userid, CONCAT(username, CHAR(32), password) 
    FROM sql_injection_test WHERE 1
 
 
Tests 6 and 8 work.

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 1:59 pm
by requinix
Well yeah. Duh. mysql_real_escape_string is for strings, not numbers.

If you shove "a number" through it and expect to get a number back, you're wrong.

Re: mysql_real_escape_string question

Posted: Thu Apr 30, 2009 2:21 pm
by Christopher
tasairis wrote:Well yeah. Duh. mysql_real_escape_string is for strings, not numbers.

If you shove "a number" through it and expect to get a number back, you're wrong.
I think you misunderstand mysql_real_escape_string(). It works on strings containing numbers, letters and symbols. What it does is escape any values that would cause problems within quotes in MySQL. It does not in itself work against all injection attacks. You would need to check that unquoted values only contain numbers separately.

Re: mysql_real_escape_string question

Posted: Fri May 01, 2009 6:00 am
by mattpointblank
tasairis wrote:Well yeah. Duh. mysql_real_escape_string is for strings, not numbers.

If you shove "a number" through it and expect to get a number back, you're wrong.
My point was that blindly applying mysql_real_escape_string to anything going into a query isn't going to save you from all injection attacks. A lot of articles and forum discussions just tell people to wrap any user input with it and then everything will be fine - not true, as we've seen.

Re: mysql_real_escape_string question

Posted: Fri May 01, 2009 7:12 am
by requinix
arborint wrote:I think you misunderstand mysql_real_escape_string(). It works on strings containing numbers, letters and symbols. What it does is escape any values that would cause problems within quotes in MySQL. It does not in itself work against all injection attacks. You would need to check that unquoted values only contain numbers separately.
Right. I understand it fine - security in applications is my strong point. By "strings" and "numbers" I'm talking about data types in a more abstract sense.

The mentality is that mysql_real_escape_string makes all input safe but it doesn't: it only works for strings. Once you start treating data as numbers you get problems.
If you want to make a number safe then it's easier to use another function, like is_numeric, intval, or ctype_digit. Two different types of data, two separate ways of making them safe.