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 remediate 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.
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.
In this lesson, you will learn how to remediate 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.
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.
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."
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.
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!
