Website Security: WordPress

Wordpress, How secure is it?

Well that is probably one of the most talked about topics when it comes to WordPress development, how secure is WordPress?

First we have to look at what Cyber-Security actually is:

Cyber-Security is the protection of internet-connected systems, including hardware, software and data, from cyberattacks.

Modern day Cyber-Security is more about limiting the damage caused by a breach than actually preventing the breach, this is due to the multitude of ways that an attacker could break into a system. One example of this is that a web app could be vulnerable to SQL Injection. SQL Injection is an attack that involved sending a website unescaped SQL Queries that will then do something on the server, such as deleting the entire database or returning a list of all users usernames and passwords.

In relation to modern websites there are 3 common types of preventable attack:

  1. Cross-Site Scripting (XSS)
  2. SQL Injection
  3. Cross-Site Request Forgery (CSRF)

According to Positive Technologies, these 3 Types of attack make up 58.7% of all web based attacks.[1]

Cross-Site Scripting (XSS)

There are a few methods of doing this; the most common by far is sending some data to a website, the website can sometimes then display this data back to the browser. Due to HTML allowing for script tags which can contain JavaScript code, this allows a potential attacker to start to change the markup and content of the website. This can be especially dangerous if the data is then stored as raw HTML (No tags have been removed or escaped), this can be due to how the data is then used, if the data is used on a forum for example, the code could be loaded and run every time someone visits that forum. The code could then be used to steal a users username and password, if a login form is present on the same page as the code.

A major example of this was a vulnerability found in eBay’s Auction description, this allowed for script tags to be added to the description. The actual attack lasted for over a month and a half before eBay managed to find all of the auctions with the malicious code, during this time the code was redirecting people to a spoof login page asking them for their eBay details; these details were then being sent to the attacker.

In relation to WordPress: As standard WordPress is not vulnerable to XSS Attacks, however if a plugin has been installed that is vulnerable to XSS this will make the website also vulnerable to XSS. the scope of the vulnerability will depend on what the plugin does and how easy it is for an attacker to use this to inject malicious code onto the website.

SQL Injection

This is the second most common type of attack, it can only occur when an attacker sends SQL to the website that is the used directly in an SQL Query. For example:

Lets say that a website has an unescaped search box allowing the relevant posts on the website to be displayed in a 3 column table: Title, Excerpt, Date Published.

Now because the input filed being used for the search box is unescaped on the server, it will allow us to send (inject) SQL Queries, these Queries will then be run by the SQL Server and will return results.

So, assuming the default query being send to the SQL Server is something like this:

SELECT title, description, date_published FROM 'posts' WHERE title LIKE '%{{ Some Data }}%';

In this query the {{ Some Data }} would be replaced by the value of the input field. Some intermediary Server Side language would then take the return value of this query and generate some HMTL which is the returned to the clients web browser. Due to the value of the search filed being unescaped, we can start to send our own queries along with the query being run, to do this we could type into the field something like this:

' UNION SELECT username, password, 1 FROM users; --

Submitting the form would make the search query this:

SELECT title, description, date_published FROM 'posts' WHERE title LIKE '%' UNION SELECT username, password, 1 FROM users; --'%';

In SQL the union clause will take the rows from the second SELECT and append them to the first SELECT, so by submitting this the server would return all of the website usernames and passwords. We could also delete the entire database or a few tables, or even edit some tables to insert our own XSS Code using this same technique. Here is a good video explaining more about how to do this and why it is important to protect against SQL Injection.

In relation to WordPress: As standard WordPress is also not vulnerable to SQL Injection, it uses a PHP Class to generate SQL code that is all escaped and rarely allows for any user submitted code to be unescaped. The danger is when a plugin is installed that is vulnerable to SQL Injection, especially when it only takes 1 query to be unescaped to allow this sort of attack to be successful. Having said that, WordPress uses a multi level md5, DES or Blowfish Hash functions to store user passwords, this means that even if a SQL Injection attack is successful and an attack does manage to get ahold of some user details, they cannot actually see the passwords as they will first have to use some form of brute force or rainbow table to decode the passwords.

Cross-Site Request Forgery (CSRF)

This method of attack is used to make an authenticated User perform requests or actions that are unwanted. For example:

  1. Sending a Transaction
  2. Deleting an account
  3. Changing their Email address or login details

This attack usually consists of a user clicking on a link that will perform some action on account they’re already logging in to, for example: If a user is logged into their online bank, a CSRF attack could be for them to visit an address that will initiate a bank transfer to the hacker. This type of attack can be mitigated by use of CSRF Tokens, these tokens are completely random and are generated when a form is requested by a client. this token is then stored and when the form is submitted it is compared against the value of the submitted CSRF Token. If they match then the request is allowed to continue, if not then an error message is usually displayed showing a timeout error.

In relation to WordPress: WordPress uses a CSRF Token system called a nonce, as explained above this prevents any unauthorised actions being carried out by an authorised user. The danger of this type of attack is when a plugin or theme is being used that is vulnerable to CSRF, and so will allow some plugin or theme specific actions being performed.

In Conclusion

Overall WordPress is a very stable and secure platform, it is protected against the 3 most common forms of attack and, due to being used in 32.9% of websites[2], new updates and security fixes are being released periodically. The only issues that are caused is when a plugin or theme is poorly built or maintained and allows for any of the above attacks. to mitigate this risk we would always advise to use popular plugins and themes or check the plugin for these vulnerabilities before deciding to use it on your WordPress Website.

 

References:

  1. Positive Technologies. 2017. Web application attack statistics: Q4 2017. [ONLINE] Available at: https://www.ptsecurity.com/ww-en/analytics/webapp-vulnerabilities-2017-q4/. [Accessed 24 January 2019].
  2. W3Techs. 2019. Historical trends in the usage of content management systems, January 2019. [ONLINE] Available at: https://w3techs.com/technologies/history_overview/content_management/all. [Accessed 24 January 2019].