...

View Full Version : Input Sanitization



q1h
01-13-2012, 03:03 AM
I've read a few things about attacks, and I'm wondering if what I'm using is sufficiently secure:


$string = mysql_real_escape_string( $_POST['string'] ); // do the escape
$string = substr($string,0,12); // limit the input to the needed amount of characters
$string = preg_replace("/[^A-Za-z0-9]/",'',$string); // filter out unwanted characters

Also, is it ok to just use converted data without escaping? Like:


$string = md5($_POST['string']);

// or

$string = strtotime( $_POST['string'] );

Thanks ...

felgall
01-13-2012, 03:35 AM
escaping is an output function that has nothing at all to do with security. You eacape HTML using htmlspecialchars() before writing it so as to make sure that any < and & in the text don't get misinterpreted as tags. You use mysql_real_escape_string() if you are using the old approach to referencing the database using query instead of prepare/bind so as to make sure that your data isn't confused with the query. Using prepare/bind is a better method because it keeps the query in the prepare and the data in the bind so that the data doesn't need to be escaped to be kept separate.

To sanitize fields in PHP you use the sanitiize filters at http://au2.php.net/manual/en/filter.filters.sanitize.php as your first choice of sanitization method [unless there is a specific function that will handle it for you such as is_numeric() ] and only use a regular expression for fields that it can't handle.

For your first example all you need is:

$string = preg_replace("/^([^A-Za-z0-9]){,12}$/",'', $_POST['string'] );

With your second example given that the functions you are calling return sanitized data there is no need for anything further to sanitize those values.

q1h
01-13-2012, 04:14 AM
felgall, thanks for the info ...

I thought that the danger was SQL injection when inserting user data INTO a database? Are you saying the danger is when their code is displayed?

Dormilich
01-13-2012, 06:50 AM
I thought that the danger was SQL injection when inserting user data INTO a database? Are you saying the danger is when their code is displayed?

the danger of SQL Injections is user data being interpreted as SQL Statement.
if you have for example SELECT * FROM mytable WHERE id = '$id'; then the content of $id is parsed as statement. if it's a value, then this is OK, if that'd be SQL code, it's SQL Injection ($id = "' or 1 = 1 --").

Prepared Statements on the other hand side treat SQL statements and data differently, because the SQL is parsed first and after that, data are added: SELECT * FROM mytable WHERE id = ?; there is no way for user data to be parsed as SQL Statements rendering SQL Injections useless (even if you used the code from above, the data are not evaluated as SQL)

(and another feature is that you don't have to concern yourself with whether the value needs to be quoted or not. that information (the data type) is passed in the data bind process)



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum