A short horror story about web app data leaks and how to prevent them

How to improve your database security

Beep-beep!

You hear the sound of an alarm clock. The first thing you see after you wake up is a notification. The entire user base of your WordPress* app has leaked into Darknet. According to GDPR, you’re both data controller and processor so now you’re facing a number of fines and court hearings. Not fun at all.

In the “bargaining” phase of Kübler-Ross grief coping stages, you’re going through the logs of your leaked web app, coffee in hand. The following is what you’re most likely to see.

Day 1: SQL Injections

SQL injection (SQLi) is one of the most common web attack mechanisms used by attackers to steal the data from a database. It is the #1 risk on the OWASP Top 10 Most Critical Web Application Security Risks.

SQLi happens when code injected into an SQL query pretends to be a normal part of the data and then is interpreted and executed as a command. SQLi are often used for stealing data or mis-configuring the system. The malicious commands can be hidden inside SQL, NoSQL, OS, and LDAP queries. Any source of data can be used for this kind of attack. An SQL injection commands list is essentially the same as a list of database commands, including with potentially catastrophic ones, like DROP TABLE.

How to tell if your web app is potentially vulnerable to an SQL injection? Your back-end can execute SQL queries.

Jokes aside, to start protecting your app against SQLi, you need to use:

• Automated SQL injection prevention tools (i.e. Sqlmap or jSQL Injection);
• Input validation / sanitation to ensure that the data is allowed, has the right format, and that query is allowed to access the specified table.
• Prepared statements and stored procedures.

Consider using web application firewall (WAF) or/and SQL firewall that helps filter out the malicious data. WAF works on the application level and SQL firewall works closer to the database (so it has more access to raw data).

Digging deeper into the differences between these firewall types, WAFs try to detect the known attacks or patterns of attacks and verify signatures on input (on the border of an application), filtering the requests on the network traffic level, so there are many ways to bypass a WAF firewall. One of the most popular WAFs is ModSecurity.

SQL firewalls have a number of advantages over a WAF firewall, but they are more complicated to use and there are not many (good) SQL firewalls. For instance, there is Oracle SQL firewall, which is strictly a part of the Oracle suite. If you look into open source — Acra database protection suite has a built-in SQL firewall (AcraCensor), which supports filtering SQL injections for PostgreSQL and MySQL.

Check out how SQL firewalls work in real-time in an open source OWASP-based demo.

Inspired by this information, you get down to work. After having fixed everything SQLi-related, you contently go to sleep.

Beep-beep!

The alarm clock wakes you up the next morning. The first thing you see is that your user base has leaked through your web app. Again. What could have gone wrong this time? You’ve fixed everything yesterday, right? You brew stronger coffee and get down to fixing stuff.

Day 2: Privileged database access

What allowed the attacker to get the privileged database access this time? The possible causes could be that you did something of the following:

• Kept the default login/password combination,
• Left public fields or tables in the database,
• Left public configuration files (like .env files) for anyone to tamper with,
• Left or hardcoded access credentials to your server or database.

Leaving default or even public access credentials is a typical mistake that leads to massive data leaks and even larger companies have been found guilty of it. According to the IoT search engine Shodan, misconfigured MongoDB databases totalling 24 TB of corporate data were exposing it for anyone to see at one point, one of the most notable MongoDB-related leaks being the exposure of 2Gb of personal data through unprotected databases in a popular babysitting app. A great number of Amazon Web Services (AWS) buckets left open on the Internet is another example of how you should never treat your databases.

Screenshot of an .env file left public in the root folder of a real functioning website. We haven’t checked, but we believe that these credentials are totally valid.

To avoid such obvious, but potentially catastrophic mistakes in your web app, make sure that you don’t have any hard-coded credentials in your code base. Using open source code scanning tools like clouseau can help you find the forgotten credentials in your repo and even git history.

Another precaution to take to discourage potential attackers is to change the default login and root password for your database, as well as change the default URL of admin page to something less obvious (i.e. from default “/admin” or “/root” to something like “/opensesame”).

A good idea is to check your app using dev-ops checklists to make sure that you haven’t forgotten to mark some vital data as private sensitive files. You may also want to look into these database hardening practices.

All done for today? Let’s hope so.

Beep-beep!

The alarm clock wakes you up. Another day and your app is still leaking sensitive data. Desperate, you ask yourself — what to do now? Same as yesterday — brew more coffee and fix more vulnerabilities in your web app.

Day 3: Forgotten backups, logs, SQL dumps

Letting the attackers grab some of the contents of your database because of exposed credentials is bad enough. Exposing your whole database (or its full backup) stored somewhere online in plaintext is a disaster.

“If someone finds a backup database file on your server,

it’s game over.”

However, many data leaks start with backups stored in plaintext and left forgotten somewhere on the server for anyone to take. This is a typical oversight. For instance, even WhatsApp used plaintext cloud backups — if Android users setup cloud backup, WhatsApp stored all their messages and attached files in Google Drive in plaintext. Another example is a now-defunct Canadian gadget retailer NCIX, which was caught storing unencrypted financial transactions’ data and credit card details of more than half a million people.

Logs are another place to look out for uncovered circulation of plaintext passwords. It may seem like a rookie mistake, but it still happened to Twitter and Apple’s macOS.

Often triggered through an SQL injection described in “Day 1”, SQL dump attack allows the malicious attacker to lay their hands on the contents of your database or its backup. And any leaked sensitive data information makes you an instant candidate for a GDPR-related lawsuit. Luckily, there are plenty of ready-made tools (i.e. Everything CLI and Mysqldump-secure) to encrypt your SQL dumps or you might write your own script using open source crypto-libraries.

Are there easy ways to fully secure your web app and its database & backups against these vulnerabilities? Yes and no. It’s more about having a consistent secure development flow: setting correct access policies, testing backups and their recovery, cleaning out old files. Protecting data is a process, not a one-time activity, and to make it more efficient we suggest to encrypt data files fully and take care of the keys.

We recommend using encryption, but using it wisely. First and foremost, don’t roll your own crypto, use reputable and reliable encryption tools. Also, resorting only to database-side encryption doesn’t really help because if the database is hacked/accessed, the data leaks. Application-side only encryption doesn’t help either because hacking web applications is even easier than hacking databases, and again — once hacked, encryption scheme might be changed and the data will leak.

The reliable modern way is to encrypt data on the web back-end side (in such a way that won’t allow web backed app decrypt the data) and transmit and store it in the database encrypted. To decrypt the data, a separate decryption proxy is necessary; it makes sure that the application has the permission to read this exact piece of data, provides protection from SQL injections, and decrypts the data.

If you are curious about trying out the modern way, you can jump right into the one-line engineering demo of Acra (open source data encryption suite). It illustrates that proxy is the single point of trust so the whole database can be leaked with no consequences because the contents of the database are securely encrypted and neither the app nor the database can decrypt it because they don’t have access to the decryption keys.

Feeling slightly overwhelmed, but much smarter, you’re drifting off to sleep, with a new-found inspiration to dig deeper into the exciting world of encryption the next day.

Beep-beep!

Suddenly you’re awakened by your alarm clock once again and realise that all the leaks and lawsuits were nothing but a bad dream. But all the vulnerabilities and problems are still out there. You make yourself a cup of coffee and get down to reading and taking care of all the problems in your web app’s security you are aware of now.

Afterword and recommended reading

The beginning steps are not the end of the story. In addition to the basic web app security principles outlined in this article, there is a lot you can learn and implement to keep the data safe.

Check your app’s infrastructure for known vulnerabilities — most of the web app breaches are caused by what is known and could have been totally avoidable with just a little care and attention.

Make sure you:

• Use secure configurations of the app components;
• Regularly check and test the compatibility of all the components, libraries, nested dependencies, DBMS, runtime environments, other 3rd party elements and if they are up to date & use secure APIs;
• Use tools to scan for vulnerabilities often (you can find some in the open source) and keep current with the recent vulnerability discoveries (at least those that are directly related to the platforms/components you are using), perform fixes and upgrades as necessary.
• Have implemented proper logging, monitoring, and tracing tools in place.

Take the necessary precautions to:

• Separate the data from the web application logic;
• Limit the possible data exposure in case of a successful SQL injection attack.

For starters, we strongly recommend thoughtfully reading:

• The OWASP Top 10 Most Critical Web Application Security Risks;
• OWASP SQL injection prevention cheat sheet;
• Wiki Web Application Security Guide/Checklist;
• 12+1 Ideas How to Ensure Backend Security;

Also, check out the proactive list of OWASP recommendations “OWASP Top 10 Proactive Controls 2018” to be on the bleeding edge of useable security principles.

Stay secure!

* We’ve used the WordPress example simply because it is a platform with a huge user base and an impressive number of known vulnerabilities and security issues. “27% of the Internet is powered by WordPress”. But other web platforms and apps can fail you in a similar way if you’re not taking the security very seriously.

If you have something to add on the web ass security basics or would like to share your story of success or mitigation after a web app data leak, please reach out to us via [email protected] or @cossacklabs. We’d love to hear from you!