Noteworthy HTTP Headers

Each HTTP cycle also includes headers in both the client request and the server
response that transmit details about the request or response. There are several of
these headers, but we are only concerned with a few that are most applicable to
our approach covered in this book.
The headers that we are concerned about that are set by the web server and sent
to the client’s browser as part of the response cycle are:
■ Set-Cookie: This header most commonly provides the session identifier
(cookie) to the client to ensure the user’s session stays current. If a hacker can
steal a user’s session (by leveraging attacks covered in later chapters), they
can assume the identity of the exploited user within the application.
■ Content-Length: This header’s value is the length of the response body in
bytes. This header is helpful to hackers because you can look for variation
in the number of bytes of the response to help decipher the application’s
response to input. This is especially applicable when conducting brute force
(repetitive guessing) attacks.
■ Location: This header is used when an application redirects a user to a new page.
This is helpful to a hacker because it can be used to help identify pages that are
only allowed after successfully authenticating to the application, for example.

The headers that you should know more about that are sent by the client’s
browser as part of the web request are:
■ Cookie: This header sends the cookie (or several cookies) back to the server
to maintain the user’s session. This cookie header value should always match
the value of the set-cookie header that was issued by the server. This header is
helpful to hackers because it may provide a valid session with the application
that can be used in attacks against other application users. Other cookies are
not as juicy, such as a cookie that sets your desired language as English.
■ Referrer: This header lists the webpage that the user was previously on when
the next web request was made. Think of this header as storing the “the
last page visited.” This is helpful to hackers because this value can be easily
changed. Thus, if the application is relying on this header for any sense of
security, it can easily be bypassed with a forged value.

Noteworthy HTTP Status Codes
As web server responses are received by your browser, they will include a status
code to signal what type of response it is. There are over 50 numerical HTTP
response codes grouped into five families that provide similar type of status
codes. Knowing what each type of response family represents allows you to gain
an understanding of how your input was processed by the application.
■ 100s: These responses are purely informational from the web server and usually
mean that additional responses from the web server are forthcoming.
These are rarely seen in modern web server responses and are usually followed
close after with another type of response introduced below.
■ 200s: These responses signal the client’s request was successfully accepted
and processed by the web server and the response has been sent back to your
browser. The most common HTTP status code is 200 OK.
■ 300s: These responses are used to signal redirection where additional
responses will be sent to the client. The most common implementation of
this is to redirect a user’s browser to a secure homepage after successfully
authenticating to the web application. This would actually be a 302 Redirect
to send another response that would be delivered with a 200 OK.
■ 400s: These responses are used to signal an error in the request from the
client.
This means the user has sent a request that can’t be processed by the
web application, thus one of these common status codes is returned: 401
Unauthorized, 403 Forbidden, and 404 Not Found.
■ 500s: These responses are used to signal an error on the server side. The most
common status codes used in this family are the 500 Internal Server Error
and 503 Service Unavailable.
Full details on all of the HTTP status codes can be reviewed in greater detail at
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.