I am currently building a query where both the field/column and value parts possibly consist of user inputted data.
The problem is escaping the fieldnames.
I'm using prepared statements in order to properly escape and quote the values but when escaping the fieldnames i run into trouble.
The ANSI standard way of doing a delimited identifier is:
SELECT "field1" ...
and if there's a " in the name, double it:
SELECT "some""thing" ...
Unfortunately this doesn't work in MySQL with the default settings, because MySQL prefers to think double quotes are an alternative to single quotes for string literals. In this case you have to use backticks (as outlined by Björn) and backslash-escaping.
To do backslash escaping correctly, you would need mysql_real_escape_string, because it's character-set-dependent. But the point is moot, because neither mysql_real_escape_string nor addslashes escape the backquote character. If you can be sure there will never be non-ASCII characters in the column names you can get away with just manually backslash-escaping the ` and \ characters.
Either way, this isn't compatible with other databases. You can tell MySQL to allow the ANSI syntax by setting the config option ANSI_QUOTES. Similarly, SQL Server also chokes on double quotes by default; it uses yet another syntax, namely square brackets. Again, you can configure it to support the ANSI syntax with the ‘quoted_identifier’ option.
Summary: if you only need MySQL compatibility:
a. use backquotes and disallow the backquote, backslash and nul character in names because escaping them is unreliable
If you need cross-DBMS compatibility, either:
b. use double quotes and require MySQL/SQL-Server users to change the configuration appropriately. Disallow double-quote characters in the name (as Oracle can't handle them even escaped). Or,
c. have a setting for MySQL vs SQL Server vs Others, and produce either the backquote, square bracket, or double-quote syntax depending on that. Disallow both double-quotes and backslash/backquote/nul.
This is something you'd hope the data access layer would have a function for, but PDO doesn't.
Summary of the summary: arbitrary column names are a problem, best avoided if you can help it.
Summary of the summary of the summary: gnnnnnnnnnnnh.