HTTP is a stateless protocol used in the World Wide Web (WWW) to facilitate a client-server data transaction. HTTP/1.1 is currently the most widely accepted version of the protocol but the industry will begin to shift over to version 2.0 soon. Web sites and web applications are what the World Wide Web is made up of but there is a key difference between the two, which is that a web application accepts user input. A web site can be thought of as static, while a web application is dynamic. A web site hosts content on a web server and the resources present on the web server can be retrieved by a client but the resources will never change. A web application on the other hand accepts user input and dynamically generates output based on that user input. In the early days of the internet, the World Wide Web typically only consisted of web sites. Today, relatively few web sites exist and web applications hold the more dominant position throughout the web. The communication transaction between a client and server via HTTP consists of what are known as HTTP messages. An HTTP message consists of an HTTP request sent by the client to a receiving web server and an HTTP response returned by the web server to the client. A critical component to performing web application security testing is to have a solid understanding of the actual communication taking place. In this blog post, we will look into the structure of HTTP messages and analyze what’s going on behind the scenes when browsing the web.
HTTP Requests
Simple HTTP Request:
HTTP methods:
The HTTP protocol supports a series of methods. HTTP/1.0 possessed three methods including GET, POST, and HEAD. HTTP/1.1 expanded on this and introduced several new methods. RFC 2616 outlines the following methods to include GET, POST, OPTIONS, HEAD, CONNECT, TRACE, PUT, and DELETE. In 2010, RFC 5789 introduced an additional method for use, PATCH.
Note:
Most application are only going to require the use of the GET and POST methods. HTML only supports the GET and POST methods. Therefore, if an application allows the use of methods outside of GET and POST such as OPTIONS, PUT, DELETE, PATCH, TRACE, or CONNECT, the purpose in which each is required should be carefully evaluated to identify whether this presents any level of security risk to the application or web server.
URLs:
A URL is a Uniform Resource Locator which is a subset group of URIs (Uniform Resource Identifiers). A URL typically holds the following structure:
[Protocol]://[host]/[resource path]?[parameter1]&[parameter2]It’s simply a way to specify the location of a network resource and a way to pass data to a target resource.
HTTP Responses
Simple HTTP Response Example
In the above example, the primary thing we will address is the first line. Line one possesses the HTTP version in use, and the status code returned by the server. A status code is an important piece of an HTTP message because it indicates how the application processed the request.
100 Continue is a response code that is hardly ever seen. The most common status code you will see is a 200 OK. This simply indicates that the request was valid, the resource exists, the server processed the request and returned the resource in the body of the response. 201 on the other hand indicates that the resource specified in the request was successfully created. This usually is the result of a request using the PUT method. 3xx status codes are also often returned by applications, which will contain a link to a resource that the client is to be redirected to in either the response body or the ‘location’ header. 4xx response codes will occur if the requested resource doesn’t exist on the server, the user is not authorized to retrieve such content or if there is an error of some sort in the request sent to the server. 5xx status codes are returned when the server encounters an error and is unable to proceed with processing the request.
HTTP GET Method Request Example
As you can see, the first line consists of the method, the path of the resource with the parameters passed over it, and the HTTP version. The second line specifies the host the request is being sent to. The third line contains information associated with the client’s browser. The forth line specifies what type of data the client is capable of accepting. The fifth line tells the server the language the client is using. The sixth line possesses the cookies, which were retrieved from the server to maintain a session. The seventh line tells the server whether to keep the session alive or close it. The last line is required while using the GET method and is simply blank.
HTTP GET Method Response Example
The response returned possesses a series of HTTP headers discussed earlier in the blog post and a response body.
HTTP POST Method Example:
An HTTP request using the POST method shares a lot of similarities with the previous request we just reviewed using the GET method. The primary difference between the POST and GET method is that the parameters are not passed to the server over the URL’s path of the request but rather the body. This is the method of preference for security purposes in order to communicate sensitive information to the web server because the data within the parameters would not be retrievable from the client’s cache. Considering the parameters being passed within the request contain authentication specific information, it’s important to note that a connection to the server should only be established over HTTPS using TLS to enable a layer of encryption for the data in transit. Two other headers in the example to take note of are the ‘Content-Length’ and ‘Referer’ headers. The ‘Content-Length’ header is simply the length of the requests body in 8-bit bytes called octets. Lastly, the ‘Referer’ header is simply telling the server the origin of the request.
HTTP TRACE Request Method Enabled
HTTP TRACE Method Response Example
In the TRACE method example, as you can see, the server returns everything that was sent within the HTTP request within the body of the response. This may be beneficial in scenarios where the client needs to identify exactly what was received by the server. The TRACK method is another method that functions in the exact same way but is specific to Microsoft IIS. A vulnerability that could be introduced into your web applications environment as the result of the TRACE method being implemented is Cross-Site Tracing (XST). Cross-Site Tracing is a vulnerability that an attacker could potentially leverage in order to steal a victim’s cookies or other authentication related information such as credentials stored within the ‘Authorization’ request header via Cross-Site Scripting (XSS).
HTTP PUT Method Request Example:
The PUT method requires the use of the ‘Content-Length’ HTTP request header. The actual value of the ‘Content-Length’ header is relatively insignificant and can simply be set to zero without causing any interference. If the directory specified within the URLs path of the request already exists on the server, then that resource will be entirely replaced. If the resource specified within the URLs path does not exist on the server then it will be created, assuming this method is implemented on the receiving server. The contents of the resource you wish to create is specified within the body of the request. In the above example a simple html page is created.
HTTP PUT Method Response Example:
Ideally you will want to receive a 201 Created status code in the HTTP response returned by the server. This status code indicates that the resource specified within the request was created. Additionally, you could insert this HTTP request header ‘Expect: 100-continue’ to validate that the server is ready to handle the input your sending to it, and ensure it won’t close the socket on you prior to retrieving the input you specify within the HTTP request body. Using the ‘Expect’ request header should output one of two HTTP status codes within the response returned, 100 Continue or 417 Expectation Failed.
After reviewing the above information, it should be rather apparent as to why this method being implemented on a web server can be a problem. This method could allow an attacker to own your web server. Out in the wild, it’s not too common for this method enabled and allowable but it typically will require credentials stored within the ‘Authorization’ header in the request before the web server will accept the content within the body of the request.
An example of an attack can be found in the screenshot below. In this example a shell is inserted within the body of the of the HTTP request, which if accepted by the server, would allow an attacker to execute commands against the server.
HTTP PUT Method Request with Shell:
HTTP Delete Method Request Example:
HTTP Delete Method Response Example:
The expected status code that the server would return upon successfully deleting the resource specified within the URLs path within the HTTP request would be 200 OK.
HTTP OPTIONS Method Request Example
HTTP OPTIONS Method Response Example
The purpose of this method is to see what methods are allowable on the server. This is not a method that you would be capable of doing any damage with by itself but it can be used as an information gathering tool. It’s important to mention that the output found within the ‘Allow’ HTTP response header can often contain methods that are not implemented on the receiving server but rather the proxy sitting in front of the server if traffic is configured to be tunneled in that manner.
To recap this article provided information associated with HTTP messages, which include requests and responses, and the methods implemented within the HTTP version 1.1 protocol, and how some of these methods can be used to facilitate attacks against web applications. A thorough understanding of the breakdown of HTTP traffic is a necessity to perform attacks within a web application penetration test. Hopefully, this information has delivered a better understanding of the data flow of the HTTP protocol.
Originally authored by Ryan
