3

It is my understanding that good security design does not reveal information about data which the user is not allowed to access. This includes information about the existence of said data, i.e. if a user is not allowed to access entities of a certain type, they should also not be able to figure out whether an entity of that type with a certain ID exists.

A project I am currently working on does not support this consistently. For example a request to /edit/record/52 will return an HTTP 404 error if the record with ID 52 does not exist and an HTTP 403 error if it does exist.

I'm unsure how much of a problem this is in terms of security. With this information alone, attackers can probably not do anything. My worry is that this enables attackers to aggregate information about data in the system (as we have several endpoints for different entities exhibiting this same behavior) which could then be used to attack the system. Admittedly, I do not have an attack scenario using this information laid out in my head, but I'm afraid this leakage might at least facilitate attacks. Unfortunately, changing this would require a bit of refactoring of our security architecture, which is why we didn't do it right away.

Is this a common attack vector? Should I be worried and fix this wherever possible? Or is leakage of information about existence of objects acceptable? Could you provide examples of well-known or high-profile attacks where leakage of seemingly insignificant data led to the compromise of a system?

Chris
  • 652
  • 6
  • 12
  • 1
    Just having sequential ID's (I asume 52 is one) will give away some information. – Anders Jun 27 '16 at 09:03
  • IMHO it depends on whether the denotation of the record, here 52, conveys a meaning or not that the attacker could exploit. Consider the database of medical records of patients of a hospital seachable with patients' names. The existence of a record for X implies that X has consulted that institution at some time, doesn't it? – Mok-Kong Shen Jun 27 '16 at 09:09
  • @Anders Indeed, it is the database's primary key. However, I read https://security.stackexchange.com/questions/56357/should-i-obscure-database-primary-keys-ids-in-application-front-end and decided that obscuring primary keys is not worth the effort. So yes, this does give some information, but doesn't tell the attacker whether there are entries with values above 52. – Chris Jun 27 '16 at 09:40
  • 1
    While 404 is technically only for resources which don't exist for _anyone_, the standard allows its use when 403 would otherwise reveal sensitive information. So you can just use 404. – forest Dec 13 '18 at 02:40

1 Answers1

2

Your assessment of the risk is correct: leaking this data could facilitate an attack by helping the attacker collect information. So even if there is no direct risk, it could speed up the information gathering phase of an attack.

If you have any concern, the usual solution is to sanitise your responses as needed - you could replace those 403's with 404's for example. But if, as you have mentioned, this is high effort - it's worth weighing up whether the slight leakage risk needs remediation.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320