Top 10 Database Security Issues to Avoid
Top 10 Database Security Issues
- Failure to scrub queries. Typically an issue with SQL based databases, the simplest but most common security issue is a simple failure to clean up SQL queries before they’re passed into the database. This single oversite is responsible for what is known as an SQL injection attack, where even novice hackers can simply submit a malformed query that can wreak havoc on the system. Simply adding a logic layer between incoming connections and the database that scans incoming queries and removes invalid requests such as “;DROP TABLE critical_table_name;” or similar.
- Inference. This is a tricky security issue that is often overlooked. What it means is the ability to ascertain secure information through queries of insecure or uncritical information. For example, a database that wishes to obscure the number of accounts with a certain privilege level may naively assign each account a unique, consecutive ID. By querying for every account that is accessible, the number of accounts that aren’t and even their unique ID’s can be inferred by the skips in the ID numbers.
- PEBKAC. This might be better suited to rank one, as it is the number one threat to database security. A completely valid user with critical privileges and a poor understanding of password security can jeopardize the entire database. This is amongst the hardest of security vulnerabilities to detect and regulate as even the savviest individuals will make mistakes and all that is required is one such oversight for the database to be compromised.
- Unnecessary Privileges. Similar to PEBKAC, simply handing users permissions they do not require is a major security risk that endangers critical data. User permissions must be tightly regulated to ensure database security.
- Unnecessarily Enabled Features. Most databases are designed with flexibility in mind, but that flexibility can serve as a vulnerability when features intended for different applications remain enabled in locations where they are not needed. By simply disabling all but the necessary features, a database can greatly improve its security.
- Not separating the web server from the database server. If your web server is ever compromised, you will be glad the database server is not bundled together with the site. By separating the web and database server(s); you can further restrict attacks, apply additional security precautions, and isolate potential data exposure / breaches. New attacks can arise at any time, dividing the two functions will better insulate your information and allow you to apply additional security measures specific to your application vs. the database.
- Unencrypted Data. If the data is sensitive, it should be encrypted, hashed, and salted so that if and when some other vulnerability leads to an intrusion, the data retrieved cannot be directly put to use.
- Buffer Overflows. Another form of invalid input, this form of attack involves sending the database more data than it can process in such a way that the extra “spills over” into other parts of the program, creating an illegitimate access point for any number of functions.
- Privilege Escalation. This form of attack requires the attacker to have intimate knowledge of the database back-end. Various exploits of specific database implementations can allow a user to escalate their privilege and gain access to functionality reserved for trusted clients or administrators. Keeping database software up to date is the only effective protection against these attacks.
- Overconfidence. Database security is a paranoid business. No security measure is watertight and everything should be scrutinized and held suspect by the administrators of the database. A database of any size or importance can and will come under attack, and only by taking caution at every step and never making assumptions about the in place security measures can a database hope to remain secure.