MySQL Database configuration tips

Starting a remote service with the root user has been a security taboo because remote attackers are most likely to gain full control of the host if there is a problem with the service program. MySQL made a small change at the start of version 3.23.15, and the default installation service is to be started with the MySQL user and not allow the root user to start. If you want to start with the root user, you must add the--user=root parameter (./safe_mysqld--user=root &). Because MySQL has the load DATA infile and select ... into outfile SQL statement, if the root user started the MySQL server, then the database user has the root user write permission. However, MySQL has made some restrictions, such as the load DATA infile can only read the global readable files, SELECT ... into outfile cannot overwrite files that already exist.

Local log files cannot be ignored, including shell logs and MySQL own logs. Some users log on locally or back up the database in order to facilitate the map, sometimes in the command-line parameters directly with the password of the database, such as:

shell>/usr/local/mysql/bin/mysqldump -uroot -ptest test>test.sql
shell>/usr/local/mysql/bin/mysql -uroot -ptest

These commands are recorded in the history file by the shell, such as bash writing to the user directory's. bash_history file, and if the files are inadvertently read, the database password will leak. SQL commands executed after the user logs in to the database are also recorded in the user directory's. mysql_history file by MySQL. If a database user modifies the database password with an SQL statement, it is also compromised by the. mysql_history file. So we in the shell landing and backup when not directly after-p password, but in the prompt and then enter the database password.

In addition to these two files we should also not let it record our operation, just in case.

shell>rm .bash_history .mysql_history
shell>ln -s /dev/null .bash_history
shell>ln -s /dev/null .mysql_history

The two commands at the door link the two files to the/dev/null, so our operations will not be recorded in these two files. Programming need to pay attention to some of the problems: regardless of which program language to write the MySQL database program, there is a rule is never trust users to submit data!

For numeric fields, we use Query statements: SELECT * FROM table where id= ' 234 ' and do not use query statements such as SELECT * from table where id=234. MySQL automatically converts strings to numeric characters and goes away unless the number characters. If the user submits the data through the mysql_escape_string processing, so we can completely eliminate the SQL inject attack, about SQL inject attack please refer to the following link article:

http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
http://www.ngssoftware.com/papers/advanced_sql_injection.pdf

The issues to be noted in various programming languages:

1 All Web programs:

A try to enter single and double quotes in the Web form to test for possible errors and find out why.

b Modify the URL parameter band%22 (' "),%23 (' # '), and%27 ('").

C for the variables of the numeric field, our application must be rigorously checked, otherwise it is very dangerous.

D check whether the data submitted by the user exceeds the length of the field.

e do not give too much access to users of your program that connect to the database.

2) PHP:

A to check whether the data submitted by the user has been addslashes before the query, and provides a function mysql_escape_string () based on the MySQL C API after the PHP 4.0.3.

3 MySQL C API:

(a) Check whether the query string is invoked with the mysql_escape_string () API.

4) mysql++:

A the query string is checked for escape and quote processing.

5) Perl DBI:

A to check whether the query string uses the quote () method.

6) Java JDBC:

A to check whether the query string uses the PreparedStatement object.