Form security, php, mysql, utf8

Question

I'm making a registration form where some input goes into the DB and some not. My page uses utf8. For the data that doesn't goes into the db, I use this function(a sort of htmlspecialchars):

$c = array("'", '"', "/", "<", ">", "$", "%");
$s = str_replace($c, "", $s);

For the db I will use mysqli_real_escape_string. 2 questions by the security point of view and suppose I want to allow symbols and unicode(utf8).

1- For the data that doesnt goes in the db, is it enough the function above ?

2- For the data that goes in the db, is it enought mysqli_real_escape_string or should I use the function above too ? Or something else ?

Thanks.

Update1 Updated after bobince answer.

$c = array("'", '"', "/", "\\", "<", ">", "$", "%", "&");
$s = str_replace($c, "", $s);

Update2 So, to insert in the db I should use realescapestring or prepare. And then escape at every output, that depends on the Platform/Language.

2 Notes:

This way i have to escape many times instead of one, but there are some advantages too...

Php seems pretty strong against little hacks, look like it automatically escape some characters...

Answer 1

$c = array("'", '"', "/", "<", ">", "$", "%");

This string mangling is neither necessary nor sufficient to prevent injection issues into HTML (because ampersand) nor MySQL string literals (because backslash).

Injections are an output-escaping issue, not an input filtering issue. By trying to deal with them globally at the input stage you are making your application break for a wide range of valid input, without guaranteeing safe output for any data that comes in via other means.

To prevent SQL injection, mysqli_real_escape_string is fine, at the point you are building the query string. (Though parameterised queries are usually easier to get reliably correct.)

To prevent HTML injection, htmlspecialchars is fine, at the point you are writing strings into an HTML template. (Though a templating language that automatically HTML-escapes is desirable so you don't forget to do it sometimes.)

Other kinds of injection need their own special handling. For example if you are outputting into a URL query component you would need urlencode() and if you are outputting a value into JavaScript code you would want something like json_encode(). Again, this happens at the point you're creating the output for these things; you cannot handle this at the input filtering stage because you don't know what data is going to end up in what context.

Input filtering is a good idea for removing characters you know you're never going to want (eg control characters) and, on specific input fields, for enforcing business rules (eg what characters are valid in a username). But input filtering is absolutely not the place to be worrying about injection issues.

Answer 2

For the data that doesn't goes into the db, I use this function(a sort of htmlspecialchars):

For escaping output onto a web page, why not just use htmlspecialchars()? For example:

function noHTML(string $input): string
{
    return htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}

Good luck getting past that.

For the db I will use mysqli_real_escape_string.

Please don't. See this answer.

---

---

The one-minute solution to SQLi and XSS

• SQL Injection: Use prepared statements (without emulation!), don't bother escaping.
• Cross-site scripting:
  • Need formatted output (e.g. HTML)? HTMLPurifier or Stauros on output.
  • Otherwise, a function like noHTML() above will work wonders.
• Don't try to use a one-size-fits-all solution for both problems.

There's nothing more to it. These are solved problems.