MySQL server security
-
Upload
damien-seguy- -
Category
Business
-
view
3.772 -
download
2
description
Transcript of MySQL server security
MySQL SecurityWashington DC, USA
November 8th, 2007
Agenda
Why is security important?
Privileges management
Configuration directives
MySQL security on the Web
Next challenge for security
Who is speaking?
Damien Séguy
LAMP expert services at NexenServices.com
'Sécurité PHP 5 et MySQL' with Philippe Gamache at Eyrolles
http://www.nexen.net/
Common fears
Root overtake
Data erasing
Denial of service
Data modification
Data publication
Plain shame....
Default privileges
Root account, no password
Always ADD A password
Renaming root to 'chef'?
Users and test bases
Users without password
Users without IP restrictions
Anonymous users
User table sanity checksAnonymous users
SELECT count(*) FROM users WHERE user='';
Avoid % in addresses
SELECT count(*) FROM users WHERE host LIKE '%\%%';
Alwas have a password
SELECT count(*) FROM users WHERE password='';
The FILE privilege
Export data to file
Import data to file
Import data from the client
The GRANT privilege
Share your privileges
Privilege escalation
Complement by exchanging rights with other users
Configuration directives
--skip-grant-tables
--old-password
--secure-auth
--skip-show-databases
Configuration directives (2)
--port=3306
--skip-networking
--bind-address
--skip-name-resolve
--skip-symbolic-links
Configuration directives (3)
--local-infile=0
--secure-file-priv
--chroot
--open-files-limit
--safe-user-create
--allow-suspicous-udf
Client configuration directives
--secure-auth
--safe-updates
also called : --i-am-a-dummy
--select_limit=1000
--max_join_size
Resource consuming
+-----------------------+------+| Field | Null |+-----------------------+------+| max_questions | NO || max_updates | NO || max_connections | NO || max_user_connections | NO |+-----------------------+------+
In the User table
Max_connections
Max_user_connections
Max_questions
Max_updates
Inactive by default
Valid for an hour
SQL injectionsDynamic build of the SQL query
$requete = "SELECT COUNT(*) FROM users WHERE login='".$_GET['login']."' AND motdepasse='".$_GET['password']."' ";
Mixing data and instructions
It is always possible to escape this quoting, and make the query do other things
Injections patternsWHERE clause removal
WHERE login = '' or 1 or ''
Subqueries
WHERE id=(SELECT BENCHMARK(md5(1),1000));
UNION
WHERE id=1 UNION SELECT * FROM table;
Multiple insertions
VALUES ('login'),('admin');
MySQL special chars
' and " : string delimiters
() : sub queries
% and _ : regex with LIKE
REGEXP
; \g \G : end of command
--, # et /* .... */ comment
Protecting against injectionsProtecting special characters
with PHP : use mysqli_real_escape_string() AND delimiters
$sql = "SELECT * FROM table WHERE id = '".mysqli_real_escape_string($mid, $_GET['id'])."'";
The case of integers : force the type before building the query
ProtectionsPrepared queries
Prepare the command execution
Affect variables
Execute the command
/* Preparing command execution */$query = "INSERT INTO cities (Name, Country, Region) VALUES (?,?,?)";$stmt = $mysqli->prepare($query);
$val1 = 'Washington';$val2 = 'USA';$val3 = 'DC';
$stmt->bind_param("sss", $val1, $val2, $val3);
/* Commande execution */$stmt->execute();
$val1 = 'Montréal';$val2 = 'CAN';$val3 = 'Québec';
/* Commande execution */$stmt->execute();
/* Free resources */$stmt->close();
Other protectionsStored procedures
MySQL variables
Easier to read and secure
$sql = "CALL my_proc('".$_GET['id']."');
$sql = "SET @id := '".$_GET['id']."'";mysqli_query($mid, $sql);$sql = "SELECT * FROM table WHERE id = @id"; mysqli_query($mid, $sql);
Injections are still possibles!!, just limited
Hidden entrances
MySQL logs (binary, slow, general)
SHOW PROCESSLIST
SHOW CREATE TABLE
Data folder
Backup systems (media, fichiers)
Replication slaves
Clients (history, network comm...)
Be preparedDelete unused data
Crypt data
Passwords, writeable but not readable
Poison your data
Audit critical data
Back up
Database security standards?
Sarbanes-Oxley, SOX
Health Insurance Portability and Accountability Act (HIPAA)
Payment Card Industry
Gramm-Leachy Bliley Act
SB 1386
BASEL II
Common vulnerabilities1)Insufficient security tests
2)Mediocre configuration
3)No encryption of critical data
4)No update processus
5)Security is called when a disaster strikes
6)No monitoring
7)Insufficient control over third parties access
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10.Track and monitor all access to network resources and cardholder data
11.Regularly test security systems and processes
12.Maintain a policy that addresses information security
Norme PCI