Most business websites are based on content management systems. A CMS is built around a database, which is a favorite target of online attacks. WordPress, Joomla, Drupal, and Magento all have a database for holding dynamic information. Gaining access to it lets intruders steal information or alter the website's content.

From the attacker's standpoint, going after the database is more effective than altering the source files. The database is the CMS's storage closet. It contains mysterious items that you can't just throw out. It's hard to tell if some of them are unauthorized and might do harmful things to your website.

To keep your CMS secure, you have to protect the database carefully. You need to monitor the site for unauthorized content, so you can find and remove any unauthorized data. Rogue data can cause damage over a long time if you don't take measures to prevent and catch intrusions.

Attacks on a CMS-based website can go after the source files or the database. Source files can easily be restored, but the database is more complicated. It's not just the core software that accesses and modifies its content. Each plugin or add-on may have database entries for its own purposes. Identifying problems or restoring the database to a known good state is difficult.

Access requires authentication with a username and password. It's distinct from any user account's authentication. Most CMSs store the credentials in plaintext in a configuration file. That makes it easier to steal than a user's password, which is stored only in hashed form. Acquiring the config file means acquiring the database password.

One way to do this is to place malware on the target server and have it read the configuration file. It's also possible, if the site has certain vulnerabilities, to access the file through the browser. In the latter case, there may be no sign that anything has gone wrong until changes to the database cause nasty results.

The attacker needs to get an authorized connection to the database. In a well-configured system, having the username and password isn't necessarily enough. The server will accept access only from specified clients. There should be multiple barriers in the way of unauthorized access.
In WordPress, the target file is wp-config.php. It contains definitions like the following:

Joomla uses PHP assignments in configuration.php for the same purpose:

With Drupal, it's settings.php:

Someone who gains unauthorized access to the database can cause serious trouble. Infected source files also mean trouble, but they're easier to catch. A regular scan of the CMS directory will discover any changes to the files and issue an alert. Replacing the files with a good version will fix the problem, though you should find out why they were vulnerable. In a normal scan cycle, altered files will be restored in 24 hours or less.

Modifications to the database can't be caught as easily. It's intended to be modified, and each add-on or plugin has its own data. There's no known good state to revert to.

Another problem is that database access doesn't go through HTTP requests. The commands are invisible to the Web server and use a binary protocol that is distinctive to the database. Internal scans of the website won't reveal anything out of the ordinary. However, an external scan will catch any changes that show up in the HTML delivered to browsers.

If a site has what's known as a path traversal vulnerability, its configuration files are at risk. The situation exists when a request can specify an absolute file path or walk upward to a higher-level directory. Poorly tested plugins and add-ons may have this problem. Sometimes a backup copy of the config file is in a Web-reachable directory.

Here are a few real-life examples that we have logged from customer sites:

GET [protected.website]/wp-content/plugins/mailz/lists/config/config.php?wpabspath=../../../../../wp-config.php

GET [protected.website]/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

GET [protected.website]/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

GET [protected.website]/wp-content/plugins/wp-support-plus-responsive-ticketsystem/includes/admin/downloadAttachment.php?path=../../../../../wp-config.php

GET [protected.website]/wpcontent/plugins/mail-masta/inc/campaign/count_of_send.php?pl=../../../../../wpconfig.php

Another technique is to infect the server with malware which can download the configuration file to a rogue system. There are many ways an attacker can proceed from a successful infection, but acquiring database credentials has the advantage of being hard to catch. The code that stole the credentials can attack the database and erase itself when it finishes its job, or a different piece of code can exploit the stolen credentials.

Inspecting a database for unauthorized data is difficult. Other approaches will work better. Periodic external scanning will often discover the effects. The point of altering the database is usually to put malicious content on the website by modifying the way pages are generated. These changes will show up in a browser or an external scan.

For instance, the infection might add a link to a rogue website or redirect the user to a different server. A scan that emulates a browser will identify malicious content and issue an alert. Once you know how the site has been subverted, it's easier to examine the database for unauthorized data. When you get an alert, you should immediately change the database password and try to figure out how to prevent a recurrence.

Cross-site scripting, or XSS, is a common vulnerability in the software. It can happen wherever an unauthorized party can add arbitrary content to a page. Some sites allow user-created content and have to scrutinize input to keep JavaScript out. Others, such as ones using the plugin discussed here, unintentionally let unauthorized parties add content. Sites that allow XSS because they fail to verify authorization keep turning up.

Preventing the problem is better than having to fix it, of course. There are several steps to preventing the theft of database credentials.

The first is to protect the configuration file. Make sure it's in a directory that can't be reached by Web access and that any copies of it are equally safe. Keep plugins updated to fix any vulnerabilities.

Another important step is to restrict access to the database by IP address. Only systems that need database access should have it. Typically, this means just the servers that run the CMS. There should be no direct access to the database from any other client locations, even with the right credentials.

Third, a Web Application Firewall will catch requests that attempt to exploit path traversal vulnerabilities or download arbitrary files. This will protect against vulnerabilities that haven't been patched yet. The Quttera WAF provides broad website protection against both known and unknown attacks. It keeps malicious requests of all kinds from reaching the Web server. You get this protection when you sign up for ThreatSign. With ThreatSign, your systems are protected against hostile access and data theft. That means more uptime and a website that visitors trust.