3 ms·

I'm still struggling to think how this could have happened. I wonder if it has something to do with interaction with annualcreditreport.com? Maybe originally t

I'm still struggling to think how this could have happened. I wonder if it has something to do with interaction with annualcreditreport.com? Maybe originally the code had multiple levels of authenticating the user: 1) we know who you are, but you haven't proven it yet, and 2) you've proven it, now you can see everything. But when they integrated with a 3rd party, which could have been a decade or more after the original code was written, some developer who didn't understand the code just lumped everyone who came over from annualcreditreport.com into basket #2, even though that user still had to go through the url flow to prove themselves. Just a guess. I don't think most non-programmers realize how often preventing this kind of thing comes down to one developer making a stink repeatedly to indifferent higher-ups. If that one developer is incompetent or doesn't care, no one else does.

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 ago
  I 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 ago
    That'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 ago
  The 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 ago
  This 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...
A4ET8a8uTh0 4y ago
This is pure speculation on my end, but I can see it happen in a way that is not gross negligence. Backend does not understand what frontend looks like, does, or even supposed to do. Data team just wants to make sure stuff is mapped and goes where it is supposed to go without breaking anything. Nowhere there is a person who is responsible to say 'the fuck yo'.

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 ago
I 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 ago
  That'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 ago
The 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 ago
This 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...

A4ET8a8uTh0 4y ago

This is pure speculation on my end, but I can see it happen in a way that is not gross negligence. Backend does not understand what frontend looks like, does, or even supposed to do. Data team just wants to make sure stuff is mapped and goes where it is supposed to go without breaking anything. Nowhere there is a person who is responsible to say 'the fuck yo'.