One of the most prevalent issues that continue to vex application developers is weaknesses in database security that open us to exploit. Database security is a broad subject, and I will not cover all the security issues here but want to provide context and understanding around some of the more comment vulnerabilities. In this blog, I will highlight some key issues and provide references for your own study.
1. SQL Database
SQL Injection
When we talk about application security, SQL injection comes to mind immediately. This is unfortunate, in my opinion. I have mixed feelings about SQL injection. On one hand, SQL injection demonstrates how complicated and tedious a vulnerability exploitation task can be. On the other hand, SQL injection is a terrible example to demonstrate how complicated a vulnerable code can be remediated. It is very easy to fix the SQL injection vulnerability; all you need to do is to adopt the parameter binding technique. This misleads people to believe that all vulnerabilities are easy to remediate, which is totally wrong.
SQL injection has always been taught in the AppSec introduction courses. This doesn’t mean AppSec is all about SQL injection. The skill to exploit SQL injection vulnerability is not helpful in detecting other types of security vulnerabilities. For example, do you know how to exploit Remote Code Execution (RCE), inject a backdoor script on the victim’s server, and grab the password file? They all require different techniques.
Blind SQL injection
Blind SQL injection is a special category of SQL injection. It occurs when an application is vulnerable to SQL injection, but its HTTP response does not contain the results of the SQL query or the details of any database errors. Here is OWASP’s explanation of the subject: https://owasp.org/www-community/attacks/Blind_SQL_Injection. Exploiting blind SQL injection requires an additional step after performing SQL injection: you need to compare the injection results between two similar injections to make sure the injections have been executed successfully.
Tools
The number one tool to exploit SQL injection, including blind SQL injection, is sqlmap, which is an open-source application. Sqlmap has earned its reputation as the best tool for exploiting SQL injection. Many docker images for sqlmap are available. I am not sure which one is better.
Stored Cross-Site Scripting (XSS)
There are three types of XSS: reflective, DOM-based, and Stored (persistent). Stored XSS is the worst among all the XSS vulnerabilities because it is persistent. Many Web applications do not validate user input data (see the sidebar) and allow JavaScript snippets to get into the database. Whenever the injected data is retrieved by the application running on a browser, the browser executes the JavaScript snippet. Hence, the XSS happens. Are you sure your application blocks the following code snippet: <script>alert(1)</script>? Are you using a backlist approach or a whitelist approach to block the code? Another serious problem is any downstream application that uses the same database will have the same XSS vulnerability.
Miscellaneous Issues
Most of the databases (if not all) provide at least one way to invoke OS commands from within the database. Just like invoking OS commands directly from Java programs, invoking OS commands directly from within a database requires careful scrutiny. If you must invoke OS commands while inside the database, I recommend the following: (1) create a whitelist containing all the commands you are planning to use, (2) store the whitelist somewhere users cannot modify, (3) validate the commands against the whitelist before executing them.
Another potential vulnerability is allowing the full privileged access from remote databases. If the remote database is hacked, your database will be hacked too.
Many organizations store their database code into a code repository for the purpose of code review or CI/CD pipeline. Precaution is required for this process: user credentials may be embedded in the code and hence leaked to anyone who has the permission to read the code. One approach to hide the user credential in this scenario is to replace user credentials with some kind of variables, or encrypted user credentials. I usually search “IDENTIFIED BY” in the SQL code to locate this type of issue.
2. NoSQL Database
NoSQL Injection
The NoSQL databases have been in the market for years, and many good articles on exploiting NoSQL databases have been published. Please check out the OWASP’s discussion on the subject, especially the Whitepaper references at the bottom of the page: https://github.com/OWASP/wstg/blob/master/document/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection.md
If you are interested in the subject, check out the following URL which provides some good test cases for NoSQL injection: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection
Tools
There are a couple of open-source nosqlmap tools. I have tried a few. The quality of those nosqlmap tools is disappointing, in my opinion. The one that has been referenced most is https://github.com/codingo/NoSQLMap. Since they are all open sources, you may want to improve the code as a fun project.
Miscellaneous Issues
As mentioned above, invoking OS commands from inside a database can be dangerous. Think twice before doing it. For MongoDB, the run() command can be used to invoke OS commands.
3. Object-Relational Mapping (ORM)
You might think adding a layer of code to shield a database would improve the database security. Unfortunately, the opposite is true. It was reported last year that the set of characters \’’ (backslash, single quote, single quote) can escape from Hibernate Query Language (HQL) into MySQL context. You can then inject any MySQL statement to the database. The original report is probably this one: https://habr.com/ru/company/parallels/blog/272589/ (in Russian). A partial rewrite in English with code is here: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/hql-injection-exploitation-in-mysql/. Notes: the above Russian article also discusses how to escape into PostgreSQL, Oracle, and SQL Server.
4. Time-Series Database
A time-series database is a statistical database that collects time-series data, which can be useful for server metrics, application performance monitoring, network data, sensor data, events, incidents tracking, and many other types of analytics usage. Wikipedia has a list of time series databases on the market: https://en.wikipedia.org/wiki/Time_series_database.
Because time series databases are statistical databases, the traditional SQL injection does not seem to be useful. Injecting one or two rows of data has a neglectable impact on the statistics it generates. I do not have a good way to exploit the time-series databases. However, database security is not just about SQL. Weak system configuration settings can cause the database to be hacked too.
