Testing OWASP’s Top 10 API Security Vulnerabilities (Part 1)

Application Programming Interface (API) attacks are set to become one of the most prevalent cyberattacks with a broad target range. By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII), causing APIs to become a target for attackers. In 2019, Gartner predicted that API hacks would become the most common form of cyberattacks in 2022. So how can teams stay ahead of API attacks? One answer is by implementing a strong API security strategy that focuses on developer education.

Upskilling developers is a key part of a strong API security strategy

API security strategies help organizations focus on solutions to understand and mitigate the unique vulnerabilities and security risks of APIs. When designing an API security strategy, it’s imperative to look at the experience and training of the developers and determine what they know about API security. Developers are the key to quality – they’re building and fixing applications that we rely on daily. One of the best places to start applying security tactics is actually in development.

Take a look at the OWASP Top 10 API Security Vulnerabilities List. The list outlines the top API vulnerabilities, detailing what these vulnerabilities are, how they occur, and how to prevent them. In this series, we’re using Veracode Security Labs, a developer tool for hands-on secure code training that uses real, containerized APIs and apps, to test and mitigate each vulnerability on the OWASP API Top 10 list. With security labs, developers can explore lessons to help familiarize themselves with vulnerabilities and gain experience identifying issues in code and fixing flaws.

Let’s get started:

API1: 2019 Broken Object Level Authorization

Object-level authorization is the process of verifying if an authenticated user has permission to access an object, what actions they are allowed to perform over the object, and the limits related to performing the action. These kinds of checks are important to reduce exposing objects to malicious attackers.

Object-level authorization vulnerabilities can occur when domain object identifiers are exposed. The best way to remedy this vulnerability is to establish access control using a secure authorization process. To further increase security and avoid creating easy-to-guess identifiers, you should also assign random and unpredictable identifiers to your objects.

API Image

One ID to access all objects

The sample API provided in this lesson represents the back end of a bank. It will be used to demonstrate how an attacker can access the financial information of other users when object-level authorization checks are not in place.

API Image 2

In this lesson, you will learn how to remedy this vulnerability to protect the objects from unauthorized clients.

Stronger IDs

The sample API provided in this lesson represents the back end of a bank. It is used to demonstrate how a malicious user can identify an ID sequence. This allows them to guess another ID and try to access other objects, or to collect useful information to be used in subsequent attacks.

API Image 3

In this lesson, you will learn how to create stronger object IDs, to discourage malicious users from being able to attack your API at the object level.

API2: 2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. Compromising a system’s ability to identify the client / user, compromises API security overall.

API Image 4

Really, really bad passwords

Authentication is the process of verifying ** who ** someone is. Commonly the term “user” is used to refer not only to a person but to a machine that is going to use an API and needs to be authenticated. The most widely used authentication mechanism is through what is technically called “Memorized Secret authenticator” popularly known as “password.”

API Image 5

This API uses ASP.NET Core Identity, which is a standard membership system that adds login functionality to ASP.NET Core. Identity can be configured using any Entity Framework compatible database to store usernames, passwords, and profile data. This API uses a simple in-memory database to store registered users. This lab will cover some best practices when it comes to user passwords, including sensible ways and really, really bad ways to enforce user password requirements.

Terrible password

Incredibly, many APIs store users’ passwords in plain text. You should never do that. Instead, you should convert the passwords to a meaningless string. This process is called ‘hashing’ which is a special algorithm to cipher strings, this process cannot be reversed, so if an attacker gets access to a hashed password, they cannot reverse it to the original password.

MD5 is a cryptographic hash function, popular in the past, but no longer considered secure as it is vulnerable to malicious attackers. Converting to SHA512 provides a more robust hash. Yet, common passwords can still be looked up in databases, resulting in what is called a rainbow table attack.

API Image 6

In this challenge, you will learn how attackers crack a password hashed with SAH512 using online rainbow tables, and you’ll learn how to avoid these in the future.

Interested in learning to write more secure code (or help your team learn)? Start a free trial of Security Labs Enterprise to check out more topics, challenges, and secure coding strategies. Stay tuned for Part 2 which will cover more of the OWASP API Top 10!

Source

Application Programming Interface (API) attacks are set to become one of the most prevalent cyberattacks with a broad target range. By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII), causing APIs to become a target for attackers. In 2019, Gartner predicted that API hacks would become the most common form of cyberattacks in 2022. So how can teams stay ahead of API attacks? One answer is by implementing a strong API security strategy that focuses on developer education.

Upskilling developers is a key part of a strong API security strategy

API security strategies help organizations focus on solutions to understand and mitigate the unique vulnerabilities and security risks of APIs. When designing an API security strategy, it’s imperative to look at the experience and training of the developers and determine what they know about API security. Developers are the key to quality – they’re building and fixing applications that we rely on daily. One of the best places to start applying security tactics is actually in development.

Take a look at the OWASP Top 10 API Security Vulnerabilities List. The list outlines the top API vulnerabilities, detailing what these vulnerabilities are, how they occur, and how to prevent them. In this series, we’re using Veracode Security Labs, a developer tool for hands-on secure code training that uses real, containerized APIs and apps, to test and mitigate each vulnerability on the OWASP API Top 10 list. With security labs, developers can explore lessons to help familiarize themselves with vulnerabilities and gain experience identifying issues in code and fixing flaws.

Let’s get started:

API1: 2019 Broken Object Level Authorization

Object-level authorization is the process of verifying if an authenticated user has permission to access an object, what actions they are allowed to perform over the object, and the limits related to performing the action. These kinds of checks are important to reduce exposing objects to malicious attackers.

Object-level authorization vulnerabilities can occur when domain object identifiers are exposed. The best way to remedy this vulnerability is to establish access control using a secure authorization process. To further increase security and avoid creating easy-to-guess identifiers, you should also assign random and unpredictable identifiers to your objects.

API Image

One ID to access all objects

The sample API provided in this lesson represents the back end of a bank. It will be used to demonstrate how an attacker can access the financial information of other users when object-level authorization checks are not in place.

API Image 2

In this lesson, you will learn how to remedy this vulnerability to protect the objects from unauthorized clients.

Stronger IDs

The sample API provided in this lesson represents the back end of a bank. It is used to demonstrate how a malicious user can identify an ID sequence. This allows them to guess another ID and try to access other objects, or to collect useful information to be used in subsequent attacks.

API Image 3

In this lesson, you will learn how to create stronger object IDs, to discourage malicious users from being able to attack your API at the object level.

API2: 2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. Compromising a system’s ability to identify the client / user, compromises API security overall.

API Image 4

Really, really bad passwords

Authentication is the process of verifying ** who ** someone is. Commonly the term “user” is used to refer not only to a person but to a machine that is going to use an API and needs to be authenticated. The most widely used authentication mechanism is through what is technically called “Memorized Secret authenticator” popularly known as “password.”

API Image 5

This API uses ASP.NET Core Identity, which is a standard membership system that adds login functionality to ASP.NET Core. Identity can be configured using any Entity Framework compatible database to store usernames, passwords, and profile data. This API uses a simple in-memory database to store registered users. This lab will cover some best practices when it comes to user passwords, including sensible ways and really, really bad ways to enforce user password requirements.

Terrible password

Incredibly, many APIs store users’ passwords in plain text. You should never do that. Instead, you should convert the passwords to a meaningless string. This process is called ‘hashing’ which is a special algorithm to cipher strings, this process cannot be reversed, so if an attacker gets access to a hashed password, they cannot reverse it to the original password.

MD5 is a cryptographic hash function, popular in the past, but no longer considered secure as it is vulnerable to malicious attackers. Converting to SHA512 provides a more robust hash. Yet, common passwords can still be looked up in databases, resulting in what is called a rainbow table attack.

API Image 6

In this challenge, you will learn how attackers crack a password hashed with SAH512 using online rainbow tables, and you’ll learn how to avoid these in the future.

Interested in learning to write more secure code (or help your team learn)? Start a free trial of Security Labs Enterprise to check out more topics, challenges, and secure coding strategies. Stay tuned for Part 2 which will cover more of the OWASP API Top 10!

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

YouAttest collaborates with JumpCloud to give users access reviews for identity governance

YouAttest announced their product integration with JumpCloud - an open directory platform that gives IT, security...

SLACIP: How to Comply with the SOCI ACT Reforms

On March 31, 2022, the Security Legislation Amendment Critical Infrastructure Protection Act 2022, also known as SLACIP, was passed by the Australian Parliament. ...

Microsoft patches the Patch Tuesday patch that broke authentication – Naked Security

Two of the big-news vulnerabilities in this month's Patch Tuesday updates from Microsoft were CVE-2022-26923 and CVE-2022-26931which affected the safety of authentication in Windows. Even...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!