2023 Candidate List
- Broken Object Level Authorization
- Broken Authentication
- Broken Object Property Level Authorization
- Unrestricted Resource Consumption
- Broken Function Level Authorization
- Server Side Request Forgery
- Security Misconfiguration
- Lack of Protection From Automated Threats
- Improper Assets Management
- Unsafe Consumption of APIs
Broken authentication and authorization
Broken authentication and authorization continue to be major concerns in API security. BOLA, also known as IDOR, remains a widespread issue due to insufficient object-level authorization checks. Broken authentication, on the other hand, arises from two key factors:
- Lack of protection mechanisms for authentication endpoints.
- Misimplementation of authentication mechanisms.
This often results from the complexity of applications or a misunderstanding of the threats.
Broken Object Property Level Authorization (BOPLA)
Moving down the list we see Broken Object Property Level Authorization (BOPLA). Both excessive data exposure and mass assignment are now part of this category. It essentially outlines how attackers can exploit endpoints by accessing or modifying object properties without proper authorization. This issue occurs when an application validates user access to functions and objects, but fail at validating access to specific properties within objects.
If you want more details on Mass Assignment which is part of this category, you can check out our previous post here.
Server-Side Request Forgery (SSRF)
Following the OWASP Top 10 2021, SSRF has appeared. This is a clear indication of the growing use of unvalidated user-supplied URLs. But why is this an increasing issue?
- Webhooks and file fetching from URLs require developers to access external resources based on user input.
- Modern technologies like cloud providers, Kubernetes, and Docker expose management and control channels over HTTP on predictable paths making them targets for SSRF.
- The connected nature of modern applications makes it challenging to limit outbound traffic.
Lack of Protection from Automated Threats
Lack of protection from automated threats in APIs is a growing concern. These attacks are difficult to identify as individual requests appear legitimate and traditional protections like rate limiting and captchas become less effective over time.
Often, vulnerable APIs expose sensitive functionality without considering the potential harm caused by excessive automated access. Identifying sensitive business flows can be tricky, however, with proper design and threat modelling it can likely be minimised. An interesting example of this can be found below, as this person had an entire section of the stadium to himself; it wasn’t exactly automated but really highlights the issue here.
Where is injection?
It’s interesting to see the shift in the application security landscape where injection was once at the top of everyone’s checklist and now it’s gone. The unsafe consumption of APIs does reference injection attacks but is actually more to do with APIs interacting with one another.
Another interesting point for this section is that it’s essentially a trust issue. Data coming from another API should be treated the same as data coming from a user. In previous training, I’ve also touted to teams that they should treat other teams within the same organization as a third party. Just because you are following the guidelines and best practices does not mean they are; this is of particular importance in larger enterprises.
If you want to find our more about hacking APIs, head over to https://academy.tcm-sec.com/p/hacking-apis or join us live every Tuesday for our AppSec Live Stream https://www.youtube.com/@TCMSecurityAcademy/streams.