The OWASP top 10 describes the top 10 vulnerabilities as they were found in production environments for a particular year. While this is a good approach, it fails to take the impact of an issue into account. For example, being able to register an account for a webshop is expected but being able to register for a private website is something that can have quite a lot of impact.

The OWASP top 10 also looks at all the websites but it has been talked about so often that you can find a host of references online though they will be more general than one would expect. For example, the topic "Injections" covers a range of different vulnerabilities but it's better to talk about specific vulnerabilities in some cases, especially when it comes to bug bounties.

1. Broken Access Control (Including IDORs)

What is it?

These days, almost all the modern dynamic web applications are reliant on both authentication systems which determine what users are logged in and authorization which checks if a certain user is allowed to execute certain functionality. For example as a regular user who might not be able to create new users under normal operations, but due to a Broken Access Control issue, they might be able to make the API directly which indicates only the UI elements have been hidden. 

Please note this issue type can exist on any resource that the attacker should not be authorised to see, For example, an internal helpdesk that the user might get access to due to the x-forwarded by header. Some servers only check this header and not the origin IP address.

IDORs are a type of Broken Access Control (BAC). The term has been made popular by being included in the OWASP top 10 but this is just an example of vertical or horizontal privilege escalation. The distinction between horizontal and vertical BAC is important to make as horizontal BAC includes functionality which the user is able to use but only with their own data while vertical BAC includes functions that the attackers do not have access to at all.

How can it be abused?

When this vulnerability has been discovered the flaw is fairly easy to take advantage of. We simply need to execute the requests and depending on what functionality and HTTP method (POST, GET, PUT, ...) the severity rises. We need to ensure business-critical applications are also clear so the severity can be raised accordingly.

To abuse this the attacker simply has to repeat the vulnerable calls and the attackers can actually do this using simple developers tools, such as Postman.

How to protect against it?

We need to create a proper authorisation matrix to determine for every role level what their available options are per component and we need to make sure we keep all of the CRUD actions in mind. For example:

What CRUD stands for is Create, Read, Update and Delete. We need to use this matrix to implement the correct authorization controls. When we do so we also need to pay special attention we only create 1 authorization control system and inherit it everywhere we need it.

2. Cryptographic failures

What is it?

This category describes all related to cryptography. Cryptography is the art of protecting information through the use of codes. An example of this is when you register for a website and enter a password. This password should never get stored in the database in clear text as it would make it much too easy for hackers to log in as anybody with all the consequences that come of it. The fact that most people use the same password for every website would make not having enough cryptography a really bad thing and unfortunately, it still occurs way too often. 

How can it be abused?

Not only is this a serious security risk when an attack can already compromise a system fully, but abuse can also come from anywhere. If your data is not properly encrypted when sent across the internet, someone might try to intercept it. This is especially prevalent with public wifi hotspots but attackers get more sophisticated every day and they’ve even been known to spoof the names of wifi routers that you have previously connected to which might prompt your devices to spontaneously connect. If an attacker can successfully pull this off and sniff unencrypted traffic, they might be able to steal names, email addresses or credit card numbers.

How to protect against it

Protecting against this vulnerability type is not an issue task. We need to be very meticulous about indexing what data is important to users and which is sensitive. Both should be treated with the utmost care and respect and should therefore be encrypted whenever transmitting over the internet or stored. Besides protecting the customer’s data, we need to ensure we do it well and use a strong encryption algorithm. For which ones to pick, make sure you do your due diligence because new security flaws keep getting discovered daily.

3. Injection

What is it?

Injection sounds like a very broad term and you’d be right in thinking that. I was confused when I first heard it as it seems like a rather broad amount of things can fall under injection. One famous example is the “command injection” vulnerability which can trigger quite impactful bugs. We’ll get more into that specific example later on. 

They occur because attackers can insert pieces of code that interfere with the normal workings of an application such as pieces of SQL code used to grab or insert objects into a database or even OS commands to hack a complete server. 

How can it be abused? 

Usually, when you enter something into an application, the developers of that application should sanitize your input because if they don’t, you can insert malicious fragments of code as an attacker. This can lead to all kinds of unexpected and unwanted behavior like the deletion/modification of data or executing malicious commands which interfere with the rights and privileges of the users on a system (This is called an LDAP injection). 

How to protect against it

With this vulnerability category, it is key that developers properly validate input and reject it if it does not meet the criteria. This may seem obvious at first but with thousands of endpoints and even more parameters that users can control, the task suddenly becomes a lot harder. When you then consider that some of these parameters might not be as obvious to detect it becomes crystal clear why this issue type is high on the list. 

4. Insecure design

What is it?

Securing an application starts with designing it properly from the ground up. Neglecting to do so will result in an insecure design which is usually far worse than what people give it credit for. The biggest problem is that the later in the SDLC (Software Development Lifecycle) we detect a vulnerability or an issue, the more it will cost to repair it. These design flaws usually go as unnoticed as well because they are domain and even application-specific in some cases.

How can it be abused? 

Since so many issues can fall under this category, it will depend on what type of vulnerability is exactly being abused. A simple design flaw could be to not have validation that is easy to spot and fix but high in impact. At the same time, a more advanced vulnerability could be the lack of design patterns such as a security factory pattern which tells us we should keep all of our security code in a separate module that can be called from anywhere within the application. To abuse this, we don’t have one specific scenario but rather a range of different things that can occur. 

How to protect against it?

There is a big movement going on at the moment pushing for more secure design coding practices and design patterns. They advocate to properly educate developers and testers as to what design patterns exist and how they can apply them to their projects. 

5. Security misconfiguration

What is it? 

The complex systems that are set up to facilitate all the functionality required by applications require a fair bit of configuration. All this comes with the added requirements of in-depth knowledge of how to configure all the complex systems that we need. I’m talking about AWS for example which is making a big rise if you misconfigure your “s3 bucket” (A place to store objects such as pictures for example) you might expose the documents of users to the world without them knowing. 

How to abuse it?

First of all, it is really important that we get an overview of what technologies are being used. Next, we can try to figure out if there are any security misconfigurations that can occur by diving into the manual. If the application can be configured incorrectly, that’s the first thing we will test for but knowing it is not configured correctly is quite a challenge in and of itself. This can vary from project to project as some “s3 buckets” on AWS for example are supposed to contain publicly available assets like profile pictures while at the same time we can configure it to protect other users assets. This duality brings an extra layer of complexity that attackers will gladly take advantage of. 

How to protect against it? 

Misconfigurations mostly find their origin in sysadmins either not knowing exactly what to configure or how different configurations interfere with one another. To prevent this, proper training with a focus on the security features of an application and how to configure them is a must before deploying anything to a production environment. It’s also crucial to always have an overview of all the components that make up a system and check every configuration change for interferences.

6. Vulnerable and Outdated Components

What is it?

Modern-day applications are no longer isolated units running without any libraries. These days, applications rely on all sorts of components and libraries. While this is not an issue itself, it becomes dangerous when these components stack up as it’s easy to lose sight of them. Any outdated component that is simply forgotten because “the application works” can be very dangerous. When a library or component brings out an update, it usually also contains some security updates as well and if we neglect to install these updates, we are opening ourselves up for big security holes through 3rd party components. 

How can it be abused?

Depending on what component is outdated and vulnerable, the method of exploitation will also change. One often forgotten component most modern web applications use is JQuery. Not updating that can lead to XSS vulnerabilities. These issues can have a broad range of impacts such as stealing a person’s data or even their full account. 

Another set of often forgotten components are WordPress plugins. Not updating these can even lead to arbitrary code execution which in turn could lead to an entire network being compromised.

How to protect against it? 

It’s important to have a good inventory management system in which you register all the external and even internal components being used. Libraries, Integrations, any component needs to be noted and updated properly. This means that for some components, we will need to update them at our earliest convenience while others warrant an immediate update. Preferably this should be done by automatic scans that run periodically combined with a healthy dose of human skepticism.

7. Identification and Authentication Failures

What is it? 

When using an application's features, we can notice some are locked away and you need to make an account before accessing them. This combined with good authorization (Making sure you actually are who you say you are) can be a great way to control access to our applications. If one of these components fails, however, we can have a security vulnerability that is quite impactful. Usually, attackers will attack the authentication section of an application since gaining access to accounts is a hacker’s ultimate goal. They will usually do this by exploiting weaknesses in the authentication system which allows them to attack and hack certain accounts.

How to exploit it?

There are certain techniques hackers use to break into accounts. One of these techniques is credential stuffing for example, where they will try to log into your application with a list of already compromised accounts from a previous hack. This works so well because people generally only use 1 password for all applications which means that if an attacker can crack that password in 1 location, it might be valid in other places as well. 

This can be made worse if multi-factor authentication is not enabled. (This is where we add another layer of authentication on top of the username/password system, making a compromised account far less likely, even if the attackers can get the password.

How to prevent it?

Prevention starts by making sure our applications follow secure design principles such as multi-factor authentication and the enforcement of strong passwords. When we have those implemented, we should make it as hard as possible for any potential attacker by rate-limiting the login attempts someone can make. We also need to encrypt the passwords of our users when we store them. If an attacker manages to steal them, they are not useful anymore. 

8. Software and Data Integrity Failures

What is it?

When programming, data is often passed between components to integrate many smaller pieces into a bigger system. Problems occur when this data is user-controllable as they might be able to insert their own code into the integration points. When operating normally, software and data should always be validated before executing. This will prevent unintended vulnerabilities as the system simply won’t execute any other code/software that is not what is expected. This is often done by assigning a checksum where something like an MD5 hash will be calculated of the software/data to be executed.

How can it be abused? 

Abusing this issue type often requires another one to create a real impact as the category is mostly focused on lowering the impact of any potential attack but direct attacks such as insecure deserialization are also possible. When objects are sent between components of an application, we can send that object over in serialized form. You probably know JSON as a great example of serialization and deserialization. Attackers can either manipulate the properties of an object or even abuse hidden properties to create possibly even more impact.

Another way this issue is often abused is by taking advantage of our target not checking the integrity of updates. Attackers can come along and insert their own updates into the system which might get executed if they are not properly verified. 

How to prevent it?

Wherever system updates happen and where software is being used, we have to ensure that we are verifying the integrity. The same goes for any serialized objects used by the application. One possible attack vector that is often being used are the CD/CI pipelines so we have to ensure proper access control is being applied and that they verify the integrity of the software they are running. With this knowledge in mind, we can see that we need to take care in using external libraries as well, they should only ever come from trusted sources and repositories. 

9. Security Logging and Monitoring Failures

What is it? 

All of the issue types on this list have been focused on attacking an application but when those attacks inevitably happen, you need to be prepared and have proper logging in place to detect any hacking attempts. This alone is not sufficient however, good logging is useless if there is nobody to monitor it. Failure to do so could leave you blind in case of an attack. This monitoring should occur both passively and actively by allowing tools to do the bulk of the work and checking their work manually on a regular basis to ensure they are still performing as intended. These systems should be tested regularly as well. 

How can it be abused? 

Attackers need to stay undetected for as long as possible to snoop around and execute their attacks. This is made much easier if their targets do not have proper logging and monitoring in place. This includes holiday periods like the summer when there might not be anyone available to monitor these logs. 

How to prevent this?

We need to implement a strong logging and monitoring plan that is checked on a regular basis and tested. The system should monitor for and alert the responsible people whenever an attack happens. 

10. Server-side request forgery (SSRF)

What is it?

Server-side request forgery is an attack technique that can be leveraged to reach internal resources that should not be accessed externally such as admin pages or intranets for example. This is just one of the uses of SSRF and if allowed to run rampant, this issue type can even cause the execution of arbitrary code. In this instance, a server is tricked into performing a request to the internal resource and since it’s the server making the request, it will appear to come from the internal network. 

How can it be abused?

For this specific vulnerability type, attackers will be looking for parameters of the web application which contain a full or partial URL that is being resolved. They will try to get that parameter to be manipulated and the process to send a request on their behalf. This will usually be aimed internally to scan out the internal network if the attacker does not know about any resources restricted to internal access only.

How to prevent it?

We can either protect from this issue by the network layer or the application layer. On the network level, we are going to make our firewalls block any request by default unless we approve it explicitly. 

On the application level, the best way to prevent this issue is to properly sanitise the user input and make sure only expected input is allowed. We also want to Disable HTTP redirections and we do not send raw responses to clients.