dubey/WebGoat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mitigation content update

Browse Source
This commit is contained in:
Jason White 2017-06-27 11:28:16 -04:00
parent 296723508b
commit ebb851b361
1 changed files with 52 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
webgoat-lessons/idor/src/main/resources/lessonPlans/en/IDOR_mitigation.adoc
View File

@ -1,10 +1,58 @@
== Secure Object References
=== Start with the end in mind
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 Example
|===
|Endpoint | Method | Description | Roles, Access Rules | Notes, Caveats
| /profile
| GET
| view user profile
| Logged in User, can only view their own role
| Admin roles must use diff Url to view others' profiles (see below)
| /profile/{id}
| GET
| view user profile of a given user
| Logged in User can view their own profile by {id}, admins can also view
| n/a
| /profile/{id}
| PUT
| edit user profile. profile object submitted from client with request
| Logged in User can edit their own profile by {id}, admins can also edit.
| Admin edit must be logged
|===
==== 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.
=== Using Indrect References
In some cases, using an indirect reference may help. This of course may make the application harder to trouble shoot and may also affect performance.
Not many applications employ it, but you can use *indirect* refrences. In this case you can run your references across a hahsing,
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.
=== Access Controls
Since the root of 'Insecure' of IDOR's s really in controlling access to the objects referenced, the key to making them secure is implementing vertical and horizontal access control.
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.
==== Knowing How Things Should be Secured
=== APIs
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 (https://jwt.io) 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 ...
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-10
https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-05
https://tools.ietf.org/html/draft-ietf-tokbind-https-06