In order to know what which user role can do, you have to know your target well.
If documentations are available, make full use of them, if not, use the app as much as you can from the perspective of each user role (have a different account for each role)
2οΈβ£ Test plan
Obviously, you need to have multiple accounts, one for each available user role.
The premises of BAC testing is lateral and vertical privilege escalation, seeing if user role A can do what B can, even though he's not supposed to. If he can, then we have a bug.
This consists in replacing cookies/tokens on various requests, such as API calls.
For example:
/api/admin/users (Admin only)
Try to access it with Normal user privileges
To remove the pain of copy-pasting cookies/tokens/keys for 100 times, use the extension Authorize in Burp Suite.
If the attack fails(as expected), you can try tweak the request in somd ways.
Tamper with the URL, inject certain parameters, change some values, JSON β‘οΈ Normal params, force browsing, WHATEVER you can think of.
Fool the system by making it think you have access to that resource.
If all fails, move on to the next function.
There's not that many bypasses you can try, if the privileges for your users don't allow for a certain thing, don't spend more than 5 minutes trying to bypass it.
There's a lot of other requests for you to test so don't waste time.
That's a wrap!
If you enjoyed this thread:
1. Follow me @shrekysec for more of these 2. RT the tweet below to share this thread with your audience
Anywhere you see user input is reflected in the response (not limited to what you see on the page, it could be in source code/HTTP response only), note the location/parameter down, that's a potential attack vector.