Skip to content

Commit fe25767

Browse files
PauloASilvaPauloASilva
committed
chore: add 2023 top10 candidate categories
1 parent 5d4a3a3 commit fe25767

10 files changed

+1210
-0
lines changed

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

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
API1:2023 Broken Object Level Authorization
2+
===========================================
3+
4+
| Threat agents/Attack vectors | Security Weakness | Impacts |
5+
| - | - | - |
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. This can 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 widespread. 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+
9+
## Is the API Vulnerable?
10+
11+
Object level authorization is an access control mechanism that is usually
12+
implemented at the code level to validate that a user can only access the
13+
objects that they should have permissions to access.
14+
15+
Every API endpoint that receives an ID of an object, and performs any action
16+
on the object, should implement object-level authorization checks. The checks
17+
should validate that the logged-in user has permissions to perform the
18+
requested action on the requested object.
19+
20+
Failures in this mechanism typically lead to unauthorized information
21+
disclosure, modification, or destruction of all data.
22+
23+
Comparing the user ID of the current session (e.g. by extracting it from the
24+
JWT token) with the vulnerable ID parameter isn't a sufficient solution to
25+
solve BOLA. This approach could address only a small subset of cases.
26+
27+
In the case of BOLA, it's by design that the user will have access to the
28+
vulnerable API endpoint/function. The violation happens at the object level,
29+
by manipulating the ID. If an attacker manages to access an API
30+
endpoint/function they should not have access to - this is a case of BFLA
31+
rather than BOLA.
32+
33+
## Example Attack Scenarios
34+
35+
### Scenario #1
36+
37+
An e-commerce platform for online stores (shops) provides a listing page with
38+
the revenue charts for their hosted shops. Inspecting the browser requests, an
39+
attacker can identify the API endpoints used as a data source for those charts
40+
and their pattern `/shops/{shopName}/revenue_data.json`. Using another API
41+
endpoint, the attacker can get the list of all hosted shop names. With a
42+
simple script to manipulate the names in the list, replacing `{shopName}` in
43+
the URL, the attacker gains access to the sales data of thousands of e-commerce
44+
stores.
45+
46+
### Scenario #2
47+
48+
An automobile manufacturer has enabled remote control of its vehicles via a
49+
mobile API for communication with the driver's mobile phone. The API enables
50+
the driver to remotely start and stop the engine and lock and unlock the doors.
51+
As part of this flow, the user sends the Vehicle Identification Number (VIN) to
52+
the API.
53+
The API fails to validate that the VIN represents a vehicle that belongs to the
54+
logged in user, which leads to a BOLA vulnerability. An attacker can access
55+
vehicles that don't belong to them.
56+
57+
### Scenario #3
58+
59+
An online document storage service allows users to view, edit, store and delete
60+
their documents. When a user's document is deleted, a GraphQL mutation with the
61+
document ID is sent to the API.
62+
63+
```
64+
POST /graphql
65+
{
66+
"operationName":"deleteReports",
67+
"variables":{
68+
"reportKeys":["<DOCUMENT_ID>"]
69+
},
70+
"query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
71+
{
72+
deleteReports(reportKeys: $reportKeys)
73+
}
74+
}"
75+
}
76+
```
77+
78+
Since a document ID is deleted without any further permission checks, a user
79+
may be able to delete another user's document.
80+
81+
## How To Prevent
82+
83+
* Implement a proper authorization mechanism that relies on the user policies
84+
and hierarchy.
85+
* Use the authorization mechanism to check if the logged-in user has access to
86+
perform the requested action on the record in every function that uses an
87+
input from the client to access a record in the database.
88+
* Prefer the use of random and unpredictable values as GUIDs for records' IDs.
89+
* Write tests to evaluate the vulnerability of the authorization mechanism. Do
90+
not deploy changes that make the tests fail.
91+
92+
93+
## References
94+
95+
### OWASP
96+
97+
* [Authorization Cheat Sheet][1]
98+
* [Authorization Testing Automation Cheat Sheet][2]
99+
100+
### External
101+
102+
* [CWE-285: Improper Authorization][3]
103+
* [CWE-639: Authorization Bypass Through User-Controlled Key][4]
104+
105+
[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
106+
[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html
107+
[3]: https://cwe.mitre.org/data/definitions/285.html
108+
[4]: https://cwe.mitre.org/data/definitions/639.html

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

Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
API2:2023 Broken Authentication
2+
===============================
3+
4+
| Threat agents/Attack vectors | Security Weakness | Impacts |
5+
| - | - | - |
6+
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **3** : Business Specific |
7+
| Authentication in APIs is a complex and confusing mechanism. Software and security engineers might have misconceptions about what are the boundaries of authentication and how to implement it correctly. In addition, the authentication mechanism is an easy target for attackers, since it's exposed to everyone. These two points make the authentication component potentially vulnerable to many exploits. | There are two sub-issues: 1. Lack of protection mechanisms: API endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection; 2. Misimplementation of the mechanism: The mechanism is used / implemented without considering the attack vectors, or for the wrong use case (e.g. an authentication mechanism designed for IoT clients might not be the right choice for web applications). | Attackers can gain control of other users' accounts in the system, read their personal data, and perform sensitive actions on their behalf, like money transactions and sending personal messages. |
8+
9+
## Is the API Vulnerable?
10+
11+
Authentication endpoints and flows are assets that need to be protected. Additionally, "Forgot password / reset password" should be treated the same way
12+
as authentication mechanisms.
13+
14+
A public-facing API is vulnerable if it:
15+
16+
* Permits credential stuffing where the attacker uses brute force with a list
17+
of valid usernames and passwords.
18+
* Permits attackers to perform a brute force attack on the same user account,
19+
without presenting captcha/account lockout mechanism.
20+
* Permits weak passwords.
21+
* Sends sensitive authentication details, such as auth tokens and passwords in
22+
the URL.
23+
* Allows users to change their email address, current password, or do any other
24+
sensitive operations without asking for password confirmation.
25+
* Doesn't validate the authenticity of tokens.
26+
* Accepts unsigned/weakly signed JWT tokens (`{"alg":"none"}`)
27+
* Doesn't validate the JWT expiration date.
28+
* Uses plain text, non-encrypted, or weakly hashed passwords.
29+
* Uses weak encryption keys.
30+
31+
On top of that, a microservice is vulnerable if:
32+
33+
* Other microservices can access it without authentication
34+
* Uses weak or predictable tokens to enforce authentication
35+
36+
## Example Attack Scenarios
37+
38+
## Scenario #1
39+
40+
In order to perform user authentication the client has to issue an API request
41+
like the one below with the user credentials:
42+
43+
```
44+
POST /graphql
45+
{
46+
"query":"mutation {
47+
login (username:\"<username>\",password:\"<password>\") {
48+
token
49+
}
50+
}"
51+
}
52+
```
53+
54+
If credentials are valid, then an auth token is returned which should be
55+
provided in subsequent requests to identify the user. Login attempts are
56+
subject to restrictive rate limiting: only three requests are allowed per
57+
minute.
58+
59+
To brute force log in with a victim's account, bad actors leverage GraphQL
60+
query batching to bypass the request rate limiting, speeding up the attack:
61+
62+
```
63+
POST /graphql
64+
[
65+
{"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"},
66+
{"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"},
67+
{"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"},
68+
...
69+
{"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"},
70+
]
71+
```
72+
73+
## Scenario #2
74+
75+
In order to update the email address associated with a user's account, clients
76+
should issue an API request like the one below:
77+
78+
```
79+
PUT /account
80+
Authorization: Bearer <token>
81+
82+
{ "email": "<new_email_address>" }
83+
```
84+
85+
Because the API does not require the user to confirm their identity by
86+
providing their current password, bad actors are able to put themselves in a
87+
position to steal the auth token.They also might be able to take over the
88+
victim's account by starting the reset password workflow after updating the
89+
email address of the victim's account.
90+
91+
## How To Prevent
92+
93+
* Make sure you know all the possible flows to authenticate to the API
94+
(mobile/ web/deep links that implement one-click authentication/etc.). Ask
95+
your engineers what flows you missed.
96+
* Read about your authentication mechanisms. Make sure you understand what and
97+
how they are used. OAuth is not authentication, and neither are API keys.
98+
* Don't reinvent the wheel in authentication, token generation, or password
99+
storage. Use the standards.
100+
* Credential recovery/forgot password endpoints should be treated as login
101+
endpoints in terms of brute force, rate limiting, and lockout protections.
102+
* Require re-authentication for sensitive operations (e.g. changing the account
103+
owner email address/2FA phone number).
104+
* Use the [OWASP Authentication Cheatsheet][1].
105+
* Where possible, implement multi-factor authentication.
106+
* Implement anti-brute force mechanisms to mitigate credential stuffing,
107+
dictionary attacks, and brute force attacks on your authentication endpoints.
108+
This mechanism should be stricter than the regular rate limiting mechanisms
109+
on your APIs.
110+
* Implement [account lockout][2]/captcha mechanisms to prevent brute force
111+
attacks against specific users. Implement weak-password checks.
112+
* API keys should not be used for user authentication. They should only be used
113+
for [API clients][3] authentication.
114+
115+
## References
116+
117+
### OWASP
118+
119+
* [Authentication Cheat Sheet][1]
120+
* [Key Management Cheat Sheet][4]
121+
* [Credential Stuffing][5]
122+
123+
### External
124+
125+
* [CWE-204: Observable Response Discrepancy][6]
126+
* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7]
127+
128+
[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
129+
[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003)
130+
[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key
131+
[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
132+
[5]: https://owasp.org/www-community/attacks/Credential_stuffing
133+
[6]: https://cwe.mitre.org/data/definitions/204.html
134+
[7]: https://cwe.mitre.org/data/definitions/307.html

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

Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
API3:2023 Broken Object Property Level Authorization
2+
====================================================
3+
4+
| Threat agents/Attack vectors | Security Weakness | Impacts |
5+
| - | - | - |
6+
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **2** : Business Specific |
7+
| Attackers can exploit API endpoints that are vulnerable to broken object property level authorization by reading or changing values of object properties they are not supposed to access. | Authorization in APIs is done in layers. While developers might perform proper validations to make sure that a user has access to a function, and then to a specific object, they often don't validate if the user is allowed to access a specific property within the object. | Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. |
8+
9+
## Is the API Vulnerable?
10+
11+
When allowing a user to access an object using an API endpoint, it is important
12+
to validate that the user has access to the specific object properties they are
13+
trying to access.
14+
15+
An API endpoint is vulnerable if:
16+
17+
* The API endpoint exposes properties of an object that are considered
18+
sensitive and should not be read by the user. (previously named: "[Excessive
19+
Data Exposure][1]")
20+
* The API endpoint allows a user to change, add/or delete the value of a
21+
sensitive object's property which the user should not be able to access
22+
(previously named: "[Mass Assignment][2]")
23+
24+
## Example Attack Scenarios
25+
26+
### Scenario #1
27+
28+
A dating app allows a user to report other users for inappropriate behavior.
29+
As part of this flow, the user clicks on a "report" button, and the following
30+
API call is triggered:
31+
32+
```
33+
POST /graphql
34+
{
35+
"operationName":"reportUser",
36+
"variables":{
37+
"userId": 313,
38+
"reason":["offensive behavior"]
39+
},
40+
"query":"mutation reportUser($userId: ID!, $reason: String!) {
41+
reportUser(userId: $userId, reason: $reason) {
42+
status
43+
message
44+
reportedUser {
45+
id
46+
fullName
47+
recentLocation
48+
}
49+
}
50+
}"
51+
}
52+
```
53+
54+
The API Endpoint is vulnerable since it allows the authenticated user to have
55+
access to sensitive (reported) user object properties, such as "fullName" and
56+
"recentLocation" that are not supposed to be accessed by other users.
57+
58+
### Scenario #2
59+
60+
An online marketplace platform, that offers one type of users ("hosts") to rent
61+
out their apartment to another type of users ("guests"), requires the host to
62+
accept a booking made by a guest, before charging the guest for the stay.
63+
64+
As part of this flow, an API call is sent by the host to
65+
`POST /api/host/approve_booking` with the following legitimate payload:
66+
67+
```
68+
{"approved":true,"comment":"Check-in is after 3pm"}
69+
```
70+
71+
The host replays the legitimate request, and adds the following malicious
72+
payload:
73+
74+
```
75+
{"approved":true,"comment":"Check-in is after 3pm","total_stay_price":"$1,000,000"}
76+
```
77+
78+
The API endpoint is vulnerable because there is no validation that the host
79+
should have access to the internal object property - "total_stay_price", and
80+
the guest will be charged more than she was supposed to be.
81+
82+
### Scenario #3
83+
84+
A social network that is based on short videos, enforces restrictive content
85+
filtering and censorship. Even if an uploaded video is blocked, the user can
86+
change the description of the video using the following API request
87+
88+
```
89+
PUT /api/video/update_video
90+
91+
{"description":"a funny video about cats"}
92+
```
93+
94+
A frustrated user can replay the legitimate request, and add the following
95+
malicious payload:
96+
97+
```
98+
{"description":"a funny video about cats","blocked":false}
99+
```
100+
101+
The API endpoint is vulnerable because there is no validation if the user
102+
should have access to the internal object property - "blocked", and the user
103+
can change the value from "true" to "false" and unlock their own blocked content.
104+
105+
## How To Prevent
106+
107+
* When exposing an object using an API endpoint, always make sure that the user
108+
should have access to the object's properties you expose.
109+
* Avoid using generic methods such as to_json() and to_string(). Instead,
110+
cherry-pick specific object properties you specifically want to return.
111+
* If possible, avoid using functions that automatically bind a client's input
112+
into code variables, internal objects, or object properties
113+
("Mass Assignment").
114+
* Allow changes only to the object's properties that should be updated by the
115+
client.
116+
* Implement a schema-based response validation mechanism as an extra layer of
117+
security. As part of this mechanism, define and enforce data returned by all
118+
API methods.
119+
* Keep returned data structures to the bare minimum, according to the
120+
business/functional requirements for the endpoint.
121+
122+
## References
123+
124+
### OWASP
125+
126+
* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1]
127+
* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2]
128+
* [Mass Assignment Cheat Sheet][3]
129+
130+
### External
131+
132+
* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4]
133+
* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5]
134+
135+
[1]: https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa3-excessive-data-exposure.md
136+
[2]: https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa6-mass-assignment.md
137+
[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html
138+
[4]: https://cwe.mitre.org/data/definitions/213.html
139+
[5]: https://cwe.mitre.org/data/definitions/915.html

0 commit comments

Comments
 (0)