filtering data

[Destramic]

hey guys i was generally wondering...is it good practice to add_slashes and use mysqli_real_escape_string when entering data into the database?

 

then to strip slashes when extracting rows?

 

is this the right way to go around things...thanks

 

 

[requinix]

addslashes() no, stripslashes() no, mysqli_real_escape_string() only if you can't use prepared statements instead. Which you can (mysqli provides that functionality). So no to that one too.

[teynon]

Destramic,

 

   To further discuss this topic as requinix has stated, the reason you want to use prepared statements is that you prevent sql injection because the values being entered are not parsed. That is to say that if you had an SQL query like this:

INSERT INTO myTable ({$myValue1}, 'monkeys')

You have to worry about the quotes. You have to apply those functions because if you don't it's pretty easy for a user to attack your database. Now it's been about a year since I've done any PHP, but if I remember correctly, a user can send a certain character code that will turn into a quote and get around the stripslashes, etc. (I may be wrong or it may have been patched, I'm not sure.) Regardless, if you were to use a prepared statement, you don't have to worry about quotes at all. So for example:

INSERT INTO myTable (?, 'monkeys')

You can then call the query by passing the value. This sends the initial query to the database and then in a separate request, sends the parameters. So instead of parsing the values, it can simply insert them directly.

[Jacques1]

The reason why addslashes() doesn't work is because it doesn't take the character encoding of the input string into account. It assumes that every string is ASCII-encoded, which is of course nonsense. If you apply addslashes() to a non-ASCII string, pretty much anything can happen: The function may cease to work, or it may damage the input, or it may actually yield the correct result. You never know. That's definitely the last thing you want when you're trying to protect your database.

 

mysqli_real_escape_string() does take the encoding into account, so it theoretically works. However, it's extremely fragile:

• You must never forget to escape a value.
• You must always wrap the escaped string in quotes.
• You must not mess with the character encoding. For example, a simple SET NAMES query can break the function entirely.

History has shown that the average programmer simply cannot do this. People forget to escape their stuff all the time, or they only escape the values which they find “dangerous” (this never works), or they forget the quotes, or they screw up the encoding. Pick any applications, and you'll probably find dozens of SQL injection vulnerabilities.

 

So we need a more robust solution which doesn't require perfect programmers. And that's where prepared statements come into play.

 

stripslashes() is a brainfart from the early days of PHP. It tries to solve the problem of cross-site scripting by simply killing anything which looks like HTML markup. Chances are it will destroy your entire input and leave you with a bunch of garbage data. And it doesn't even work for attributes. So strike this garbage from your memory.

 

Cross-site scripting is an output problem, not an input problem. You cannot solve it by removing “evil data” from the user input (whatever that means). Instead, you have to escape the value when you generate the output. And this is done with htmlspecialchars(). 

[Destramic]

thank you guys for your input so in essence dont use add/strip_slashes and mysqli_real_esapce_string() but with every input ($_POST from user i should use

htmlspecialchars() ?

 

thank you agian

[Jacques1]

Whenever you have to pass a dynamic value to a query, either use a prepared statement or mysqli_escape_string(). Whenever you have to output a dynamic value on your site, use htmlspecialchars().

 

It doesn't matter whether or not the value comes from the user. Escape all values unless they're hard-coded. Don't even try to distinguish between “safe” values and “dangerous” values. This is extremely risky, it's a waste of time, and it doesn't make sense. Even if a value is “safe” in the sense that it doesn't come from the user, it may very well cause a syntax error when you insert it into a query without prior escaping. So don't do that.

 

When you use htmlspecialchars(), make sure to specify the character encoding and set the ENT_QUOTES flag:

htmlspecialchars($input, ENT_QUOTES, 'UTF-8');

The character encoding must match the encoding of your HTML document.

[Destramic]

lovely...thank you for your help