Intended for technical staff and IT service providers, this document gives guidelines to merchants running Content Management Systems such as Drupal, Joomla!, Magento, WordPress and suchlike.

It warns them against the most common misconfiguration scenarios that can lead to data compromises and/or breaches, and recommends steps to protect themselves and their customers.

The information contained in this document is non-binding and subject to change, as the scene evolves.

Acronyms and key words

RFC 2119 key words

Should they appear hereafter, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 / BCP 14.

Acronyms and abbreviations

Bit: Binary Digit (quantification unit in computer systems)

CMS: Content Management System
CSRF: Cross-Site Request Forgery (attack that tricks victims into executing a legitimate request to another site, with their credentials)

FIM: File Integrity Monitor
FTP: File Transfer Protocol
SFTP: Secure FTP over SSH
SSH: Secure Shell Protocol
WAF: Web Application Firewall
XSS: Cross-Site Scripting (malicious code injected by a hacker on your site, executed by your site's visitors with potentially malicious effects)

Preamble on Content Management Systems

Content Management Systems have become the de facto way a company can quickly and efficiently reach out to its customer base.

They come in various formats, offer a lot of different plugins for high customization and are often free to use.

They also benefit from regular security and functionality updates.

A downside of CMSes however is that their wide use makes them an ideal target for hackers. Worse, these systems are often implemented by non-technical staff, in insecure ways.

On top of the vulnerabilities that come with CMSes (CSRF, XSS, session hijacks, code injections…), they are often installed and configured in an insecure way which allows attackers to access restricted areas, upload and run malicious code, and generally attack visitors.

While you have no control over these inherent vulnerabilities, several measures can be taken to ensure you are as secure as possible.

These steps include, but are not limited to:

Reading the CMS’ hardening instructions,
Regularly applying security updates,
Subscribing to vulnerability watch mailing lists, at the very least for your CMS,
Performing regular security scans (Nessus, Qualys),
Performing regular penetration testing (or having it done by a professional),
Regularly reviewing your web access logs,
Installing a File Integrity Monitor to get notified of code changes on your site,
Implementing a Web Application Firewall to block most of the injection attacks.

Most, if not all, of the merchants who suffered a data breach were using an insecure CMS and insufficient countermeasures.

Hardening your CMS

Most CMSes come with instructions on how to harden them against attacks.

These often include generic advice, such as keeping your system up to date, reviewing third-party modules you install or securing file permission bits (access rights).

Joomla!, Magento and WordPress all come with up-to-date security advice which should be followed prior to running your site in production:

Drupal doesn’t seem to offer a proper checklist of security measures.

On top of this, a number of guides from KeyCDN are available to help merchants understand and mitigate the security problems with their CMS:

File System permissions

Aside from following hardening guides, it is strongly recommended that you familiarize yourself with UNIX Permission Bits.

CMSes, and websites in general, often get hacked through code injections. Such injections are made possible by sites blindly trusting user input and injecting it in their database or uploads folder. Incorrect permissions at the file system level, on the web server’s files, also facilitate these attacks.

There are very few cases where your CMS and web server need write access to files served to your customers.

Understanding which privilege allows which access is critical in keeping your CMS secure.

Please read your CMS’ hardening guide for more information on which files and directories should be writable.

PHP and code parsing in sub-directories

Now that you have followed your CMS’ hardening guide and made sure you are using secure file system permissions, there is another venue of attack against which you need to protect your customers.

In spite of your efforts, if a hacker manages to inject code, you need to take steps to prevent them from running said code.

A typical injection attack allows a hacker to write a file to your web directory, then call the page from their web browser to read files on your server, or even worse, alter the code in existing files (but you have already adjusted your file system permissions, haven’t you?).

Once hackers manage to write uploads/shell.php, it is trivial for them to call http://yoursite/uploads/shell.php and exfiltrate information such as your SQL database credentials.

However, there is no legitimate reason for your uploads folder to contain executable files.

Therefore, you may want to disable the interpretation of code in your uploads directory.

If your web host is running Apache, you may do so by creating a .htaccess file containing the following lines and pasting it in your uploads folder:

<Files *.php>
deny from all
</Files>

Or

RewriteRule ^.*\.php$ - [F,L]

Here is a more secure way if your web host allows the use of PHP flags:

php_flag engine off

If you are not using mod_php but a CGI parser instead (modcgi, fastcgi):

RemoveHandler .php

For more information on how to use .htaccess files, please refer to this post from DigitalOcean.

If you are self-hosted and running another web server, this post describes how to achieve the same with NginX.

Please note that the order of your location directives matters.

Advanced techniques

If you are self-hosted (i.e., you are not on a shared server) and have full control over the Operating System, there are a number of additional steps you can take to ensure your safety and the safety of your visitors.

Two very efficient techniques consist in installing and configuring a File Integrity Monitor and a Web Application Firewall.

The File Integrity Monitor will warn your technical staff of changes to files in your web server’s directory.

The Web Application Firewall will block most injection attacks (SQL, code).

Please note that both measures are mandatory as per PCI DSS requirements and must be monitored (make sure that they are running) as well as kept up-to-date at all times.

Getting help and technical support

Should you have any questions or need help interpreting this document, please do not hesitate to contact HiPay by submitting a request through our Support Center.

Literature and further reading

On code injection attacks: https://www.owasp.org/index.php/Code_Injection

On CSRFs: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

On CSRF prevention: https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

On Drupal hardening: https://www.keycdn.com/blog/drupal-security/

On File Integrity Monitors: http://ossec-docs.readthedocs.io/en/latest/manual/syscheck/

On Joomla! hardening 1/2: https://docs.joomla.org/Security_Checklist/Joomla!_Setup

On Joomla! hardening 2/2: https://www.keycdn.com/blog/joomla-security/

On Magento hardening 1/2: http://docs.magento.com/m1/ce/user_guide/magento/magento-security-best-practices.html

On Magento hardening 2/2: https://www.keycdn.com/blog/magento-security/

On UNIX file permissions: https://www.linux.com/learn/understanding-linux-file-permissions

On Web Application Firewalls: https://www.owasp.org/index.php/Web_Application_Firewall