Is it a good practice to show 403 unauthorized access error to user?

Question

Whenever we see a 403 forbidden access error page we think we have got to a place where some secret or private data is present. Now at this point bad guys know that this might be of interest and start to see if they can do something to get access to this secret data.

So is it good to show this error or just redirect to some other place?

Edit

I am thinking of dealing with error is to redirect to separate login page to access that particular resourse. But in this case also what if I simply don't want any one (may be even admin) to have access to these resource via my application. Offcourse admin can access the same resource by some other mean at the backend.

Answer 1

In production environment, you usually want to disclose as little information as possible. For that purpose, it's preferable to show generic error codes:

• Error 400 for client-related errors: Bad request, authentication needed, etc.
• Error 500 for server-related errors: Database down, site down for maintenance, etc.

Ideally, you shouldn't opt for the default error pages provided by your webserver. You either make your own error pages, or edit the default error pages in a way that hides any information that could be used by an attacker. For example, here's an error from one of our servers when accessing a password-protected URL:

Beyond that, it's a pure usability issue and it's greatly case-dependant. Shouldn't you redirect users to the homepage? Are those areas password-protected? Should you view a login form? Or do you simply want to show the generic error message with your site's style?

Here's an example of an error page on our site (Security.StackExchange)

Answer 2

Yes, all it means is that authentication was successful but the account is not authorized to view this resource. Per RFC2616, an HTTP 404 could be used instead. However I would advise against that since returning a 403 provides the following benefits:

1. For systems with multiple accounts (i.e. active directory), this provides the necessary information for the user that perhaps they logged in with the wrong account and should try another.
2. If the user legitimately needs access, the helpdesk ticket can be quickly processed knowing they're getting a 403.

In your scenario, the "bad guys" have already logged in successfully. Hopefully the authorization process is robust enough to thwart further damage (i.e. don't use query strings).

While many have commented on turning off detailed error messages, I would agree that this is a best practice. However, a 403 is much different from a server error such as an HTTP 500 where interesting information is printed to the screen. Again, a 403 just means you're unauthorized to view a particular resource after successfully logging in. So continue to return a 403 but don't include verbose diagnostic information.

If this is an extremely sensitive resource, consider segregating it and require dual-factor authentication. This will provide additional security that the person is truly who they claim to be when accessing the protected resource.

Answer 3

As @Adnan says, in any production environment you want to limit information leakage. A redirect can also be useful for an attacker.

I would take the recommendation a little further, and say you should not only limit the types of errors, but you should also only ever deliver customised error pages to the end user.

Default 400 or 500 pages often include a wealth of information about the error, and this is very useful for an attacker - they can find out what software is running, what web server, what OS etc.

So the general recommendation in an error context is to deliver a customised page to the user that acknowledges an error but gives away nothing, for example:

Internally all errors should be logged, so they can be dealt with.

Answer 4

To answer your first question, It is not good to show this error to the end user.

Showing a default error page that has the exact technical details in it is not a good practice. It has both security and user experience issues.

If the user is a non-technical person, this kind of error messages can highly annoy him with all the technical stuff in it. He will not know what to do solve the error which he dint understand.

On the other hand if the user is a technical person (lets say a bad one), there is a chance for him to get the glimpse or an overall idea of your security structure of your application. There is a fair chance of getting exposed if he finds out the security patterns in your application because the attacks he tries to break your application will be accurate or at least a bit more specific.

To answer your second question, Redirecting to some other page does not seem to be a good user friendly idea.

When user tries to access something and it redirects him straight to the Home page or any other page, it will spoil the usability and the users interest in your application. If you really want to redirect him somewhere, show him a a neat customized message and then redirect him. So that he will at least know what is happening.

Error handling is the solution for your problem . Always think in the user's perspective when you prepare the error messages. Show customizes error messages which the user can easily understand and also does not expose any security structure of your application.

Bottom line - Any kind of errors must be handled and customized before informing the user.

Answer 5

Is it a good practice? It depends. I do agree that you probably don't want to just send the default page to the user. That spoils usability, and it can provide too much information for an attacker if there are technical details.

However, what about sending 403 errors more generally? Here I am less convinced that it is a bad idea generally, and the larger question is what is going on or why is the 403 error occurring?

If I see a 403 error with a default error page, or particularly when I am not even logged in, this screams "incompetent admin" and therefore might seem to invite attack not so much through what it reveals about your site so much as what it reveals about your administrators.

But suppose I am logged in. I have been authenticated. Is there any reason when I try to access a resource I am not authorized to view that it should return something other than a 403 Access Denied error message? Passing back the error code allows this to be programmatically handled on the client side which is an important consideration with things like web services.

Now obviously this should never happen when you try to do something exposed in the UI. But as an additional layer of defence and opportunity for error handling, I don't see anything wrong with passing back the error code in this case, because there may be causes (again, web services come to mind) where passing the error code is the best way forward.

So with this in mind, I see a few things that have to be looked at non-prejudicially:

What information is leaked that can help an attacker? What information should be provided with the error message?

In general, with LedgerSMB we log extensively, but anything access-denied wise is a very short message on the client-facing side. This enables the admin to see what's going on but not the user.

What does the client minimally need to know in order to handle the error?

Usually, IMO, just that access was denied despite being logged in. The 403 can be helpful here, but you don't want to send much more than this.

What other concerns do you have?

A lot of things are dependent on threat model. The threat model of a customer-facing web application is very different than a line of business web app, and these are different than a subscription web service. You need to know what you are protecting and from what before you go further.

Answer 6

Looking at the context of your question, it seems to be an administration page that requires login to access. You are worried that by displaying a 403 error to non-authorized users, it would let anyone who guess the URL know that the page is there, but couldn't be accessed.

Obviously, the error page, if any, should not disclose information such as your server architecture and version. I am not going to repeat those very basic things again. There are a few options here. Let's look at the various options:

A redirection to the admin login page:

This is useful from the administrator's point of view. A session timeout might have occurred. The admin who clicked on the link to this page would be redirected straight to the login page to continue privileged access. As for others, they would also be redirected to the login page. If it is a hidden login, then it would be equivalent to showing the door to a hacker. In this case, I would strongly advise against redirection.

Display 403 error:

This error is unambiguous. Both the administrator and the user would be able to understand that their access is denied because they are not authorized. To the administrator, it could be due to a session timeout, or when they are accessing the page from a non-recognized IP address. Now, a determined hacker may, by trial-and-error chance upon this page as well. The question is, should you be worried about it? If the page itself doesn't accept any user input and you are confident that the code is clean and well written, then you shouldn't be.

Display 404 error:

By displaying a 404 error, you are in fact doing a security through obscurity. There is no doubt a gain in security but you shouldn't rely solely on it. A user would normally move on upon seeing a 404 file not found error. There is tradeoff here as your administrator may get confused when a different error code is shown than what is to be expected. If your administrator knows this, then, it shouldn't be much of a problem.

You are asking this question because you are worried. To have a peace of mind, I would go for the third option. But ultimately, it is up to you to decide based on the security requirement of your web application.