Skip to content

Commit 44e7293

Browse files
authored
A5 Change name
1 parent a80f06d commit 44e7293

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

2019/en/src/0xa5-missing-function-resource-level-access-control.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
1-
A5:2019 Missing Function/Resources Level Access Control
1+
A5:2019 Broken Function Level Authorization
22
=======================================================
33

44
| Threat agents/Attack vectors | Security Weakness | Impacts |
55
| - | - | - |
66
| API Specific : Exploitability **3** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
7-
| Exploitation requires the attacker to send legitimate API calls to the API endpoint they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It is 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") | Access control 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 hierarchy (e.g. sub-users, users with more than one role) | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack |
7+
| Exploitation requires the attacker to send legitimate API calls to the API endpoint they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It is 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") | 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 hierarchy (e.g. sub-users, users with more than one role) | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack |
88

99
## Is the API Vulnerable?
1010

11-
The best way to find missing function or resource level access control is to
11+
The best way to find broken function level authorization issues is to
1212
perform deep analysis of the authorization mechanism while keeping in mind the
1313
user hierarchy, different roles or groups in the application, and asking the
1414
following questions:
@@ -41,7 +41,7 @@ about the invite including the user’s role and the user’s email.
4141
An attacker duplicated the request and manipulated the HTTP method and endpoint
4242
to `POST /api/invites/new`. This endpoint should only be accessed by
4343
administrators using the admin console which does not implement function level
44-
access control checks.
44+
authorization checks.
4545

4646
The attacker exploits the issue and sends himself an invite to create an
4747
admin account:
@@ -56,7 +56,7 @@ POST /api/invites/new
5656

5757
An API contains an endpoint that should be exposed only administrators -
5858
`GET /api/admin/v1/users/all`. This endpoint returns the details of all the
59-
users on the application and does not implement function level access control
59+
users on the application and does not implement function level authorization
6060
checks. An attacker who learned the API structure takes an educated guess and
6161
manages to access this endpoint which exposes sensitive details of the users of
6262
the application.
@@ -70,13 +70,13 @@ code.
7070

7171
* The enforcement mechanism(s) should deny all access by default, requiring
7272
explicit grants to specific roles for access to every function.
73-
* Review your API endpoints against function level access control flaws, while
73+
* Review your API endpoints against function level authorization flaws, while
7474
keeping in mind the business logic of the application and groups hierarchy.
7575
* Make sure that all of your administrative controllers inherit from an
76-
administrative abstract controller that implements access control checks based
76+
administrative abstract controller that implements authorization checks based
7777
on the user’s group/role.
7878
* Make sure that administrative functions inside a regular controller implements
79-
access control checks based on the user’s group and role.
79+
authorization checks based on the user’s group and role.
8080

8181
## References
8282

0 commit comments

Comments
 (0)