2

Disclaimer: yes, I have checked the Which HTTP status codes are interesting from a security point of view? which sounds relevant but not entirely.

These days it's supposed to be a good practice to not disclose extra data for non-authenticated users. Eg: email addresses for "forgot password" feature: when instead of saying "this email is not registered" hence disclosing that a user is not there/or is there you always return the same message like "check your email with the password reset link".

So far so good.

But what about HTTP status codes, more detail: for 404 vs 403.

Say you have some secured area where multiple people have different access to. Say it's a user management for multiple organisations.

And if you have a sequence based primary key for users that is used in the link to user's profile, eg: /admin/users/42 then you might iterate over the counter and comparing the status response code 404 - for non existing, 403 for existing determine how many users are there.

It's a simple example and I think there are a lot of similar things around.

So the question: should we prefer security over semantics and use only 403 (or 404) exclusively in all cases?

Community
  • 1
zerkms
  • 173
  • 10

2 Answers2

3

You practically answered your own question, It's completely viable to use a plain response for harden your system against an analysis attempt.

Other option could be: Use a random UUID to identify your users publicly and keep the primary key only for internal use. A UUID of 16 characters should be enough to mitigate this type of attack.

Finally you should consider log all the failed requests to get users information (403, 404).

Now, What method is better for your situation? is something that you have to decide, consider the next points:

  1. If your system is already in production phase, then it could be better make a little patch to formalize all the user failed requests to a 403/404 response.
  2. If you are in the design phase then you could opt for the second option and build a cool hardened system for your users.
ifm
  • 146
  • 3
1

It's a case of usability vs "implied" security. By making the requests have the same response code a user has lost the ability to determine if "the website isn't working" due to them typing in the wrong url or the wrong password.

As value of the response code itself isn't a necessity for HTTP to work, or even directly related to the url requested. The attacker would simply transfer the scanner/attack login to operate on the response body instead of the header, much like you would when exploiting blind SQL injection.

In short, you are increasing the trouble shooting complexity and downgrading the user experience of the website for a neglible gain in "security". Overall the increased financial cost in implementing and supporting these changes will most likely outweigh any benefits.

wireghoul
  • 5,745
  • 2
  • 17
  • 26
  • Not sure why your whole answer is based on the "login" example (which I didn't address) - it's about disclosing "number of something" that you may or may not have access to. Imagine you are a user manager that has access only to your department. But if you iterate over the counter in the user edit page link you can disclose how many users are in the system (which you normally should not know) – zerkms Apr 13 '15 at 03:10
  • User enumeration is really a separate issue, however with regards to knowing how many users are in a system, I don't see how disclosure of that information represents any kind of risk in the real world. – wireghoul Apr 13 '15 at 07:18
  • "how disclosure of that information represents any kind of risk in the real world" --- try to ask any microsoft or google manager about number of their employees they currently have or have ever had. Not sure anyone will give you an answer. Instead of users they might be bank account numbers. Or any other identifiers. – zerkms Apr 13 '15 at 08:06