Database Security

1. Database Security Jordan Coderre CMPT320_01

2. Why Database Security? • Databases are an essential part of almost every modern website. • Their importance in modern web design combined with the potential for holding sensitive information make them commonly target systems. • “What issues are facing databases today and what are some general guidelines one should follow to prevent the exploitation of vulnerabilities and maintain a healthy system?”

3. Database System Architectures • To understand what must be secured we need to look at how networks with databases are commonly built. • There are three common architectures: • Single machine database system • Client/Server (two-tier) • Three-tier architecture

4. Two-Tier Architecture • Two-tier architectures are usually based upon clients directly communicating with the DBMS directly through a network connection. • The DBMS processes queries, interacts with the database and returns information to the client. • Two-tier architectures include interaction via a web server.

5. Three-Tier Architecture • Three-tier architectures contain an application server (middleware). • The middleware houses the business logic and is responsible for doing the calculations that return the client’s view of the data. • Three-tier architectures are more scalable and found in networks with a larger demand on the DBMS.

6. Mission & Breakdown • I looked to follow the core principals of information security in the CIA triad. • We will cover: • Physical security of database components • Client workstation security • Database software configuration & updates • Account privileges • Database firewalls

7. Physical Security of Database System Components • Disallowing physical access to essential systems • Alarm system • Security of server room • Protection from environmental hazards • Implementing a backup system • Encrypt! • Battery backup to ensure proper shutdown • Uninterruptible power supply (UPS) • Foundation of room housing the servers • Proper climate & environment

8. Client Workstation Security • Anti-virus application • Frequently updated definitions • Automatic OS & application updates • Implement central deployment system such as Secunia & SUS • Automatic logout after set interval of inactivity • User education on proper computer usage • Communication encryption (SSL/TLS) • Protection from eavesdropping & packet manipulation • Digital signaturesfor authenticity

9. Database Software Updates & Configuration • Exploits are constantly being found and released to the public. • Maintaining up to date software on the DBMS (and possibly web server) is crucial. • Sony Online Entertainment’s customer record database was compromised in 2011 due to an unpatched version of Apache.

10. Database Software Updates & Configuration • Default settings must be changed to suit the needs of the DBMS. (RTFM!) • For example, Oracle databases have preconfigured security settings that can be enabled through the included ‘Database Configuration Assistant’. Enables monitoring of specified DB components Protects ‘SYS’ tables Login protection measures Allows OS to set roles

11. Setting Privileges • Privileges are the right to execute a specified type of SQL statement or access another user’s objects. • A MySQL database allows you to designate a specific user’s access to commands like insert, drop, delete & more.

13. Setting Privileges • Example of a SQL command granting privileges to all columns in a given table: • GRANT SELECT, INSERT ON mydb.mytbl TO 'someuser'@'somehost'; • Privileges are more often assigned to roles than specific users. • The SIFMA report on database vulnerabilities lists excessive user & group privileges as the 3rd biggest threat against databases.

14. Database Firewalls • Database firewalls can be used to monitor queries, prevent SQL injections and prevent inferences. • Can be configured to ‘cleanse’ queries (substituting queries matching a criteria with a pre-set statement) • Can be used to track user behavior and use this to prevent insider attacks. • In a U.S. Secret Service/CERT/Microsoft E-Crime report, insider attacks constitute 34% of all surveyed attacks, with outsiders contributing 37% and the last 27% originating from unknown sources.

15. Database Firewalls • Database firewalls can utilize a blacklist or whitelist approach. • Offers an extra layer of protection on top of measures implemented into the coding of the application.

16. Vulnerabilities • Considering these protective measures I’ve discussed, what are some common vulnerabilities that are affecting databases? • OWASP and SIFMA provide a good list of common exploits, but I will only cover two: • Default user accounts & weak passwords • SQL injection

17. Default User Accounts & Weak Passwords • SIFMA cites weak passwords & failure to change or remove default accounts the biggest threat to databases. • Minimum password length & complexity policies should be set in place. • Needs to avoid brute forcing & rainbow table attacks • Files or tables containing any login information for the network should be encrypted.

18. Default User Accounts & Weak Passwords • Some DBMS may have factory accounts disabled by default but some do not. • Earlier versions of Oracle database had accounts like ‘HR’, ‘OE’ and ‘SCOTT’ with considerable privileges used for testing purposes. • Check for default accounts regardless of whether or not you believe they are already disabled • Oracle databases allow you to log into SQL*Plus using the SYSDBA privilege. You can then query ‘DBA_USERS_WITH_DEFPWD’ to see which accounts have the default password. • MariaDB allows you to invoke ‘mysql_secure_connection’ from a shell prompt and will prompt you through several actions to secure your default accounts.

19. SQL Injections • Injections are considered the biggest security threat according to OWASP’s Top 10 from 2013 and the 2nd biggest from SIFMA’s report. • The first discussions of SQL injections arose in 1998 and yet they still remain a major vulnerability. • In 2005 a SQL injection attack on MasterCard leaked 40 million credit card details.

20. SQL Injections • The vulnerability lies in how the application interacting with the DBMS is coded. • In the situation where a store uses the following URL to view products less than $100: • http://www.victim.com/products.php?val=100 • You could modify the end of the URL to view all products: • http://www.victim.com/products.php?val=100’ OR ‘1’=‘1

21. SQL Injection Prevention • There are several ways you can prevent this aside from the utilization of a database firewall. • Parameterized Statements • Input Validation • Canonicalization • Parameterized statements work by forcing a query to interact with prepared statements before sending the query to the database. • $con = new mysql(“localhost”, “username”, “password”, “db”); • $sql = “SELECT * FROM users WHERE username=? AND password=?”; • $cmd = $con->prepare($sql); • $cmd->bind_param(“ss”, $username, $password); • // Adds parameters to SQL query and binds parameters as strings • $cmd->execute(); • // Takes the newly prepared statement and executes it on the database.

22. SQL Injection Prevention • Input Validation • Testing of the input received by an application for compliance against a standard defined within the application. • Can be approached by cleansing input with regular expressions. • Common method of validating a U.S. zip code: • ^\d{5} (-\d{4})?$ • Canonicalization • Ensuring certain characters are not allowed to be inputted and that the user cannot use different encodings to sneak in the disallowed characters. • %27 is the URL-encoded representation of a single-quote character.