Question

I’m developing an application using WordPress as a CMS.

I have a form with a lot of input fields which needs to be sanitized before stored in the database.
I want to prevent SQL injection, having javascript and PHP code injected and other harmful code.

Currently I’m using my own methods to sanitize data, but I feel that it might be better to use the functions which WP uses.

I have looked at Data Validation in WordPress, but I’m unsure on how much of these functions I should use, and in what order. Can anyone tell what WP functions are best to use?

Currently I’m “sanitizing” my input by doing the following:

1. Because characters with accents (é, ô, æ, ø, å) got stored in a funny way in the Database (even though my tables are set to ENGINE=InnoDB, DEFAULT CHARSET=utf8 and COLLATE=utf8_danish_ci), I’m now converting input fields that can have accents, using htmlentities().

2. When creating the SQL string to input the data, I use mysql_real_escape_string().

I don’t think this is enough to prevent attacks though. So suggestions to improvement is greatly appreciated.

Answer 1

Input “sanitisation” is bogus.

You shouldn’t attempt to protect yourself from injection woes by filtering(*) or escaping input, you should work with raw strings until the time you put them into another context. At that point you need the correct escaping function for that context, which is mysql_real_escape_string for MySQL queries and htmlspecialchars for HTML output.

(WordPress adds its own escaping functions like esc_html, which are in principle no different.)

(*: well, except for application-specific requirements, like checking an e-mail address is really an e-mail address, ensuring a password is reasonable, and so on. There’s also a reasonable argument for filtering out control characters at the input stage, though this is rarely actually done.)

I’m now converting input fields that can have accents, using htmlentities().

I strongly advise not doing that. Your database should contain raw text; you make it much harder to do database operations on the columns if you’ve encoded it as HTML. You’re escaping characters such as < and " at the same time as non-ASCII characters too. When you get data from the database and use it for some other reason than copying it into the page, you’ve now got spurious HTML-escapes in the data. Don’t HTML-escape until the final moment you’re writing text to the page.

If you are having trouble getting non-ASCII characters into the database, that’s a different problem which you should solve first instead of going for unsustainable workarounds like storing HTML-encoded data. There are a number of posts here all about getting PHP and databases to talk proper UTF-8, but the main thing is to make sure your HTML output pages themselves are correctly served as UTF-8 using the Content-Type header/meta. Then check your MySQL connection is set to UTF-8, eg using mysql_set_charset().

When creating the SQL string to input the data, I use mysql_real_escape_string().

Yes, that’s correct. As long as you do this you are not vulnerable to SQL injection. You might be vulnerabile to HTML-injection (causing XSS) if you are HTML-escaping at the database end instead of the template output end. Because any string that hasn’t gone through the database (eg. fetched directly from $_GET) won’t have been HTML-escaped.