WHAT YOU NEED TO KNOW ABOUT HTTP

The HTTP is the agreed upon process to interact and communicate with a web application. It is completely plaintext protocol, so there is no assumption of security or privacy when using HTTP. HTTP is actually a stateless protocol, so every client request and web application response is a brand new, independent event without knowledge of any previous requests. However, it’s critical that the keeps track of client requests so you can complete multistep shopping transactions, such as online shopping where you add items to your shopping cart, select a shipping method, and enter payment information.

HTTP without the use of cookies would require you to relogin during each of created those steps. That is just not realistic, so the concept of a session was where the application keeps track of your requests after you login. Although sessions are a great way to increase the user-friendliness of a web application,
provide another attack vector for web applications. HTTP was not originally created to handle the type of web transactions that requires a high degree of security and privacy. You can inspect all the gory details of how HTTP operates with tools such as Wireshark or any local HTTP proxy.

The usage of secure HTTP (HTTPS) does little to stop the types of attacks that will be covered in this article. HTTPS is achieved when HTTP is layered on top of the Secure Socket I adds the TLS of SSL/TLS to normal HTTP request and responses. It is best suited for ensuring man-in-the-middle and other eavesdropping attacks are not successful; it ensures a “private call” between your browser and the web application as opposed to having a conversation in a crowded room where anybody can hear your secrets. However, in our usage, HTTPS just means we are going to be communicating with the web application over an encrypted communication channel to make it a private conversation. The bidirectional encryption of HTTPS will not stop our attacks from being processed by the waiting web
application

HTTP Cycles
One of the most important fundamental operations of every web application is the cycle of requests made by clients’ browsers and the responses returned by the web server. It’s a very simple premise that happens many of times every day. A browser sends a request filled with parameters (variables) holding user input and the web server sends a response that is dictated by the submitted request. The web application may act based on the values of the parameters, so they are prime targets for hackers to attack with web application and web server.

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 article.

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 headers 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 clients 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 response codes 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 clients 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 his 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.