A1:2021 | Insecure Direct Object Reference (6) | Cycubix Docs
PreviousA1:2021 | Insecure Direct Object Reference (5) | Cycubix DocsNextA1:2021 | Missing Function Level Access Control | Cycubix Docs
Last updated
Was this helpful?
Last updated
Was this helpful?
Do you have your access control documented? If you don’t, how can you enforce it?
Access control is defined by the business logic that guides the application and/or privacy and other laws.
Horizontal and Vertical Access Control
Often times we think of access control in terms of 'roles' (user, power-user, admin, etc.).
However, as noted in the previous exercises, users with the same 'role' can access each other’s data. This is horizontal access control. Both should be enforced.
Access Control Matrix
Audit Access
As displayed in the above example, your access control rules should include provisions of what access is logged.
For example, if a super-user or admin can edit other’s profiles … That is something that should be logged. Other examples would include detected violations or attempts to violate access control mechanisms.
Not many applications employ it, but you can use indirect references. In this case you can run your references across a hashing, encoding or other function on the server so that the id that the client sees is not the actual reference which the server handles.
This will reduce efficiency some (a common trade-off for security) and is still subject to being guessed, brute-forced or reverse engineered.
This approach should not be the only protection used. It can be used as an additional layer. Your server must implement the logic of mapping client (indirect) to server (direct) references.
Secure Object References
Do you have your access control documented? If you don’t, how can you enforce it?
Access control is defined by the business logic that guides the application and/or privacy and other laws.
Horizontal and Vertical Access Control
Often times we think of access control in terms of 'roles' (user, power-user, admin, etc.).
However, as noted in the previous exercises, users with the same 'role' can access each other’s data. This is horizontal access control. Both should be enforced.
Access Control Matrix
Audit Access
As displayed in the above example, your access control rules should include provisions of what access is logged.
For example, if a super-user or admin can edit other’s profiles … That is something that should be logged. Other examples would include detected violations or attempts to violate access control mechanisms.
Not many applications employ it, but you can use indirect references. In this case you can run your references across a hashing, encoding or other function on the server so that the id that the client sees is not the actual reference which the server handles.
This will reduce efficiency some (a common trade-off for security) and is still subject to being guessed, brute-forced or reverse engineered.
This approach should not be the only protection used. It can be used as an additional layer. Your server must implement the logic of mapping client (indirect) to server (direct) references.
Many time, APIs or RESTFul endpoints rely on obscurity , a static 'key', or lack of imagination on the user’s part to control access. Good options such as digitally signed JSON Web Tokens () are a good option for API authentication & access control using a combination of the claims and a digital/cryptographic signature to validate the consumer. Other emerging standards such as Secure Token Binding promise a 'cryptographic state' for web services in the request headers …
