When managing a website, it’s important to stay on top of the most critical security risks and vulnerabilities. The OWASP Top 10 is a great starting point to bring awareness to the biggest threats to websites in 2021.
OWASP stands for the Open Web Application Security Project, an online community that produces articles, methodologies, documentation, tools, and technologies in the field of web application security.
OWASP Top 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Updated every three to four years, the latest OWASP vulnerabilities list was released in 2017. Let’s dive into it!
Contents
A code injection happens when an attacker sends invalid data to the web application with the intention to make it do something that the application was not designed/programmed to do.
Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data. You can see one of OWASP’s examples below:
String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;
This query can be exploited by calling up the web page executing it with the following URL: https://example.com/app/accountView?id=’ or ‘1’=’1 causing the return of all the rows stored on the database table.
The core of a code injection vulnerability is the lack of validation and sanitization of the data used by the web application, which means that this vulnerability can be present on almost any type of technology related to websites.
Anything that accepts parameters as input can potentially be vulnerable to a code injection attack.
We’ve written a lot about code injection attacks. One of the most recent examples is the SQL injection vulnerability in Joomla! 3.7.
Here is another example of an SQL injection that affected over half a million websites that had the YITH WooCommerce Wishlist plugin for WordPress:
The SQL injection shown above could cause a leak of sensitive data and compromise an entire WordPress installation.
Preventing code injection vulnerabilities really depends on the technology you are using on your website. For example, if you use WordPress, you could minimize code injection vulnerabilities by keeping it to a minimum of plugin and themes installed.
If you have a tailored web application and a dedicated team of developers, you need to make sure to have security requirements your developers can follow when designing and writing software. This will allow them to keep thinking about security during the lifecycle of the project.
Here are OWASP’s technical recommendations to prevent SQL injections:
Preventing SQL injections requires keeping data separate from commands and queries.
From these recommendations you can abstract two things:
Without appropriate measure in place, code injections represent a serious risk to website owners. These attacks leverage security loopholes for a hostile takeover or the leaking of confidential information.
The Sucuri Firewall can help virtually patch known vulnerabilities and block attacks against your website.
A broken authentication vulnerability can allow an attacker to use manual and/or automatic methods to try to gain control over any account they want in a system – or even worse – to gain complete control over the system.
Websites with broken authentication vulnerabilities are very common on the web. Broken authentication usually refers to logic issues that occur on the application authentication’s mechanism, like bad session management prone to username enumeration – when a malicious actor uses brute-force techniques to either guess or confirm valid users in a system.
To minimize broken authentication risks avoid leaving the login page for admins publicly accessible to all visitors of the website:
The second most common form of this flaw is allowing users to brute force username/password combination against those pages.
According to the OWASP Top 10, these vulnerabilities can come in many forms. A web application contains a broken authentication vulnerability if it:
Writing insecure software results in most of these vulnerabilities. They can be attributed to many factors, such as lack of experience from the developers. It can also be the consequence of more institutionalized failures such as lack of security requirements or organizations rushing software releases, in other words, choosing working software over secure software.
In order to avoid broken authentication vulnerabilities, make sure the developers apply to the best practices of website security. Support them by providing access to external security audits and enough time to properly test the code before deploying to production.
OWASP’s technical recommendations are the following:
Sensitive data exposure is one of the most widespread vulnerabilities on the OWASP list. It consists of compromising data that should have been protected.
Some sensitive data that requires protection is:
It is vital for any organization to understand the importance of protecting users’ information and privacy. All companies should comply with their local privacy laws.
Responsible sensitive data collection and handling have become more noticeable especially after the advent of the General Data Protection Regulation (GDPR). This is a new data privacy law that came into effect May 2018. It mandates how companies collect, modify, process, store, and delete personal data originating in the European Union for both residents and visitors.
There are two types of data:
Both types of data should be protected. When thinking about data in transit, one way to protect it on a website is by having an SSL certificate.
SSL is the acronym for Secure Sockets Layer. It is the standard security technology for establishing an encrypted link between a web server and a browser. SSL certificates help protect the integrity of the data in transit between the host (web server or firewall) and the client (web browser).
We have created a DIY guide to help every website owner on how to install an SSL certificate.
According to the OWASP Top 10, here are a few examples of what can happen when sensitive data is exposed:
Over the last few years, sensitive data exposure has been one of the most common attacks around the world. Some examples of data leaks that ended up in exposing sensitive data are:
Not encrypting sensitive data is the main reason why these attacks are still so widespread. Even encrypted data can be broken due to weak:
This vulnerability is usually very hard to exploit; however, the consequences of a successful attack are dreadful. If you want to learn more, we have written a blog post on the Impacts of a Security Breach.
Some of the ways to prevent data exposure, according to OWASP, are:
According to Wikipedia, an XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.
Most XML parsers are vulnerable to XXE attacks by default. That is why the responsibility of ensuring the application does not have this vulnerability lays mainly on the developer.
According to the OWASP Top 10, the XML external entities (XXE) main attack vectors include the exploitation of:
Some of the ways to prevent XML External Entity attacks, according to OWASP, are:
If these controls are not possible, consider using:
In website security, access control means putting a limit on what sections or pages visitors can reach, depending on their needs.
For example, if you own an ecommerce store, you probably need access to the admin panel in order to add new products or to set up a promotion for the upcoming holidays. However, hardly anybody else would need it. Allowing the rest of your website’s visitors to reach your login page only opens up your ecommerce store to attacks.
And that’s the problem with almost all major content management systems (CMS) these days. By default, they give worldwide access to the admin login page. Most of them also won’t force you to establish a two-factor authentication method (2FA).
The above makes you think a lot about software development with a security-first philosophy.
Here are some examples of what we consider to be “access”:
Attackers can exploit authorization flaws to the following:
According to OWASP, here are a few examples of what can happen when there is broken access control:
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.
https://example.com/app/accountInfo?acct=notmyacct
https://example.com/app/admin_getappInfo
Developers are going to be more familiar with the above scenarios, but remember that broken access control vulnerabilities can be expressed in many forms through almost every web technology out there; it all depends on what you use on your website.
There are things you can do to reduce the risks of broken access control:
To avoid broken access control is to develop and configure software with a security-first philosophy. That’s why it is important to work with a developer to make sure there are security requirements in place.
The technical recommendations by OWASP to prevent broken access control are:
At its core, brute force is the act of trying many possible combinations, but there are many variants of this attack to increase its success rate. Here are the most common:
One of the most common webmaster flaws is keeping the CMS default configurations.
Today’s CMS applications (although easy to use) can be tricky from a security perspective for the end users. By far, the most common attacks are entirely automated. Many of these attacks rely on users to have only default settings.
This means that a large number of attacks can be mitigated by changing the default settings when installing a CMS.
There are settings you may want to adjust to control comments, users, and the visibility of user information. The file permissions are another example of a default setting that can be hardened.
Misconfiguration can happen at any level of an application stack, including:
One of the most recent examples of application misconfigurations is the memcached servers used to DDoS huge services in the tech industry.
According to OWASP, these are some examples of attack scenarios:
In order to prevent security misconfigurations:
Cross Site Scripting (XSS) is a widespread vulnerability that affects many web applications. XSS attacks consist of injecting malicious client-side scripts into a website and using the website as a propagation method.
The risks behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page.
XSS is present in about two-thirds of all applications.
Generally, XSS vulnerabilities require some type of interaction by the user to be triggered, either via social engineering or via a visit to a specific page. If an XSS vulnerability is not patched, it can be very dangerous to any website.
Imagine you are on your WordPress wp-admin panel adding a new post. If you are using a plugin with a stored XSS vulnerability that is exploited by a hacker, it can force your browser to create a new admin user while you’re in the wp-admin panel or it can edit a post and perform other similar actions.
An XSS vulnerability gives the attacker almost full control of the most important software of computers nowadays: the browsers.
Back in 2017, our research team disclosed a stored XSS vulnerability in the core of WordPress websites. Remote attackers could use this vulnerability to deface a random post on a WordPress site and store malicious JavaScript code in it.
According to the OWASP Top 10, there are three types of cross-site scripting:
There are technologies like the Sucuri Firewall designed to help mitigate XSS attacks. If you are a developer, here is some insight on how to identify and account for these weaknesses.
Preventive measures to reduce the chances of XSS attacks should take into account the separation of untrusted data from active browser content. OWASP guidelines gives some practical tips on how to achieve it:
Note
The OWASP Top 10 noted that this security risk was added by an industry survey and not based on quantifiable data research.
Every web developer needs to make peace with the fact that attackers/security researchers are going to try to play with everything that interacts with their application–from the URLs to serialized objects.
In computer science, an object is a data structure; in other words, a way to structure data. To make it easier to understand some key concepts:
According to OWASP guidelines, here are some examples of attack scenarios:
a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
An attacker changes the serialized object to give themselves admin privileges:
a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
One of the attack vectors presented by OWASP regarding this security risk was a super cookie containing serialized information about the logged-in user. The role of the user was specified in this cookie.
If an attacker is able to deserialize an object successfully, then modify the object to give himself an admin role, serialize it again. This set of actions could compromise the whole web application.
The best way to protect your web application from this type of risk is not to accept serialized objects from untrusted sources.
If you can’t do this, OWASP security provides more technical recommendations that you (or your developers) can try to implement:
These days, even simple websites such as personal blogs have a lot of dependencies.
We can all agree that failing to update every piece of software on the backend and frontend of a website will, without a doubt, introduce heavy security risks sooner rather than later.
For example, in 2019, 56% of all CMS applications were out of date at the point of infection.
The question is, why aren’t we updating our software on time? Why is this still such a huge problem today?
There are some possibilities, such as:
This might be a little too dramatic, but every time you disregard an update warning, you might be allowing a now known vulnerability to survive in your system. Trust us, cybercriminals are quick to investigate software and changelogs.
Whatever the reason for running out-of-date software on your web application, you can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for the cases where patching is not possible.
Virtual patching affords websites that are outdated (or with known vulnerabilities) to be protected from attacks by preventing the exploitation of these vulnerabilities on the fly. This is usually done by a firewall and an intrusion detection system.
Vulnerable applications are usually outdated, according to OWASP guidelines, if:
You can subscribe to our website security blog feed to be on top of security issues caused by vulnerable applications.
Some of the ways to prevent the use of vulnerable components are:
The importance of securing a website cannot be understated. While 100% security is not a realistic goal, there are ways to keep your website monitored on a regular basis so you can take immediate action when something happens.
Not having an efficient logging and monitoring process in place can increase the damage of a website compromise.
Here at Sucuri, we highly recommend that every website is properly monitored. If you need to monitor your server, OSSEC is freely available to help you. OSSEC actively monitors all aspects of system activity with file integrity monitoring, log monitoring, root check, and process monitoring.
According to OWASP, these are some examples of attack scenarios due to insufficient logging and monitoring:
Keeping audit logs are vital to staying on top of any suspicious change to your website. An audit log is a document that records the events in a website so you can spot anomalies and confirm with the person in charge that the account hasn’t been compromised.
Whatever the reason for running out-of-date software on your web application, you can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for the cases where patching is not possible.
We know that it may be hard for some users to perform audit logs manually. If you have a WordPress website, you can use our free WordPress Security Plugin to help you with your audit logs. The plugin can be downloaded from the official WordPress repository.
The Sucuri Website Security Platform has a comprehensive website monitoring solution that includes:
The Sucuri Website Security Platform can protect your site from the top 10 website threats and security risks. Sign up to have peace of mind.
Say on top emerging website security threats with our helpful guides, email, courses, and blog content.
Sucuri Cookie Policy
See our policy>>
Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.