Welcome to our OWASP top 10 api training page!


Here you will find a selection of labs you can easily start up (Since they do go down sometimes) and hack away at!

Please also have a look at our API top 10 descriptions owasp-api-top10-Explained

API1:2019 Broken Object Level Authorization

introduction

Broken Object Level Authorisation all starts with an object. Objects should be looked at in the context of "Object Oriented Programming", what I mean with that is objects are the things you think about first in designing a program and they are also the units of code that are eventually derived from the process. This can be anything, ranging from an account to an invoice to a credit note and everything in between. Usually these objects are marked with an identifier because we need to address these objects directly and this is where issue can arise because we need to always check if the user is allowed to access that object. This might seem simple at first but i can assure you it's not, more about that later in the "testing" section of this article.
A broken Object issue occurs when the server does not properly check if the currently logged in user or if a logged out user can read, update or delete an object to which they do not have the rights.
Link to OWASP github article

Open up this lab! - A1

Open up this lab! - A1-2
owasp-api-top10/API-testing.php

API2:2019 Broken User Authentication

introduction

Broken User Authentication can manifest in several issues. Whenever we come across an API endpoint that handles authentication we need to be extra careful since these endpoints will often determine how a user can flow through the application and what data they see. Whenever one of the following conditions is true, we can speak of a "Broken User Authentication
  • If your API allows for credential stuffing, This is an attack where a hacker will try to brute force credentials by using a list with known account names and password from other websites. This works because people often re-use their old usernames and passwords so if their credentials leak one time, a lot of accounts are vulnerable. Attackers will take these old credentials and try them on our API endpoints rapidly to see if any of the accounts work on our application. Rate limiting should exits.
  • If the API endoint does not verify the request with a captcha when needed
  • When the application allows for weak passwords. The best policy is to use a passphrase instead of a password but anything is better than a weak password
  • When the endpoint uses GET parameters (parameters in the URL) to send sensitive data such as passwords or tokens. This could allow for a MiTM attack.
  • When our endpoint issues a token such as JWT but does not validate it.
  • When we use JWT, we should be aware that we should not accept unsigned or weakly signed tokens.
  • When the endpoint does not validate the expiration date of authentication tokens such as session tokens or JWT
  • When the endpoint does not encrypt or hash the password or uses weak encryption algorithms.
  • When it uses weak encryption keys that are easy to guess (Like a birthday) or easy to crack (like md5)
Link to OWASP github article

In our devious labs, the username of this login page can be found straight in the HTML source code, but what about the password? Could it be SQLi?

Open up this lab! - A2
Open up this lab! - A2-2
Open up this lab! - A2-3

API3:2019 Excessive Data Exposure

introduction

An API is only supposed to return the required data to the front-end clients but sometimes developers will make a mistake or take the easy route and implement generic API's that return all data to the client. When these API's return too much data, we can speak of Excessive Data Exposure. Link to OWASP github article

Open up this lab! - A3

API4:2019 Lack of rate limiting

introduction

Whenever an API is served a request it will have to respond, to generate this response the API requires resources (CPU, RAM, network and at times even disk space) but how much are required highly depends on the task at hand. The more logic processing happens or data is returned, the more resources are taken up by a single call and this can stack on quick. If we do not rate limit our API endpoints. This issue is made even worse by the fact that most API's reside on shared hosts which means they are all fighting for the same resources which could mean the attacker is disabling a secondary unrelated API by consuming all the resources. Link to OWASP github article

Open up this lab! - A4

API5:2019 Broken Function Level Authorization

introduction

From the summary you might have been able to gather this vulnerability can be quite complex and varied. Humans are predictable in nature and they tend to follow several patterns when it comes to hosting endpoints, for example it usually occurs that higher priviledge endpoints are hosted on the same relative path, which makes it easier for the users to guess these endpoints but that alone does not make the vulnerability though. We have to be able to access to endpoints as a lower priviledged users as well of course. This access can occur by executing the provided HTTP method (for example POST) but it can also occur on other methods that the developers left enabled (un)intentionally (for example DELETE). These issues are often made worse by how predictable the endpoints are (for example /books?id=0 might indicate the presence of an endpoint /books/all which may print out books the user should not be able to access.). Link to OWASP github article

Open up this lab! - A5

API6:2019 Mass Assignment

introduction

Applications these days often rely an objects (For example user, product, ...) and these objects have properties (for example product.stock). As a user, we have the authorization to edit and view specific properties of the objects but we might also be limited and not able to edit or view some specific properties (For example user can view product.stock but user should not be able to edit product.stock). These properties are then matched to parameters on the front-end and if these conversion happen automatically, they might convert parameters to properties the attacker should not be able to access (For example, the user should never be able to edit product.title but the front-end might convert a paramter "title" to product.title if the user sends a PUT request).
Here are some more examples of properties the user should not be able to edit:
  • Account.AccountType or Account.discountsEnable. These are properties that relate to permissions.
  • Account.wallet This property should never be editable be the attacker
  • product.title These are internal properties the user should never be able to edit


Labs under construction

API7:2019 Security Misconfiguration

introduction

There are several factors that might indicate a Security Misconfiguration. We should be very careful with handling configurations because if the correct security measures are not in place to protect our APIs, an attacker might be able to take over the full infrastructure.
We have to ensure all our systems are always up to date to avoid old exploits working on our systems. Following up on this, if our systems are up to date, we have to disable any unused functions like http PUT calls.
All our data should always be transported over a TLS channel to avoid that an attacker can perform a MitM attack.
Make sure all your security headers such as CSP are working correctly and configured wherever needed. With CSP enabled we should also run a CORS policy and configure it properly or you might open yourself up to Security Misconfiguration vulnerabilities.
Furthermore as a last point we can claim that security misconfigurations happen when the end user is able to see error messages or warnings. These should only be logged and viewed internally.


Several issues have existed for this issue type on all the other labs including not sending traffic over HTTP and enabling debug mode

API8:2019 Injection

introduction

API's with the following properties are open to injection flaws:
  • When we don't sanitize the input from the front-end we are opening ourselves to a world of problems, this would allow the user to input anything which could intervene with later processes.
  • The same goes for validation and verification of the API's request, these have to be done before the data enters any kind of processes, this is where it could start causing problems for example on the login calls, make sure the API is validating, verifying and sanitizing any input.
  • Make sure that you pay attention to not just the input from the user directly, this can also come from 3rd party services or file uploads for example.
  • Take into account there might be processes such a batch jobs running that could trip over the data.


Open up this lab! - A8

API9:2019 Improper Assets Management

introduction

We should always wonder for every API if all the current endpoint should even be available and if we maybe can't do with only allowing the whole API to communicate internally. To aid us we can ask ourself if this API even needs to be in production at all and who should have access to the API. If the specific API does needs to be in production, we can also ask ourselves if we are not using an outdated version of the API, if there is sensitive data exposed or how the data flows throughout the application and APIs.
A lack of documentation is a problem that plagues many companies and this only makes things worse because an undocumented API that does not send out traffic can remain undetected for a long time.
To ease the removal of older APIs we might consider a retirement plan for APIs that are no longer needed. Another tool we have at our disposal are inventory management systems which index every API and it's version, this can be used to perform a regular inspection of the API plan.
As long as these older APIs and their libraries remain unpatched, the system will be vulnerable to Improper Assets Management.

All of our labs are currently not properly managed, it surprises me nobody has taken root of the server yet!

API10:2019 Insufficient Logging & Monitoring

introduction

The title already says a lot but this vulnerability is a bit more complexity than it was at first sight, of course the API is vulnerable if it does not create any log entries or when the log level is set incorrectly but we should not neglect to also check whether or not the contents of the log messages are what is expected and that they contain enough detail.
A second aspect that is a bit harder to control is the log integrity, for example a malicious user might insert a special character that when written to the log breaks it. This is known as log injection and it could nullify all the logging efforts made.
When we finally have a clear plan of what to log, when and on what environment we need to ensure we are monitoring these logs, failure to do so would result in a massive decrease in the efficiency of our logging efforts.
Monitor everything, not just the logs but make you monitor the APIs and the infrastructure as well.

Even if our labs got hacked, we have no logging nor monitoring to even realise it!