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 , you’re both so now you’re facing a number of fines and court hearings. Not fun at all. GDPR data controller and processor 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 used by attackers to steal the data from a database. It is the #1 risk on the Most Critical Web Application Security Risks. one of the most common web attack mechanisms OWASP Top 10 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. or ); Sqlmap 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 , which is strictly a part of the Oracle suite. If you look into open source — has a , which supports filtering SQL injections for PostgreSQL and MySQL. Oracle SQL firewall Acra database protection suite built-in SQL firewall (AcraCensor) 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 , misconfigured MongoDB databases totalling of corporate data were exposing it for anyone to see at one point, one of the most notable MongoDB-related leaks being the through unprotected databases in a popular babysitting app. A great number of is another example of how you should never treat your databases. IoT search engine Shodan 24 TB exposure of 2Gb of personal data Amazon Web Services (AWS) buckets left open on the Internet 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 can help you find the forgotten credentials in your repo and even git history. clouseau Another precaution to take to discourage potential attackers is to and for your database, as well as change the default URL of admin page to something less obvious (i.e. from default “ ” or “ ” to something like “ ”). change the default login root password /admin /root /opensesame A good idea is to check your app using 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 . dev-ops checklists 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 and left forgotten somewhere on the server for anyone to take. This is a typical oversight. For instance, even — 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 which was caught storing unencrypted financial transactions’ data and credit card details of more than half a million people. backups stored in plaintext WhatsApp used plaintext cloud backups Canadian gadget retailer NCIX, are another place to look out for uncovered circulation of plaintext passwords. It may seem like a rookie mistake, but it still and . Logs happened to Twitter Apple’s macOS Often triggered through an SQL injection described in “Day 1”, allows the malicious attacker to lay their hands on the contents of your database or its backup. And any makes you an instant candidate for a GDPR-related lawsuit. Luckily, there are plenty of ready-made tools (i.e. and ) to encrypt your or you might write your own script using . SQL dump attack leaked sensitive data information Everything CLI Mysqldump-secure SQL dumps 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 . 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. encryption tools 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 of (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. one-line engineering demo Acra 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 ) 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. some in the open source Have implemented proper , and tools in place. logging, monitoring tracing 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 “ ” to be on the bleeding edge of useable security principles. OWASP Top 10 Proactive Controls 2018 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 info@cossacklabs.com or @cossacklabs . We’d love to hear from you!

Flow

Amazon

Apple

Bitnami

Google

Oracle

Twitter

Visit our website now!

Too Long; Didn't Read

Questions about cloud security? Get answers here.

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

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Cossack Labs

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Cossack Labs

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES