All developers come across at least a couple of issues while they find themselves developing applications for the web. That’s exactly why sites like Stack Overflow, Stack Exchange, and the like exist – that’s developers helping other developers in trouble.
If you’re a frequent visitor of Stack Overflow though, you will notice that most of the issues related to software engineering have something to do with databases as well – new questions are also posted minutes ago, literally. And the given example only pertains to MySQL – can you imagine how many new questions are posted day-by-day targeting other database management systems? Thousands.
But what’s so problematic about databases? Why are they such a frequent problem discussion object? Well, it depends on who you ask – some might say that it’s because developers don’t know how to build software properly, some might argue that developers aren’t educated on security matters, others might have different opinions, but the problem remains – database management systems – MySQL, MariaDB, Percona Server, SQL Server, PostgreSQL, TimescaleDB, and others support web applications which means that all queries that allow web applications to work run through them – no matter what database flavor we elect to use, we use to store and interact with data.
Problems Pertaining to Database Management Systems
The title of this paragraph might seem confusing, but let us assure you it’s not. You see, problems pertaining to MySQL, Oracle, Sybase, TimescaleDB, and other database management systems are numerous, however, they all arise from the same things and spin around the same universe. They pertain to:
- Security – ever heard of SQL injection? Yeah.. that’s the one security flaw that will make sure attackers dump every last bit of your data and sell it for profit.
- Availability – one wrong SQL query and it will make your database timeout. Once one query times out, say goodbye to a part of your web application – and your clients too.
- Performance – performance mostly pertains to SQL queries too. Issue a SELECT * instead of selecting one column that is necessary, run hundreds of such queries via a loop, and oops – queries complete in 30 seconds instead of 1 millisecond. Not fun.
Many problems in the database space start like this:
If you haven’t already spotted it, the code block above has a SQL injection flaw, it doesn’t close it’s headers, and it’s also vulnerable to account enumeration. Echo a username and you also have a cross-site scripting flaw.. Obviously, not everything is exploitable via the database, but you see where we’re going. Developers usually connect to a database, run a couple of queries (which might also be susceptible to SQL injection), and problems begin. See what we mean?
You’ve successfully spotted one issue – the issues pertaining to databases can be of varying severity, though. Here are a couple of scenarios:
- - You write a loop to loop a query through multiple databases at once – clients come and tell you about availability issues. Someone forgot to finish a loop once it started..
- - You write a query to log users in and forget to escape user input (see example above) – that leaves your database wide open to SQL injection where attackers can simply craft a couple of queries to take control of your user table. It all might seem like a joke, but when you think that a data breach could cost your company hundreds of thousands, if not millions, is it worth the risk?
- - Your application is running well, but one day everything goes down. All you have is a file called access.log (if that) – what do you do? Since you don’t have a database management tool at hand and you’ve never thought that such a scenario is even possible, the only option left for you is to evaluate all 400,000 lines in the file one by one – sounds like fun.
- - Your application is using a bunch of old code and so it connects to a database that no longer exists – the issue is easy to solve in one or two scripts, but in a wide majority of projects, the amount of scripts aren’t in the area of tens – in most cases, you will have 200-300 scripts to change a couple of lines in.. Are you ready for the hassle?
- - Your application runs well, but one day your database is no longer able to use the memory that’s required by your application – too many simultaneous queries run at once and your server cannot easily handle it. You cannot upscale the server either because of hosting constraints – what do you tell your clients?
- - Glance at the code example again – the application stores all of its users passwords in plain text.. knowing that the piece of code is susceptible to SQL injection, a data breach will certainly knock on the door in the span of months, if not weeks. What then? Do we even have backups of our databases?
- - You forgot to back up your data and your web application goes down requiring you to restore from backups – this scenario might seem laughable, but you would be surprised how many developers have gone through this exact problem. Developers then usually recover their data from older backups, some being at least half a year old, and move on from there learning from the issue, but you don’t want to be one of them, do you?
You get what we mean. Just how do you overcome these database issues quickly and effectively? The answer is simple – take better care of your applications and educate yourself on the performance, security, and availability of your databases. Or, better yet, employ a database management software solution to take care of all of these problems for you for a small fee.
Most good database management software solutions will not only take care of the issues mentioned above, but also ensure that you are always in control of database operations – they will let you run database jobs (pieces of software that ensure your database runs well), and also provide you with an overview of how your database is working at any given point – no matter you fiddle with your databases at day, or at night. The whole point of this approach is that once you see that all (or at least some) of your databases are underperforming, you can issue a couple of database jobs to make it perform better, strengthen its security, or make it available during 100% of the time someone is working on it.
Enter dbWatch Control Center – not only will it allow you to improve the availability, performance, and security of all of your database instances you import into the software for monitoring (see screenshot below), but it will also provide you valuable advice on what exactly to change and how to get the best out of your database instances. Users are able to gain an overview into their databases via a couple of nice graphs depicting the most important metrics, and then act on them by running database jobs to improve their database performance, security, availability, or capacity (or all of them at once.)
And that’s not even it – all jobs come with parameters that can easily be modified to further adjust them to your needs and dbWatch Control Center also provides information on all jobs that have previously been executed. The parameters that can be modified depends on the database job itself – for example MySQL’s InnoDB job has multiple thresholds that can be adjusted (see example below), other database jobs come with different specifications.
An overview of the parameters that are available for use is always available for you to use as well:
dbWatch makes solving all of the common issues encountered by developers as easy as eating a piece of cake – if you still don’t believe us, feel free to grab a free trial and test the software out for yourself, and we will see you in the next blog!
About the Author:
Lukas Vileikis is an ethical hacker and a frequent conference speaker.
Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.
He runs one of the biggest & fastest data breach search engines in the world - BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including his blog over at lukasvileikis.com.