wiley http essentials protocols for secure scaleable web sites phần 5 doc

122 HTTP Essentials message body. With a 205 Reset Content, however, the server directs the client to reset the document view that gen- erated the request. Typically that’s equivalent to the user clicking a Reset button on a Web form. 206 Partial Content Servers that respond to a request for a subset of a resource (a request with a Range header) use the 206 Partial Content status when they accept the request and return only the re- quested subset. The response also includes a Content-Range header to identify which parts of the resource are present in the response’s message. 3.3.3 Redirection (3xx) Status codes from 300 to 399 tell the client that it needs to take further action to fulfill its request. Specifically, the server asks the client to reissue its request, but for a different uri. If there is only one alternative location available, or if the server has a preference for one particular location among the alternatives, the server includes the uri for that location in the Location header. Other alternatives may be listed in the message body. If the client’s original request was a GET or HEAD, the client can safely reissue the request to the indicated uri automati- cally, without consulting the user. With other requests, how- ever, there may be security implications, and the client should first ask permission from the user. 300 Multiple Choices The 300 Multiple Choices status gives the client a list of alternative locations for the request. The server provides these in the response’s message body, and it may include one in a Location header. 301 Moved Permanently When a resource’s uri has changed permanently, the server may respond with a 301 Moved Permanently status. The HTTP Messages 123 client (and any proxies) should, henceforth, use the indicated uri for all future references to the resource. All of the other 3xx status codes represent temporary conditions. 302 Found The 302 Found status indicates that the resource has tempo- rarily moved to a new location, and the client should reissue its request to the new uri. In practice, many clients that re- ceive a 302 Found status will send a GET request to the new uri, even if the original request used another method. This behavior actually violates the http specifications, but it is so common that servers should take it into account. With ver- sion 1.1, http introduced the 303 See Other and 307 Tem- porary Redirect status codes to address this problem. 303 See Other The 303 See Other status is the http specification’s way of properly asking clients to do what many already do in reac- tion to a 302 Found response—send a GET request to the indicated uri. The 303 See Other status is intended pri- marily as a response to a POST request. After the client issues the POST, this response tells it where to get the next resource to display for the user. Consequently, the location indicated by a 303 See Other status is not a new location for the original resource. It is, rather, a reference to an entirely new resource. 304 Not Modified If a request includes a condition (such as an If-Match or If- Modified-Since header) and that condition is not met, the server responds with a 304 Not Modified status. Typically this allows the client (or proxy server that forwarded the re- quest) to use a cached copy of the resource. 305 Use Proxy The 305 Use Proxy status asks the client to reissue the re- quest to a proxy server. Only origin servers should generate this status, and the status applies only to the initial request. 124 HTTP Essentials 307 Temporary Redirect The 307 Temporary Redirect status officially means the same as a 302 Found status: The resource has temporarily moved to a new location, and the client should reissue its request there. In particular, the client should use the same request method. As noted previously, http 1.1 added this status code because so many clients react improperly to the 302 Found status. 3.3.4 Client Error (4xx) If a server encounters a problem with a client’s request, it can use one of the 4xx status codes in its response. The specific status code may provide more information about the prob- lem the server detected. 400 Bad Request The standard status code for client errors is 400 Bad Re- quest . This response indicates that the server did not under- stand the request, perhaps because there is an error in its formatting. The client should not reissue the same request, as it will be rejected as well. 401 Unauthorized The 401 Unauthorized status code tells the client that the server requires user authentication before granting access to the resource. The server includes a WWW-Authenticate header in its response to give the client guidance on the type of authentication it requires. As section 4. 1 explains, clients react to this status by reissuing the request with an appropri- ate Authorization header. 402 Payment Required Although the http specifications define this status code, it is currently just reserved for future use. Of course, its mean- ing is fairly self-explanatory. It is much less clear, however, how a client should react to receiving it. HTTP Messages 125 403 Forbidden A client that receives a 403 Forbidden status code has at- tempted to access a resource that cannot be accessed. Unlike the case for a 401 Unauthorized status code, no Authori- zation header will grant the client access. Servers should note that by returning a 403 Forbidden response, they im- ply that the requested resource does, in fact, exist. If revealing this information is not appropriate, the server can use a 404 Not Found status code instead. 404 Not Found The 404 Not Found status code indicates that the requested resource does not exist. It does not give any information about whether this condition is permanent or temporary. If a server wishes to explicitly indicate a permanent condition, it may use the 410 Gone status instead. 405 Method Not Allowed The 405 Method Not Allowed status tells the client that the method it used is not permitted with the referenced re- source. Servers include an Allow header in their response to tell clients what methods are permitted. 406 Not Acceptable When a server returns a 406 Not Acceptable status, the client’s request can generate only responses that the client has indicated are not acceptable. The message body of the response may indicate the entity characteristics that the re- quest can generate. This status should appear only in re- sponse to requests with Accept, Accept-Charset, Accept- Encoding , or Accept-Language headers. 407 Proxy Authentication Required The 407 Proxy Authentication Required tells a client that it must authenticate itself with a proxy server before its request can proceed. The proxy server that generates this re- sponse includes a Proxy-Authenticate header to guide the 126 HTTP Essentials client in providing an appropriate Proxy-Authorization header in its reissued request. 408 Request Timeout With the 408 Request Timeout status, a server indicates that it has timed out waiting for a request from the client. 409 Conflict The 409 Conflict status indicates that the server could not complete the request because of a conflict with the current state of the resource. This conflict could arise, for example, when a PUT request includes changes to a resource that would conflict with changes already accepted by a third party. 410 Gone The 410 Gone status indicates that a resource is no longer available. This condition should be considered permanent. 411 Length Required When a server returns a 411 Length Required status, it refuses to accept a request unless the client reissues the re- quest with a valid Content-Length header. 412 Precondition Failed The 412 Precondition Failed status indicates that one of the conditions the client included in its request (through, for example, an If-Match header) did not apply. 413 Request Entity Too Large The 413 Request Entity Too Large status indicates that the message body of a request was larger than the server could accept. If the server expects this condition to be tem- porary, it can include a Retry-After header in its response. 414 Request-URI Too Long If a client includes a uri in its request that is longer than the server is willing to interpret, the server can respond with a 414 Request-URI Too Large status. HTTP Messages 127 415 Unsupported Media Type By returning a 415 Unsupported Media Type status, a server indicates that it cannot understand the media type of the request’s message body. 416 Requested Range Not Satisfiable When a client asks for a range of a resource (with the Range header) and the range is not valid, the server responds with a 416 Requested Range Not Satisfiable status. 417 Expectation Failed If a server cannot meet a client’s expectations as conveyed in a request’s Expect header, it returns a 417 Expectation Failed status. 426 Upgrade Required The 426 Upgrade Required status lets a server tell a client that it must upgrade the application it’s using for the request. A server that wanted to force its client to upgrade to Trans- port Level Security (tls), for example, would return this status along with an Upgrade header identifying tls as the required application upgrade. 3.3.5 Server Error (5xx) In contrast to the 4xx status codes, which point to a client problem, the 5xx status codes indicate a problem on the server. 500 Internal Server Error The 500 Internal Server Error status is a general indica- tion of a server problem. If the server can provide further details, it may do so in the response’s message body. 501 Not Implemented The 501 Not Implemented status indicates that the server does not support the request’s method for any resource, not just the resource requested. 128 HTTP Essentials 502 Bad Gateway If a proxy server receives an invalid response from the server to whom it forwarded a request, it responds to the client with a 502 Bad Gateway status. 503 Service Unavailable The 503 Service Unavailable status indicates that the server is temporarily unable to satisfy the request, perhaps because the server is currently overloaded or undergoing maintenance. The server may include a Retry-After header in its response if it anticipates that the problem will be cor- rected by that time. 504 Gateway Timeout When a proxy server times out waiting for a response from another server, it returns a 504 Gateway Timeout status to the client. 505 Version Not Supported The 505 Version Not Supported status indicates that the server cannot support the http version identified in the cli- ent’s request. 129 CHAPTER 4 Securing HTTP — Adding Authentication & Privacy If the World Wide Web were nothing more than a linked collection of static information, then securing the Web’s pro- tocols would be less important. With the growth of elec- tronic commerce and the extension of http to critical environments outside of the Web, however, adding security to http is critical for many applications. Security allows the communicating parties to verify each other’s identity, to en- sure the privacy of their communication, and to protect their messages from modification or corruption. This chapter looks at the various ways to add security to http. The first section, Web Authentication, details the pro- cedures built into http 1.1. The second section introduces the Secure Sockets Layer (ssl) protocol. By far the most common way of providing security on the Web, ssl is a sepa- rate protocol that adds security to many applications. It was designed, however, especially for http. The Transport Layer Security (tls) protocol is the most recent revision of ssl. It is very similar to ssl, but it includes a few additional features tailored for http communications. Finally, the chapter takes 130 HTTP Essentials a brief look at Secure-http (shttp). Originally developed about the same time as ssl, shttp defines extensions directly to the http protocol for security. shttp has largely been supplanted by ssl in actual operation, but a few implementa- tions still exist. 4.1 Web Authentication Although some sections of this chapter discusses securing http using additional protocols or extensions, http in- cludes its own security mechanisms. The http security mechanisms are not as formidable as other approaches, but they are sufficiently secure for many applications. The security mechanisms built into http rely on user pass- words for their security. That makes them relatively simple, but it is also the source of their weakness. User passwords are notoriously insecure, as human users often select passwords that are easy for adversaries to guess. Humans can also be rather careless about their passwords, reusing the same pass- word for many systems, leaving passwords on a sticky note attached to their monitor, or revealing those passwords to an adversary posing as an administrator or other employee of a system. 4.1.1 Basic Authentication The simplest form of http security is basic authentication. It allows a server to request a username and password from a client, and it defines how the client should send that infor- mation to the server. Figure 4. 1 shows the process. The client first sends its http request as usual. For its reply, however, the server responds with a status code of 401 Unauthorized. This status code tells the client that it must supply a user- name and password. The 401 Unauthorized response includes the WWW- Authenticate header, and for basic authentication the Caution: Basic Authentication Even though HTTP 1.1 defines the Basic Authentication mechanism, it does so very reluctantly. As we’ll see in this section, the security Basic Authentication offers is extremely weak security. Many, in fact, have argued that it is better to use no security at all than to rely on Basic Authentication. We cover it in this text because it is part of the specification, however, and because there are implementations that do use it. When given a choice, however, this author, along with the authors of the HTTP standard, strongly recommends against using Basic Authentication in any application. Securing HTTP 131 header includes the challenge “Basic,” as well as a value for the challenge’s realm. One possible response from a server is as follows. HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="users@hundredacrewoods.com" The server can choose any value it wants for the realm, but in Web browsing it is typical to use a value that human users can understand. That’s because Web browsers typically dis- play the realm for the user when asking for the username and password. Figure 4.2 shows how a browser might query a user. Once the user supplies a username and password, the client can continue the communication with step 3 of figure 4. 1. In Client Server 2 401 Unauthorized WWW-Authenticate 1 GET URI 3 GET URI Authorization 4200 OK ᮤ Figure 4.1 When a server wants a client to authenticate its user, the server returns a 401 status. The client can then reissue the request with appropriate information included in the Authorization header. ᮤ Figure 4.2 Web browsers ask their users for authentication with a pop-up window like this. HTTP authorization is never part of a Web page itself, unlike the SSL-secured server authorization of figure 4.3. [...]... relatively insecure Web site may be able to use that same combination for other, more valuable, sites To address the lack of real security in http s Basic Authentication, many Web sites create their own login process Figure 4.3 shows one such Web site Here users are asked for their name and password via a Web form rather than http authentication Even though http is used to convey the form to the user... passwords 133 134 HTTP Essentials Figure 4.3 ᮣ Some Web sites manage usernames and passwords themselves rather than relying on HTTP authentication As this example shows, users input their authentication information to such sites via a standard Web page rather than a browser’s pop-up dialog box are vulnerable to interception The Digest Authentication process was initially defined as an extension to http version... correctly adjust the digest for an altered nc value 4.1 .5 Mutual Authentication The Original Digest Authentication process gives http servers a way to verify the identity of clients, but it doesn’t help clients verify the identity of the server Fortunately, digest authentication in general can support mutual authentication with only a few minor modifications For that reason, 1 45 146 HTTP Essentials Improved... MD5 and Securing HTTP 151 MD5-sess, however, should always choose to use MD5-sess, as that provides greater security Clients accept one of the proposed algorithms when they reissue their request The following fragment shows a client accepting the MD5-sess algorithm GET /secret/honeypot.html HTTP/ 1.1 Authorization: Digest username="pooh", realm="users@hundredacrewoods.com", qop=auth, algorithm=MD5-sess,... qop="auth", algorithm=MD5-sess, nonce="dcd98bc09f81043d3a8cb935ae393db90674" WWW-Authenticate: Digest realm="users@hundredacrewoods.com", qop="auth", algorithm=MD5, nonce="dcd98bc09f81043d3a8cb935ae393db90674" Note that in this example the server proposes both the MD5 and the MD5-sess algorithms By proposing both options, the server can support clients that implement only MD5 Those clients will ignore... transformation that is relatively easy to perform, but extremely difficult to reverse It is easy for a computer to start with a password and other information and calculate a message digest, but it is mathematically impossible, given just the resulting digest, to figure out the password and information used to create it Today there are two common message digest algorithms One is Message Digest 5 (MD5),... again separated by colons For example, GET:/secret/honeypot.html (This is string “A2.”) 4 Calculate the MD5 digest for this character string and represent the result as 32 ASCII characters continues… 152 HTTP Essentials Table 4.8 Digest Calculation with MD5-sess Algorithm (continued) Step Action 5 Construct a character string by combining the result from step 2, the nonce supplied by the server, the... pooh:users@hundredacrewoods.com:honey, for example (This is string “A1.”) Securing HTTP Table 4.7 continued Step Action 2 Calculate the MD5 digest for this character string and represent the result in hexadecimal as 32 ASCII characters 3 Construct a second character string consisting of a colon followed by the URI of the client’s request As an example, :/secret/honeypot.html (This is string “A2.”) 4 Calculate the MD5 digest for this... realm, and the password What’s noteworthy is that those three items 149 150 HTTP Essentials do not normally change as the client makes repeated requests of a host Every request to the host will use the same key to protect its authentication information In cryptography, the more information protected with a given key, the less secure that key becomes Adversaries have more data to analyze, and the more... separated by colons For example, GET:/secret/honeypot.html (The specification calls this string “A2.”) 4 Calculate the MD5 digest for this character string and represent the result as 32 ASCII characters 5 Construct a character string by combining the result from step 2, the nonce supplied by the server, and the result from step 4, all separated by colons (:) 6 Calculate the MD5 digest for the character . features tailored for http communications. Finally, the chapter takes 130 HTTP Essentials a brief look at Secure -http (shttp). Originally developed about the same time as ssl, shttp defines extensions. time. 50 4 Gateway Timeout When a proxy server times out waiting for a response from another server, it returns a 50 4 Gateway Timeout status to the client. 50 5 Version Not Supported The 50 5. security in http s Basic Authenti- cation, many Web sites create their own login process. Figure 4.3 shows one such Web site. Here users are asked for their name and password via a Web form rather