Skip to content

Commit 18d2594

Browse files
committed
chore(2023): Risk rating review + proofreading
1 parent 08b95de commit 18d2594

10 files changed

+20
-20
lines changed

2023/en/src/0xa1-broken-object-level-authorization.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API1:2023 Broken Object Level Authorization
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **3** : Detectability **2** | Technical **3** : Business Specific |
7-
| Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request. Object IDs can be anything from sequential integers, UUIDs, or generic strings. Regardless the data type, they are easy to identify in the request target (path or query string parameters), requests headers, or even as part of the request payload. | This issue is extremely common in API-based applications because the server component usually does not fully track the client's state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access. In most cases threat agents have full control over the request data, including object IDs. The server response is enough to understand whether the request was successful. | Unauthorized access to other users' objects can result in data disclosure to unauthorized parties, data loss, or data manipulation. Under certain circumstances, unauthorized access to objects can also lead to full account takeover. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Easy** | Technical **Moderate** : Business Specific |
7+
| Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request. Object IDs can be anything from sequential integers, UUIDs, or generic strings. Regardless of the data type, they are easy to identify in the request target (path or query string parameters), request headers, or even as part of the request payload. | This issue is extremely common in API-based applications because the server component usually does not fully track the client’s state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access. The server response is usually enough to understand whether the request was successful. | Unauthorized access to other users’ objects can result in data disclosure to unauthorized parties, data loss, or data manipulation. Under certain circumstances, unauthorized access to objects can also lead to full account takeover. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa2-broken-authentication.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API2:2023 Broken Authentication
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **3** : Business Specific |
7-
| The authentication mechanism is an easy target for attackers since it's exposed to everyone. Although more advanced technical skill may be required to exploit some authentication issues, exploitation tools are generally available. | Software and security engineers misconceptions regarding authentication boundaries and inherent implementation complexity make authentication issues of some sort prevalent. Exploitation tools are generally available or they are easy to create. | Attackers can gain control of other users' accounts in the system, read their personal data, and perform sensitive actions on their behalf. Systems are unlikely to be able to distinguish attackers' actions from legit user ones. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Severe** : Business Specific |
7+
| The authentication mechanism is an easy target for attackers since it's exposed to everyone. Although more advanced technical skills may be required to exploit some authentication issues, exploitation tools are generally available. | Software and security engineers misconceptions regarding authentication boundaries and inherent implementation complexity make authentication issues prevalent. Methodologies of detecting broken authentication are available and easy to create. | Attackers can gain complete control of other users accounts in the system, read their personal data, and perform sensitive actions on their behalf. Systems are unlikely to be able to distinguish attackers actions from legitimate user ones. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa3-broken-object-property-level-authorization.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API3:2023 Broken Object Property Level Authorization
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **2** : Business Specific |
7-
| Regular API requests to existing endpoints aimed to return objects are usually enough to get access to all object properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may required crafted requests to specify what properties should be returned. Identifying additional properties that can be manipulated requires more effort but there are a few automated tools available to assist in this task. | Relying on the API client to filter response data is more common than allowing users to manipulate object's properties which they're not supposed to. Inspecting API responses is enough to identify sensitive information in returned objects' representations. Fuzzing is usually used to identify additional (hidden) properties. Whether they can be changed is a matter of crafting API request and perform API response analysis. Side-effect analysis may be required if target property is not returned in the API response. | Unauthorized access to object properties not meant to be manipulated by users/API clients can result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privileges escalation or even full account takeover. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Moderate** : Business Specific |
7+
| APIs tend to expose endpoints that return all object’s properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may require crafted requests to specify which properties should be returned. Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task. | Inspecting API responses is enough to identify sensitive information in returned objects’ representations. Fuzzing is usually used to identify additional (hidden) properties. Whether they can be changed is a matter of crafting an API request and analyzing the response. Side-effect analysis may be required if the target property is not returned in the API response. | Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa4-unrestricted-resource-consumption.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API4:2023 Unrestricted Resource Consumption
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **2** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
7-
| Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. Most of the automated tools available are designed to cause DoS via high loads of traffic, impacting APIs' service rate. | It's common to find APIs that do not limit client interactions or resource consumptions. Crafted API requests, such as those including parameters that control the number of resource to be returned and performing response status/time/length analysis should allow to identify the issue. The same is valid of batched operations. Although threat agents don't have visibility over costs impact, this can be inferred based on service providers (e.g. cloud provider) business/pricing model. | Exploitation can lead to DoS due to resource starvation, but it can also lead to operational costs increase such as those related to the infrastructure due to higher CPU demand, increasing cloud storage needs, etc. |
6+
| API Specific : Exploitability **Average** | Prevalence **Widespread** : Detectability **Easy** | Technical **Severe** : Business Specific |
7+
| Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. Most of the automated tools available are designed to cause DoS via high loads of traffic, impacting APIs service rate. | It's common to find APIs that do not limit client interactions or resource consumption. Crafted API requests, such as those including parameters that control the number of resources to be returned and performing response status/time/length analysis should allow identification of the issue. The same is valid for batched operations. Although threat agents don't have visibility over costs impact, this can be inferred based on service providers (e.g. cloud provider) business/pricing model. | Exploitation can lead to DoS due to resource starvation, but it can also lead to operational costs increase such as those related to the infrastructure due to higher CPU demand, increasing cloud storage needs, etc. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa5-broken-function-level-authorization.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API5:2023 Broken Function Level Authorization
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
7-
| Exploitation requires the attacker to send legitimate API calls to an API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles or groups and complex user hierarchies (e.g. sub-users, or users with more than one role). It's easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g. replacing the HTTP method from GET to PUT, or changing the "users" string in the URL to "admins"). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack and may lead to data disclosure, data loss, or data corruption. Ultimately, it may lead to service disruption. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Severe** : Business Specific |
7+
| Exploitation requires the attacker to send legitimate API calls to an API endpoint that they should not have access to as anonymous users or regular, non-privileged users. Exposed endpoints will be easily exploited. | Authorization checks for a function or resource are usually managed via configuration or code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles, groups, and complex user hierarchies (e.g. sub-users, or users with more than one role). It's easier to discover these flaws in APIs since APIs are more structured, and accessing different functions is more predictable. | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack and may lead to data disclosure, data loss, or data corruption. Ultimately, it may lead to service disruption. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa6-server-side-request-forgery.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API6:2023 Server Side Request Forgery
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **2** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
7-
| Exploitation requires the attacker to find an API endpoint that receives a URI as a parameter and then accesses the provided URI. In general basic SSRF (when the response is returned to the attacker) is easier to exploit than Blind SSRF in which the attacker has no feedback whether or not the attack was successful. | Modern concepts in application development encourage developers to access URIs provided by the client, whilst URL parsing inconsistencies are well-known for most common programming languages' built-in functions and libraries. Regular API request including special crafted URLs (e.g. internal/private/well-known IP addresses) and response analysis will be required to detect the issue. When the response is not returned (Blind SSRF), confirming the vulnerability requires more effort and creativity. | Successful exploitation might lead to internal services enumeration (e.g. port scanning) or information disclosure, bypassing firewalls or other security mechanisms. In some cases, it can lead to DoS or the server being used as a proxy to hide malicious activities. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Moderate** : Business Specific |
7+
| Exploitation requires the attacker to find an API endpoint that accesses a URI that’s provided by the client. In general, basic SSRF (when the response is returned to the attacker), is easier to exploit than Blind SSRF in which the attacker has no feedback on whether or not the attack was successful. | Modern concepts in application development encourage developers to access URIs provided by the client. Lack of or improper validation of such URIs are common issues. Regular API requests and response analysis will be required to detect the issue. When the response is not returned (Blind SSRF) detecting the vulnerability requires more effort and creativity. | Successful exploitation might lead to internal services enumeration (e.g. port scanning), information disclosure, bypassing firewalls, or other security mechanisms. In some cases, it can lead to DoS or the server being used as a proxy to hide malicious activities. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa7-security-misconfiguration.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API7:2023 Security Misconfiguration
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
7-
| Attackers will often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system. Most of this is public knowledge and exploits may be available. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can not only expose sensitive user data, but also system details that can lead to full server compromise. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Easy** | Technical **Severe** : Business Specific |
7+
| Attackers will often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system. Most of this is public knowledge and exploits may be available. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations not only expose sensitive user data, but also system details that can lead to full server compromise. |
88

99
## Is the API Vulnerable?
1010

2023/en/src/0xa8-lack-of-protection-from-automated-threats.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@ API8:2023 Lack of Protection from Automated Threats
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
6-
| API Specific : Exploitability **3** | Prevalence **3** : Detectability **1** | Technical **1** : Business Specific |
7-
| Exploitation usually involves understanding the business model backed by the API, finding sensitive business flows, and automating access to these flows, causing harm to the business. | Lack of an holistic view of the API in order to fully support business requirements tend to contribute to the prevalence of this issue. Attackers need to identify what resources (e.g. endpoints) are involved in the target workflow and how they work together. If mitigation mechanisms are already in place, attackers need to find a way to bypass them. | In general technical impact is not expected. Exploitation might hurt the business in different ways, for example: prevent legitimate users from purchasing a product, or lead to inflation in the internal economy of a game. |
6+
| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Average** | Technical **Moderate** : Business Specific |
7+
| Exploitation usually involves understanding the business model backed by the API, finding sensitive business flows, and automating access to these flows, causing harm to the business. | Lack of a holistic view of the API in order to fully support business requirements tends to contribute to the prevalence of this issue. Attackers manually identify what resources (e.g. endpoints) are involved in the target workflow and how they work together. If mitigation mechanisms are already in place, attackers need to find a way to bypass them. | In general technical impact is not expected. Exploitation might hurt the business in different ways, for example: prevent legitimate users from purchasing a product, or lead to inflation in the internal economy of a game. |
88

99
## Is the API Vulnerable?
1010

0 commit comments

Comments
 (0)