You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 2019/en/src/0x11-t10.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,13 +3,13 @@ OWASP Top 10 API Security Risks – 2019
3
3
4
4
| Risk | Description |
5
5
| ---- | ----------- |
6
-
| A1:2019 - Broken Object Level Authorization | APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be taken in mind in every function that accesses a data source using an input from the user. |
7
-
| A2:2019 - Broken Authentication | Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API overall security. |
8
-
| A3:2019 - Excessive Data Exposure | Looking forward to generic implementations developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before showing it to the user. Without controlling client's state, servers receive moreandmore filters which can be abused to gain access to sensitive data. |
9
-
| A4:2019 - Lack of Resources & Rate Limiting | Quite often APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only this can impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. |
10
-
| A5:2019 - Broken Function Level Authorization | Complex access control policies with different hierarchies, groups and roles and a not so clear separation between administrative and regular functions tend to lead to authorization flaws. Exploiting these issues, attackers gain access to other users resources and/or administrative functions. |
11
-
| A6:2019 - Mass Assignment | Binding client provided data (e.g. JSON) to data models without proper properties filtering based on a whitelist usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints or reading the documentation, providing additional object properties in request payloads, allow attackers to modify object properties they are not supposed to. |
12
-
| A7:2019 - Security Misconfiguration | Security misconfiguration is commonly a result of insecure default configurations, incomplete or adhoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS) and verbose error messages containing sensitive information. |
13
-
| A8:2019 - Injection | Injection flaws, such as SQL, NoSQL, Command Injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
14
-
| A9:2019 - Improper Assets Management | APIs tend to expose more endpoints than traditional web applications, what makes proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. |
15
-
| A10:2019 - Insufficient Logging & Monitoring | Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. |
6
+
| A1:2019 - Broken Object Level Authorization | APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user. |
7
+
| A2:2019 - Broken Authentication | Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall. |
8
+
| A3:2019 - Excessive Data Exposure | Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user. Without controlling the client's state, servers receive more-and-more filters which can be abused to gain access to sensitive data. |
9
+
| A4:2019 - Lack of Resources & Rate Limiting | Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only this can impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force. |
10
+
| A5:2019 - Broken Function Level Authorization | Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. |
11
+
| A6:2019 - Mass Assignment | Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. |
12
+
| A7:2019 - Security Misconfiguration | Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. |
13
+
| A8:2019 - Injection | Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
14
+
| A9:2019 - Improper Assets Management | APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. |
15
+
| A10:2019 - Insufficient Logging & Monitoring | Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. |
| API Specific : Exploitability **3**| Prevalence **3** : Detectability **2**| Technical **3** : Business Specific |
7
-
| Attackers can exploit API endpoints that are vulnerable to broken object authorization by manipulating the ID of an object that is sent in the request. This may lead to unauthorized access to sensitive data. 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. | This has been the most common and impactful attack on APIs. Authorization and access control mechanisms in modern applications are complex and wide-spread. Even if the application implements a proper infrastructure for authorization checks, developers might forget to use these checks before accessing a sensitive object. Access control detection is not typically amenable to automated static or dynamic testing. | Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover. |
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. This may lead to unauthorized access to sensitive data. 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. | This has been the most common and impactful attack on APIs. Authorization and access control mechanisms in modern applications are complex and wide-spread. Even if the application implements a proper infrastructure for authorization checks, developers might forget to use these checks before accessing a sensitive object. Access control detection is not typically amenable to automated static or dynamic testing. | Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover. |
8
8
9
9
## Is the API Vulnerable?
10
10
11
11
Object level authorization is an access control mechanism that is usually
12
-
implemented at the code level to validate that one user can access only objects
13
-
that he should have access to.
12
+
implemented at the code level to validate that one user can only access objects
13
+
that they should have access to.
14
14
15
-
Every API endpoint that receives an ID of an object and performs any type of
16
-
action on the object should implement object level authorization checks. The
15
+
Every API endpoint that receives an ID of an object, and performs any type of
16
+
action on the object, should implement object level authorization checks. The
17
17
checks should validate that the logged-in user does have access to perform the
18
18
requested action on the requested object.
19
19
20
-
Failures in the mechanism typically leads to unauthorized information
21
-
disclosure, modification or destruction of all data.
20
+
Failures in this mechanism typically leads to unauthorized information
21
+
disclosure, modification, or destruction of all data.
22
22
23
23
## Example Attack Scenarios
24
24
25
25
### Scenario #1
26
26
27
-
An e-commerce platform for online stores provides a listing page with the
28
-
revenue charts for their hosted shops. Inspecting the browser requests, an
29
-
attacker identifies the API endpoints used as a data source for those charts
27
+
An e-commerce platform for online stores (shops) provides a listing page with
28
+
the revenue charts for their hosted shops. Inspecting the browser requests, an
29
+
attacker can identify the API endpoints used as a data source for those charts
30
30
and their pattern `/shops/{shopName}/revenue_data.json`. Using another API
31
-
endpoint, the attacker gets the list of all hosted shop names. With a simple
32
-
script to iterate over the names in the list, replacing `{shopName}` in the URL,
31
+
endpoint, the attacker can get the list of all hosted shop names. With a simple
32
+
script to manipulate the names in the list, replacing `{shopName}` in the URL,
33
33
the attacker gains access to the sales data of thousands of e-commerce stores.
34
34
35
35
### Scenario #2
36
36
37
37
While monitoring the network traffic of a wearable device, the following HTTP
38
-
`PATCH` request get the attention of an attacker due to the presence of a custom
39
-
HTTP request header `X-User-Id: 54796`. Replacing the `X-User-Id` value with
40
-
`54795`, the attacker receives a successful HTTP response and is able to modify
41
-
other user account data.
38
+
`PATCH` request gets the attention of an attacker due to the presence of a
39
+
custom HTTP request header `X-User-Id: 54796`. Replacing the `X-User-Id` value
40
+
with `54795`, the attacker receives a successful HTTP response, and is able to
41
+
modify other users' account data.
42
42
43
43
## How To Prevent
44
44
@@ -47,7 +47,7 @@ other user account data.
47
47
* Prefer not to use an ID that has been sent from the client, but instead use an
48
48
ID that is stored in the session object when accessing a database record by
49
49
the record ID.
50
-
* Use an authorization mechanism to check if the loggedin user has access to
50
+
* Use an authorization mechanism to check if the logged-in user has access to
51
51
perform the requested action on the record in every function that uses an
52
52
input from the client to access a record in the database.
53
53
* Prefer to use random and unpredictable values as GUIDs for records’ IDs.
0 commit comments