Http 403 Error Recurrence experiment and its solution

Introduction to the problem

403 is a very common error code returned by the Web server, with the 403 error defined in the HTTP protocol as follows

403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization won't and the request SHOULD not be repeated. If the request method is not head and the server wishes to make public why the request has not been fulfilled, it SHOULD Describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (not Found) can is used instead.

In IIS, 403 errors are categorized in more detail in the form of a child error code, based on specific functionality.

IIS 7.0 defines the following HTTP status codes that indicate a is more specific cause of a 403 error:

403.1-execute Access Forbidden.
403.2-read Access Forbidden.
403.3-write Access Forbidden.
403.4-ssl required.
403.5-SSL 128 required.
403.6-ip address rejected.
403.7-client certificate required.
403.8-site access denied.
403.9-forbidden:too Many clients are trying to connect to the WEB server.
403.10-forbidden:web server is configured to deny Execute access.
403.11-forbidden:password has been changed.
403.12-mapper denied access.
403.13-client certificate revoked.
403.14-directory listing denied.
403.15-forbidden:client access licenses have exceeded limits on the WEB server.
403.16-client certificate is untrusted or invalid.
403.17-client certificate has expired or is not yet valid.
403.18-cannot execute requested URL in the current application pool.
403.19-cannot Execute CGI applications for the "client in" this application pool.
403.20-forbidden:passport logon failed.
403.21-forbidden:source access denied.
403.22-forbidden:infinite depth is denied.
403.502-forbidden:too many requests from the same client IP; Dynamic IP restriction limit reached.

This article uses experiments to reproduce some of the most common 403 errors, in the hope of demonstrating more vividly the causes of the various errors and the solutions to the problems.

[403.1 403.3]

The primary reason for 403.1-403.3 is that the permissions required by handler are limited by the permissions that are enabled in handler mapping.

How to view the permissions required by handler. The corresponding Handler can be found through IIS Manager-handler Mapping, based on the requested extension. For example, when we request an. asp file, error 403.3, find the processing. asp file handler for Aspclassic this handler, double hit open this handler script map-request restrictions- Access, you can view the permissions that the handler requires. In order to reproduce the 403.3 problem here, I will need permission set to write.

How to view permissions enabled by handler mapping. You can open the System.webserver/handlers@accesspolicy configuration node with IIS Manager-configuration Editor as follows, and you can see that the Write option is not selected. So there are 403.3 errors when accessing the ASP page. In addition, the corresponding Aspclassic handler in the handler mapping can also be seen as disabled.

403.1, 403.2 of the error reason is consistent with 403.3, that is, the corresponding handler required script or Read permission is not enabled.

[403.4 403.5 403.7]

403.4, 403.5, 403.7 are due to SSL settings, most of the time is not a server-side error, but the client's request does not meet the requirements of the service side. For example

403.4 means that the client sends an HTTP request to a Web site that is configured to require SSL

403.5 means that the client sends a request that does not meet the server's encryption bit requirements for SSL

403.7 refers to the client does not provide the corresponding certificate

These configurations can be configured through the server-side IIS Manager-ssl setting.

However, the 128-digit requirement for SSL requires the use of configuration Editor to locate System.webserver/security/access@sslflags to configure

For 403.7 errors There is a noteworthy place, if the server is configured to require a client certificate, the client will normally eject the certificate selection box to give the user the choice of which certificate sent to the server. If the client does not play the selection box without a single certificate, it is sent directly to the server. If you encounter a 403.7 error, it is likely that the client did not find an available certificate.

Here the so-called available certificates are defined according to the trust list returned by the server, according to the SSL protocol, the server returns a set of trusted root certificates to the client at the time of the SSL handshake, and the client looks for the existence of the corresponding user certificate link from these root certificates, and then pops the selection box. So if the client certificate is not found here, first determine if the client has the appropriate certificate, if it does not, and if the certificate exists, check that its corresponding root certificate is in the server-side trust list.

[403.14]

403.14 is very common, and the reason is simple, the directory is not allowed to be browsed.

The solution depends on the actual demand,

1. If the customer requests a question, that is, browsing the directory that should not be browsed, the server does not need any changes

2. If the browse directory expects the result to be a default page, it is likely that default document is not well matched or not in the directory

3. If you need to enable directory browsing, go to IIS Manager to the directory you specified browsing-enable

[403.6 403.8]

These two errors are related to the server configuration in which the server blocks the corresponding IP or DNS name of the client in the IPSecurity configuration. The specific configuration is system.webserver/security/ipsecurity

The above is the most common 403 errors and the corresponding solution, if you encounter some of the more rare other errors, you can refer to here to find specific solutions.

http://support.microsoft.com/kb/943891