Easy Question

[atholon]

So, I've been using stripslashes and mysql_real_escape_string for input into mysql. Is that necessary or can I do it just when I retrieve info from Mysql?

 

When getting info from mysql I am using HtmlEntities...

 

What is the best way to make sure that user entry will not be php or sql code or break the script?

[discomatt]

To the db -> stripslashes (if necessary), mysql_real_escape_string

From the db -> htmlentites

 

You've got it right.

[.josh]

There's no reason you should be having to sanitize data coming out of your database...

 

The "best" way to keep from being a victim of sql injection is to not put user inputed values into your database at all.  You know what they say, abstinence is the best policy   But of course, that is not an option in many many cases. 

 

The next "best" thing is to make a white list of acceptable input, if at all possible.  Example:

 

$whitelist = array('a','b','c');
if (in_array($_POST['blah'], $whitelist)) {
   // info is good
} else {
   // info is bad
}

 

Failing that, mysql_real_escape_string is good for adding slashes to attempts to use quotes to escape and add extra sql code.  Therefore it's not necessary to stripslashes before mysql_real_escape_string, and you certainly shouldn't stripslashes after using it.  Just use mysql_real_escape_string by itself.

 

[Guest Xanza]

Crayon - with the script you put up:

 

<?php
$whitelist = array('a','b','c');
if (in_array($_POST['blah'], $whitelist)) {
   // info is good
} else {
   // info is bad
}
?>

 

Would all information placed under the else be considered bad and blocked, or can you just leave it blank, and have everything not on the white list blocked?

[rmbarnes82]

Hi,

 

The general rule of thumb is filter input, escape output.

 

What you are doing sounds right.

 

1. Turn off gpc_magic_quotes

2. Use mysql_real_escape_string on all variables which are added to MySQL queries (note that addslashes may *not* be effective. I've heard that people can use hex codes to inject stuff into your DB, addslashes won't stop this).

3. Use htmlentities on all output which has come from the user which is not meant to display as html (if you have a cms system you may want to display user input as html). This isn't just stuff out of the database. Take a search box. Most sites have a search box, and after the user has searched the results page displays the search term, eg 'You searched for "xxx"'. This search term never gets saved in the DB, but people can type JavaScript into the search box to create an iframe (which could show a competitors website). Not a major risk but can make you look quite amateur.

 

Robin

[.josh]

Crayon - with the script you put up:

 

<?php
$whitelist = array('a','b','c');
if (in_array($_POST['blah'], $whitelist)) {
   // info is good
} else {
   // info is bad
}
?>

 

Would all information placed under the else be considered bad and blocked, or can you just leave it blank, and have everything not on the white list blocked?

 

The if..else is just an example to show that if the condition is true, the value is on the whitelist and is safe.  If the condition is false, then the value is not on the whitelist. Is it necessarily a sql injection attempt? Maybe, maybe not.  But it's not on your list of acceptable values, which is all that matters.  You can do anything you want to if it's not on the whitelist.  You can throw an error message, assign a default value, log the error, all of the above, none of the above.  Choice is up to you. 

[atholon]

The reason I do htmlentities on retrieval is because I may have to clip the string...if you do that with an HTML code it will look all jacked up.

 

 

So I clip it first and then run html entities.

[discomatt]

 

Failing that, mysql_real_escape_string is good for adding slashes to attempts to use quotes to escape and add extra sql code.  Therefore it's not necessary to stripslashes before mysql_real_escape_string, and you certainly shouldn't stripslashes after using it.  Just use mysql_real_escape_string by itself.

 

 

With magic_quotes on, you want to stripslashes prior to mysql_real_escape... hence the ( if necessary )

[.josh]

 

Failing that, mysql_real_escape_string is good for adding slashes to attempts to use quotes to escape and add extra sql code.  Therefore it's not necessary to stripslashes before mysql_real_escape_string, and you certainly shouldn't stripslashes after using it.  Just use mysql_real_escape_string by itself.

 

 

With magic_quotes on, you want to stripslashes prior to mysql_real_escape... hence the ( if necessary )

 

Ah true true.

[atholon]

Isn`t magic_quotes disabled in PHP 5? or will be in version 6?

[atholon]

function sqlSecure($iString)
{ 
    $iString = isset($iString) ? stripslashes($iString): '';
    $iString = mysql_real_escape_string($iString);
    $iString = HTMLize($iString);
    return $iString; 
}


function str_short($key,$len) { 
    if(strlen($key)>intval($len)) 
    {
      $key=HTMLize($key);
    	$key=htmlentities($key);
      return(substr($key,0,($len-3))."..."); 
    } 
    return($key); 
}

[atholon]

Oops, should be like this

 

function str_short($key,$len) { 
    if(strlen($key)>intval($len)) 
    {
      $key=(substr($key,0,($len-3))."...");  
    }    
      $key=HTMLize($key);
    	$key=htmlentities($key);
    return($key); 
}