OWASP Top 10 Security Risks and Vulnerabilities
Are you worried about the security of your WordPress plugin or theme? Are you sure they are safe to use? You should watch for these top 10 OWASP risks.
You’re right to worry about whether your software is secure. As much as developers would like to create airtight software, it’s not always possible. Vulnerabilities tend to appear over time even in some of the most secure software in the world.
But developers should be quick to recognize the flaws and fix them. If not, it could potentially put millions of WordPress users in danger of being hacked. This could result in disasters like hostile takeovers, data breaches, and financial losses!
OWASP offers developers with information about hackers and their attacks.
The OWASP (Open Web Application Security Project) is a worldwide not-for-profit organization that focusses on security awareness. One of its projects is the OWASP Top 10 which is a document that brings about awareness of web application security. It extensively analyzes security risks and narrows it down to the top 10 most-seen vulnerabilities.
This is a list that developers and site owners in the WordPress realm should not just be aware of but understand it in depth. So today, we’re taking a deep dive into the OWASP Top 10 to discuss the listed risks, their impact, and the measures you can take to combat them.
The OWASP Top 10 Security Risks
OWASP analyzes trends and releases its report every 5 years. The last 2017 report, the most-seen vulnerabilities were:
- Broken Authentication
- Sensitive data exposure
- XML External Entities (XXE)
- Broken Access control
- Security misconfigurations
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Using Components with known vulnerabilities
- Insufficient logging and monitoring
Good to note: Writing insecure code while developing software is one of the reasons many of these vulnerabilities occur. This could be because of the developer’s lack of experience. Other reasons include lack of security protocols in software development organizations, or rushing software releases. It could also occur because of choosing to create functional software rather than secure software. Testers must prevent this through a security testing process.
To avoid these vulnerabilities, there are measures developers as well as WordPress site owners can take. Here, we’ll discuss these in detail as we delve into the top 10 OWASP vulnerabilities.
1. Code Injection Vulnerability
Injection vulnerabilities are particularly widespread among web applications. In the WordPress realm, the most common example of this vulnerability is SQL injections.
An injection can occur when a website gives its users the option to enter data. It can be on a login page, site search, contact form, or blog comment. The information entered by the user is sent to the database for processing. Most of the time, this data gets stored here.
A vulnerability appears when there are no conditions and validation on the data that can be entered into these fields. What this means is that if there are no checks on what kind of data the user enters, then a hacker can send malicious codes. Next, this will enter the database and be executed. The consequences are highly damaging to the site and its contents.
What’s worse is that these injection vulnerabilities are not difficult for hackers to discover and exploit. In fact, there are many online tools hackers can use to find such vulnerabilities on websites. By exploiting the vulnerability, they can take over your website, steal data, leak confidential information – there’s no saying for sure what level of damage they can cause.
To explain how this happens, let’s look at an example of SQL injections.
Examples Of Code Injection Vulnerabilities
Let’s take a website that has a form that allows users to input their contact number. Then, this data goes to the database. But the form has not been set to accept only numerals. The form accepts text, symbols, and numerals. This becomes a parameter that a hacker can exploit to insert malicious code.
So in this injection vulnerability, hackers can input anything they want and send it to the website’s database. From here, they can send malicious codes that can create a new admin account with their email ID and a password of their choice. If the hack is successful, it gives them complete control of the site.
How To Prevent Code Injection Vulnerabilities
Here, we briefly discuss the measures you can take to prevent code injections. However, we strongly recommend reading our extensive guide on the subject.
For WordPress developers:
- Use SQL controls such as LIMIT within queries to prevent the mass disclosure of records if there is an SQL injection.
- You can also use a specific escape syntax in an interpreter to escape special characters for any residual dynamic queries. This will limit the kind of data a user can input.
- Use a positive or whitelist validation for server-side input.
- Use a safe API which entirely avoids the use of an interpreter or provides a parameterized interface.
These measures would help reduce the occurrence of code injections.
For WordPress website owners:
- The best way to prevent such injection vulnerabilities is to use a reliable WordPress security plugin such as MalCare. This plugin will scan your site for vulnerabilities and alert you if there’s any suspicious activity on your site.
- Limit the number of plugins and themes you use, down to the essentials.
- Never use pirated software as they come with pre-installed malware.
- Keep your website updated at all times.
These measures will also help prevent the other attackers we’re going to discuss.
2. Broken Authentication
Web applications use authentication methods to verify a user. If there’s a vulnerability in the authentication process, it can allow a hacker to either capture the credentials during authentication or to bypass the authentication altogether. This becomes a ‘broken authentication’ vulnerability.
The point of attack here is the login page of a website such as the /wp-admin page. We’ve listed the popular circumstances where this can happen:
- Storing Login credentials in browser cookies that are not encrypted. This allows hackers to read the credentials in plain text.
- Limited login attempts are not enabled which means hackers can brute force their way into a site.
- There is no 2-factor authentication on the site to verify the user in real-time.
- Not implementing session timeouts which means if a user failed to log out, a hacker can access a logged-in page even hours after a user has left the system.
Let’s take a look at some examples of this vulnerability to better understand it as it is one of the most top OWASP security risks.
Examples Of Broken Authentication Vulnerabilities
If a website doesn’t have limited login attempts enabled, an attacker can try to guess as many usernames and passwords as they like. This is known as credential stuffing or brute-forcing where hackers guess thousands of combinations with just a single command.
Another example of broken authentication is when session timeouts aren’t set. If you’ve noticed, banks will log you out automatically after a few minutes of inactivity. This is to prevent anyone else accessing your bank account left open on your browser.
Let’s take, for instance, a user simply closes their browser and walks away from their system. If a hacker gets access to this system, they can simply reopen the browser. The user will still be logged into their account even hours or days later. This kind of hack happens often on public computers.
Luckily, there are many ways to prevent it.
How To Prevent Broken Authentication?
The OWASP recommends the following to prevent broken authentication:
- Use a server-side built-in session manager that is secure. This will generate a unique random ID for that session and will be invalidated after logout/timeout. Remember, session IDs should not appear in the URL.
- Do not ship or deploy applications with default credentials like ‘admin’ and ‘password123’, especially for admin users.
- Use weak-password checks that will test your password against a list of the top 10,000 worst passwords.
- Ensure registration, API pathways, and credential recovery are secured against account enumeration attackers by using the same message for all outcomes.
For WordPress website owners:
- Implement limited login attempts on your site. This means if a user enters the wrong credentials, say three times, they are locked out of their account. They can use the ‘Forgot Password’ option or contact the admin.
If you use MalCare to protect your site, you automatically have this feature enabled.
- Use two-factor authentication. This means a user will have to enter their login credentials as well as a password generated in real-time. This password could be sent to their registered mobile number or email ID. You can also use apps like Google authenticator to implement this.
- Enforce the use of strong passwords among users. We recommend using a passphrase along with numerals and symbols.
- Ensure you log users out after a set period of inactivity. There are plugins available for this.
Your website’s login pages are the entryway into your website. Make sure they are ironclad! Next, we’ll discuss the third most-seen vulnerability in our OWASP top 10 list – Sensitive data exposure.
3. Sensitive data exposure
Sensitive data exposure takes place when software doesn’t have adequate measures in place to protect data while in transfer or storage. So, this means anything from passwords, credit card details, session tokens, and private health data can be at risk.
This kind of hack is more popularly called a data breach. If hackers get their hands on this information, they can run scams like making fraudulent purchases, access personal accounts, or blackmail victims. They even sell sensitive data to a thousand more hackers.
The costs of such a data breach can run into tens of millions of dollars. This is on account of investigation and reparation costs, legal fees, reputation damage, etc.
Examples Of Sensitive data exposure
The most common example of data exposure vulnerabilities is the use of HTTP.
HTTP stands for Hypertext Transfer Protocol which is used to transfer data between a user’s browser and a website. This was the general protocol used by all websites once upon a time, but HTTP transfers data in plain text.
What this means is if a hacker where to access this data during transfer, they can read the data as-is. This data could contain login credentials or credit card information.
Hence, HTTPS came into existence to encrypt the data. So even if hackers gain access to it, they won’t be able to decipher it.
How To Prevent Sensitive data exposure
- Ensure data is never stored in plain text.
- Do not accept data that is sent over non-HTTPS connections.
- Do not store credit card information ever. (Or else you need to be PCI compliant.)
- Make sure all passwords are hashed.
For WordPress website owners:
- Install an SSL certificate immediately. This will encrypt data while in transit or storage.
- Migrate all your pages from HTTP to HTTPS. You will see that your website gets a padlock in the address bar.
- Generate new security keys and salts.
Lastly, we recommend protecting your backups as well with encryption. Plugins like BlogVault automatically encrypt your backup before storing it securely.
Safeguard your backup copy! With BlogVault backups, your data is automatically encrypted and stored safely. Click To Tweet
4. XML External Entities (XXE)
This kind of vulnerability allows attackers to interfere with an application’s processing of XML data. This includes how it reads local files on the server, accesses internal networks, and scans internal ports. Hackers could also execute commands on a remote server.
How does this attack happen? Hackers take advantage of an XML parser that isn’t configured correctly and accepts XML directly or allows it XML uploads. This enables them to access an XML input that contains references to an external entity.
They could also establish connections to arbitrary hosts over HTTP and HTTPs.
Examples Of XML External Entities (XXE)
Let’s take for instance a regular WordPress website that allows users to upload files – possibly Docs, PPT, or XLSX files. Sometimes, the site could have a vulnerability that enables a hacker to upload an XML format file.
This allows hackers to embed their malicious code into a file and upload it to the site.
Once the site’s server receives the file, it will parse it and will execute the malicious code.This could result in the disclosure of sensitive information from the client-server. Keep in mind this OWASP risk.
How To Prevent XML External Entities (XXE)
You can prevent XXE attacks, by disabling external entities. If you require external entities, restrict it to trusted external links. This is much like blocking emails you receive from suspicious senders with a spam or malicious warning. Your email provider will not let you click on any links or even view the email, until you, the receiver, mark it as safe.
You can also implement the following:
- Turn off entity expansion in XML.
- Check if XML libraries used are vulnerable to XXE. If vulnerable, update immediately to more secure versions.
- Validate user-supplied input for internal and external entities and INLINE DOCTYPE definitions prior to parsing.
These measures should reduce the chances of XXE attacks.
5. Broken Access Control
We spoke of broken authentication earlier where authorization is a method of verifying a user. Upon successful verification, it grants the user access to content and functions. Access control then checks what permissions the user has and governs what authorizations they have.
For example, on a WordPress site, you have six user roles – subscriber, contributor, author, editor, admin, and super admin. Each role has different responsibilities and permissions. Access control governs this.
In some cases, access controls are not set correctly. This could be because many times implementation of access controls comes after the development of the application. They are also frequently changed by developers in some cases. This results in access control being inserted into and deleted from various locations in the coding of the application.
The haphazard management of access controls could result in flaws. Thus, vulnerabilities in access controls aren’t difficult to discover and exploit.
Next, we’ll explain how broken access controls can be taken advantage of with an example.
Examples Of Broken Access Control
Let’s take, for instance, a hacker brute forces their way into a subscriber account on a WordPress site. The user’s permissions are limited to ‘read posts and write comments’. ‘Access control’ governs these restrictions.
Access controls usually use an ID or a key to reference which user role has which functions, permissions, and restrictions.
If a hacker is able to guess or find this ID or key, they can change the granted permissions of the account they hacked. In this way, they can gain unauthorized access to files and can even gain full control of the site.
This is one example of broken access control. A hacker could use various other ways such as:
- Forced browsing past access control checks – It requires users to pass specific checks before they can access to certain URLs. Hackers can bypass these checks if there is a vulnerability in the coding.
- Path traversal – A hacker tries accessing files by submitting a request for information in URLs or any other input that is weak.
- File permissions – There are files that are stored locally on the web server and application server. Certain files like configuration and default files should not be publicly accessible. Sometimes the viewing permissions are enabled for all files which a hacker can take advantage of.
How To Prevent Broken Access Control
- Do not just hide functions and controls. Set permissions to remove access for users.
- Limit the files stored on web servers and application servers. Only files that are intended to be presented to web users should be marked as readable.
- Do not allow remote administrator access.
- Test access control mechanisms regularly.
Developers and site owners need to take precautions against broken access control. With that, we wrap up on broken access controls and move to the next most dangerous vulnerability – security misconfigurations. This risk definitely deserves a place in our OWASP top 10 list.
6. Security Misconfigurations
Improper security configurations refer to weakness in the coding or omissions of security protocols that end up giving hackers an easy pass. If the configurations aren’t set correctly to ensure security, it could enable debugging, give permissions to incorrect folders, or use default accounts and passwords. It can even enable modification of setup or configuration pages.
If hackers are able to do this, over time, they can steal data and take complete control of your site.
Examples Of Security Misconfigurations
During development, you might’ve created and used sample applications. Such sample applications usually have flaws, especially security ones. For example, passwords could be set to default ones like ‘admin’ and ‘password’. Failing to remove these apps from your production server after going live, would enable attackers to compromise your server. This should be prevented in application security testing process.
How To Prevent Security Misconfigurations
There are plenty of ways to prevent this vulnerability – the main one being focussing on writing secure code, not just functional code. Other measures include:
- Disable debugging features.
- Disable the use of default accounts and passwords.
- Prevent unauthorized access and directory listings by configuring the server.
- Run scans and audits regularly to detect misconfigurations and any flaws.
It is of utmost importance that developers implement security measures to disable or prevent access to confidential data and resources. Another dangerous and rampant hack is cross-site scripting which we’ll discuss next.
7. Cross-Site Scripting (XSS)
Similar to an injection attack, XSS also exploits areas where users can input data such as a comments section. The attacker inserts their malicious scripts here and waits for the user to visit this post. When the user does so, the hacker extracts information from the user’s browser session cookies. They try to steal login credentials or any security keys that could help them run bigger attacks.
Examples Of Cross-Site Scripting (XSS)
Let’s take a website where user inputs go to the database. Now a hacker has accessed the comments section of a blog post on this site and inserted a malicious code as a regular comment.
Next, a visitor comes to this page. This person also has other tabs open such as Facebook, email, a shopping website, etc. The code present in the comments section infects the visitor’s browser. It will be able to extract data from the browser cookies pertaining to all other pages open on the browser. This is cross-site.
Sensitive information like login credentials, any stored credit card data, or personal contact information that’s stored in the browser cookies can be stolen. This OWASP risk is one of the most common.
How To Prevent Cross-Site Scripting (XSS)
There are two main ways in which you can prevent XSS on your site:
- Make sure the web browser is using the same-origin policy. This means requests generated from one web page cannot access any data generated on another page.
- Differentiate between markup tags and content. A website should be able to tell the difference between a regular user’s input and malicious code.
We recommend reading our guide to preventing cross-site scripting attacks for more detailed information.
8. Insecure Deserialization
We first need to understand what serialization and deserialization mean. Serialization is a process in which an object is converted into a format that saves to a file or sent over a stream or network. These formats include XML, JSON, YAML.
Deserialization is the opposite. It transforms serialized data coming from a file, stream or network and converts it to an object.
Both processes are a regular part of programming and normal practice in software development. The vulnerability occurs when deserialization accepts untrusted user input.
The hacker can exploit the vulnerability to bypass authentication, execute codes remotely, and even launch larger DDoS attacks. Let’s take a look at how this happens.
Examples Of Insecure Deserialization
In WordPress, such a vulnerability can spring up when plugins or themes accept user inputs into its deserialize function.
Let’s say, a website has a plugin installed that allows users to input data – say through a comments box.
When the user enters their comment, the plugin does not properly sanitize this data before passing it to the serialize function. If a hacker is aware that this vulnerability exists, then they could send ad-hoc serialized strings through this comment box.
Let’s assume the plugin processes and autoloads this input. This would mean the malicious code fed to the deserializing PHP module and will be executed. The hacker will have successfully hacked the site.
How To Prevent Insecure Deserialization
- Do not pass untrusted user-supplied input to serialize().
- Use a safe, standard data interchange format like JSON to pass serialized data to the user.
As a developer, it’s important to take precautions against insecure deserialization and that’s why this must take place in our OWASP top 10 list of security risks.
9. Using Components With Known Vulnerabilities
There are times when websites use outdated software or other components that have known vulnerabilities. This happens due to many reasons. Let’s take a deeper look.
The last known security vulnerability in the WordPress software was in version 5.2.3. It allowed cross-site scripting in post previews by authenticated users. However, this was patched promptly and they released version 5.2.4 on 14th October 2019.
Now, WordPress made a public announcement about vulnerability and the patch release. But only a handful of people are running on the latest version. Statistics show that there are around 75% of WordPress sites running on outdated versions.
75% of WordPress sites are running on outdated versions! Update your website to avoid the risk of being hacked. Click To Tweet
What this means is that hackers now know the vulnerability. They simply need to seek out sites that are using the old version. Exploiting it becomes easier because they are already fully aware of what the vulnerability is.
The same applies to plugins and themes as well. So why do websites use components with known vulnerabilities?
Sometimes, website owners defer updating their site simply because they lack sufficient knowledge about how important updates are. Or they are afraid it might break their website as updates don’t always go smoothly. Sometimes, site owners haven’t run updates for so long that it becomes impossible to jump from version 3.4 all the way to version 5.3. It would mean losing data and breaking functionality.
How To Prevent Using Components With Known Vulnerabilities
The easy answer to this is to not use components with known vulnerabilities. Period. But this is not always possible. For developers,
- Avoid using such components, to begin with.
- Schedule regular maintenance of components and subcomponents of software.
- Remove all unnecessary and unused items as it could give more access points to hackers.
For website owners, we recommend you take the following steps:
- Update your website regularly. If you see a security patch available, update immediately.
- Never use pirated or cracked versions of themes and vulnerable plugins. They usually carry pre-installed malware.
- Then, install a security plugin like MalCare that will alert you if your software needs to be updated.
- If you worry about breaking your site, use a professional WordPress management solution.
10. Insufficient Logging and Monitoring
OWASP stated, “Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals.”
Monitoring and continuously analyzing software and its development are some of the most effective ways to identify threats and suspicious behavior early on.
Maintaining detailed logs helps track down the details of any attack promptly. Let’s look at an example that will illustrate this point.
Examples Of Insufficient Logging and Monitoring
Let’s take, for example, a hacker logs into a user’s account multiple times. They steal credentials and other data.
If the site owner has enabled the maintenance of a proper security log, they’d be able to identify the false logins by analyzing IP addresses that don’t belong to their organization.
Now, the thing is hackers are sneaky. They know well how to hide their codes, disguise them, and wipe out their activity from these logs. So just how do you overcome this?
How To Prevent Insufficient Logging and Monitoring
You might have seen that when you log in to your email from another computer, you immediately get a message on your phone that there has been an attempt to log in from a new IP. If this was not you, you need to contact them immediately. This alerts you if any attempts to log in to your private email account unauthorized. This kind of monitoring and logging of activities is what prevents hacks.
Other methods you can implement are:
- Using a plugin that takes an independent activity log. Therefore, even if the hacker erases your log, your plugin has a copy of it stored offsite. You can then use it to trace the hacker and their activities.
- Security plugins like MalCare give you a report on where login attempts are being made from geographically.
If you notice that there are clusters coming from unwanted countries, you can block the entire country with geoblocking.
- Schedule regular checks of your activity log.
- Then, ensure you get alerts if there are too many failed login attempts.
Having adequate logging and monitoring measures in place can better your management and detection of incidents. This enables faster response to attacks and safeguards you from hackers.
I learned everything I needed to know about OWASP's Top 10 security vulnerabilities with MalCare’s in-depth report. Click To Tweet
In Conclusion: Our Take On OWASP Top 10
The OWASP Top 10 list sheds light on the most frequently occurring hacks. This helps developers, researchers and site owners to have more information on hand about what mistakes to avoid making and what security measures they need to take.
It helps keep hackers at bay by empowering developers and site owners to stay updated and informed about what’s happening.
Security is not something to take lightly as the digital realm is filled with potential risks and dangers.
If you liked this article, you’ll love how our security plugin safeguards your site from hackers and threats! Keep your WordPress site protected at all times.
Try our MalCare Security Plugin Now!
Melinda is a WordPress enthusiast, and enjoys sharing their experience with fellow enthusiasts. On the MalCare blog, Melinda distils the wisdom gained from building plugins to solve security issues that admins face.