Client Programming Security Guidelines - Oracle 5.0 Reference Manual

6.1.7. Client Programming Security Guidelines

Applications that access MySQL should not trust any data entered by users, who can try to trick your
code by entering special or escaped character sequences in Web forms, URLs, or whatever application
you have built. Be sure that your application remains secure if a user enters something like
DATABASE
as a result of hackers using similar techniques, if you do not prepare for them.
A common mistake is to protect only string data values. Remember to check numeric data as well. If an
application generates a query such as
the value 234, the user can enter the value
query
SELECT * FROM table WHERE ID=234 OR
in the table. This exposes every row and causes excessive server load. The simplest way to protect
from this type of attack is to use single quotation marks around the numeric constants:
FROM table WHERE
In a numeric context, MySQL automatically converts this string to a number and strips any trailing
nonnumeric characters from it.
Sometimes people think that if a database contains only publicly available data, it need not be
protected. This is incorrect. Even if it is permissible to display any row in the database, you should still
protect against denial of service attacks (for example, those that are based on the technique in the
preceding paragraph that causes the server to waste resources). Otherwise, your server becomes
unresponsive to legitimate users.
Checklist:
• Enable strict SQL mode to tell the server to be more restrictive of what data values it accepts. See
Section 5.1.7, "Server SQL
• Try to enter single and double quotation marks ("'" and """) in all of your Web forms. If you get any
kind of MySQL error, investigate the problem right away.
• Try to modify dynamic URLs by adding
• Try to modify data types in dynamic URLs from numeric to character types using the characters
shown in the previous examples. Your application should be safe against these and similar attacks.
• Try to enter characters, spaces, and special symbols rather than numbers in numeric fields. Your
application should remove them before passing them to MySQL or else generate an error. Passing
unchecked values to MySQL is very dangerous!
• Check the size of data before passing it to MySQL.
• Have your application connect to the database using a user name different from the one you use for
administrative purposes. Do not give your applications any access privileges they do not need.
Many application programming interfaces provide a means of escaping special characters in data
values. Properly used, this prevents application users from entering values that cause the application to
generate statements that have a different effect than you intend:
• MySQL C API: Use the
• MySQL++: Use the
• PHP: Use either the
The preferred API's support the improved MySQL authentication protocol and passwords, as well as
prepared statements with placeholders. See also
If the older
mysql_real_escape_string()
because only
"bypassed" when using (invalid) multi-byte character sets.

Client Programming Security Guidelines

mysql;". This is an extreme example, but large security leaks and data loss might occur
ID='234'. If the user enters extra information, it all becomes part of the string.
Modes".
mysql_real_escape_string()
and
escape
or
mysqli pdo_mysql
extension must be used, then for escaping use the
ext/mysql
mysql_real_escape_string()
SELECT * FROM table WHERE ID=234
234 OR 1=1
1=1. As a result, the server retrieves every row
("""), ("#"), and
%22 %23
modifiers for query streams.
quote
extensions, and not the older
Section 20.7.1.3, "Choosing an
function and not
mysql_escape_string()
is character set-aware; the other functions can be
573
to cause the application to generate the
("'") to them.
%27
API call.
ext/mysql
"; DROP
when a user enters
SELECT *
extension.
API".
or
addslashes()