Jump to content

filtering data


Destramic

Recommended Posts

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.

Link to comment
Share on other sites

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()

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.