In the past, the OWASP Top 10 was exclusively a list of the top web application vulnerabilities. However, in the last year, OWASP has changed from focusing exclusively on vulnerabilities to categories in an attempt to focus on the root cause of the security issues rather than the symptoms. Going forward OWASP will feature categories/groups of vulnerabilities that companies need to address to ensure the security of their applications rather than individual vulnerabilities. In this article, we’re going to look at some of the biggest changes to the OWASP Top 10 in 2021.

Examples of these Changes in the New OWASP Top 10

Categories of risk in the OWASP top 10 are structured so that each category has multiple CWEs associated with them. A CWE stands for common weakness enumeration, and it is a category of hardware or software vulnerabilities. In the OWASP top 10 2021 iteration, there are roughly 20 different CWEs per category. This means that every category represents multiple potential vulnerabilities that an organization needs to consider. Let’s look at three examples of OWASP top 10 changes from 2021:

1) Broken Access Control: Moving up from the fifth position to the number 1 spot is broken access control. 94% of applications were tested by OWASP for broken access control with an average incidence rate of 3.81%. This category has 34 CWEs mapped to it including CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Insertion of Sensitive Information Into Sent Data, and CWE-352: Cross-Site Request Forgery.

2) Cryptographic Failure: This vulnerability was previously known as Sensitive Data Exposure and focuses on failures related to cryptography. This category has 29 CWEs mapped to it and some of them include Notable Common Weakness Enumerations (CWEs) included are CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy.

3) Injection: In the third spot on the OWASP top 10 is an injection (injection-based attacks). 94% of applications were tested for this type of attack and 19% of applications were found vulnerable. This category has 33 CWEs mapped to it including CWE-79: Cross-site Scripting, CWE-89: SQL Injection, and CWE-73: External Control of File Name or Path.

These are examples of three of the most popular categories according to OWASP. Each of these categories includes multiple CWEs which will address the specific attacks/vulnerabilities that web applications need to address. Let’s look on a more granular level at some of the specific attacks that the CWEs cover.

SQL Injection

SQL injection, which was previously on the list of OWASP top 10 is now a CWE under the category of injection. An SQL injection is simply when an attacker uses SQL code to extract information from the backend database. This is done by entering the code into an input form in the web application. If the input form doesn’t properly filter user input, then that code will be executed and the SQL injection attack will be successful. Let’s look at an example from OWASP:

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:

http://example.com/app/accountView?id=' or '1'='1

The result of these queries is that it will return all of the records from the account table. Allowing the attacker to see, modify or delete data from the database.

Command Injection 

This is an attack where the goal is to execute an arbitrary command on the host operating system of a vulnerable application. Similar to a SQL injection this type of attack is only possible when an application passes unsafe user-supplied data to the backend system. Here’s an example provided by Imperva of a command injection attack:

Manipulating APPHOME Environment Variable

...

char* home=getenv("APPHOME");

char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));

if (cmd) {

strcpy(cmd,home);

strcat(cmd,INITCMD);

execl(cmd, NULL);

}

How Businesses Need to Respond to this Shift in Focus

For businesses that leverage the OWASP top 10 this change in approach requires businesses to shift their focus from individual vulnerabilities to the root causes. This requires proactive planning on the part of the business. It’s very difficult to fix an application that is built poorly, it’s preferable to build an application that is secure by design and to continuously improve. Here are some tips on how you can do this:

Practicing Secure Coding (Developer training)

The first step is to understand why developers need to be aware of OWASP changes. While developers are experts in writing functionality software most of them are not experts in creating secure code. It’s important to shift the focus by training your developers on the best secure coding practices. This will reduce the likelihood that developers will introduce vulnerabilities into your application during development. This begins with training, but you can also use software tools to help detect potential vulnerabilities in your source code. There are two types of tools that you should use: 1) static analysis tools and 2) Dynamic Analysis tools. Static analysis tools will examine the source code itself for any signs of insecure code. Dynamic Analysis tools will test the code at runtime for any security issues. You should also do application fuzzing, which is where you feed the application junk data to see if it returns any errors or leaks any sensitive information. Finally, you should have a manual review of your source code done by a security expert to ensure that your application code is written securely.

Integration Penetration Testing

Once you have a solid foundation of secure coding you should have formal penetration tests done to test that your application will be able to withstand attacks by actual computer hackers. Penetration testing will identify areas of improvement that your team can correct to further protect your application. You can do this in one of two primary ways: Firstly, you can hire professional penetration testers to do a one-time security assessment of your application. This is great for a point in time assessment and gives you recommendations for improvement but it’s not a going process. The second option is to use a bug bounty program, this is a program where you promise people rewards for identifying bugs that they find in your application. Companies like Yahoo, Facebook, Sony, and PayPal all have bug bounty programs. It’s a great way to get consistent feedback on the security of your application and you only have to pay when someone submits a report that meets the criteria that you set. 

Integrating DevSecOps

DevSecOps stands for Development, Security, and Operations. It focuses on integrating security operations into the full life cycle of your applications. In some companies, the role of security was isolated to a specific team towards the end of the SDLC. However, to better create secure applications security must be integrated into all phases of the SDLC. Another important aspect of DevSecOps is the use of automation. Where possible companies should look to automate security processes to ensure better repeatability and to prevent security procedures from slowing down the development process. 

Conclusion

The OWASP top 10 is one of the most popular frameworks for web application security. Traditionally it featured the 10 most common web application attacks and how to defend against them. However, they have now pivoted away from individual threats to focus on categories of cyber threats. This means that the focus is now on how to treat the root cause of web application vulnerabilities instead of the symptoms. What this means for businesses is that the focus should be on creating applications that are secure by design and fixing the underlying issues within your applications so that multiple vulnerabilities within each category can be addressed simultaneously. To begin the process of fixing these underlying issues we recommend three steps. First, you need to implement secure coding training for your developers so that they are educated on how to write secure code. Secondly, you need to implement penetration testing for your application so that security professionals can test your application’s ability to withstand attack. Lastly, implement DevSecOps so that security processes are used throughout your applications’ development lifecycle, not just at the end.