4 ms·
I don't know about this case, but a lot of the time this class of vulnerability comes down to lack of Authorisation rather than lack of Authentication. So much
by xnorswap 4y ago
I don't know about this case, but a lot of the time this class of vulnerability comes down to lack of Authorisation rather than lack of Authentication.
So much effort is put into checking that people are who they say they are (is Person X really Person X) , they forget to check that they're authorised (is Person X actually supposed to be accessing resource Y).
Given the URLs don't have the actual resource Identifier, it means the resource ID will have been gathered from somewhere else, typically one of three places:
1. Cookies / Localstorage - Easily manipulated and should never be treated as a secure place, it's easy to put simple values here and forget that they still need to be validated / checked server side, and that just because you have access to /foo/Y you might not also have access to /bar/Y.
2. Session - An ASP favourite, sticking something in a key like Session["FolderID"] you might assume you've validated and checked authorisation when you set the key, then later re-use (deliberately or accidentally) the same key elsewhere leaving it open for manipulation. And then you might assume you don't need to re-check authorisation when you read the key.
- herpderperator 4y agoI wouldn't call the "session" concept an ASP favourite - it's the industry standard for any backend web framework to use a user session where the session key is stored as a random cookie value and the actual key-value pairs are stored on the backend somewhere.
- xnorswap 4y agoThat's fair, I associate it as an ASP favourite to mess it up and cause all sorts of security holes with it! Probably just a lot more inexperienced developers treating it like a magic authenticated bag without enough warnings about improper use in the documentation. Also a very easy "go to" store via global variable in ASP made it especially easy to use it as a go-to solution for anything that you couldn't be bothered to properly store.
- suzzer99 4y agoThe only way to write something super sensitive like this imo is to have the back-end API that retrieves full credit report be essentially hard-wired to a user access level of "FULLY_VALIDATED". That way no developer can come along five years later and accidentally grant the wrong access level or show the report to a not fully validated user. Put the security check on or as close to the thing being accessed as possible.
- metadat 4y agoThis class of vulnerability is called BOLA [0] (also sometimes called IDOR) and prevalence is on the rise. BOLA: Broken Object Level Authorization IDOR: Insecure Direct Object References [0] https://www.wallarm.com/what/broken-object-level-authorization#what_is_broken_object_level_authorization_ https://www.wallarm.com/what/broken-object-level-authorizati...