Secure coding

Introduction to HTTP (What Makes HTTP Vulnerabilities Possible)

December 8, 2020 by Srinivas

Understanding HTTP protocol and risks associated with the improper use of it in applications is an important step towards understanding application security. Web applications heavily rely on HTTP protocol for data exchange between the client and server. During this process, there are several concepts a web developer must understand to avoid security risks. This article covers various concepts such as HTTP requests, responses, headers, statelessness and what parts of a HTTP request can be exposed to vulnerabilities.

What is HTTP?

According to Mozilla developer documentation, “HTTP is a protocol which allows the fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance text, layout description, images, videos, scripts, and more”.

HTTP is a simple text based protocol built on top of TCP/IP. It means, when a HTTP request is sent from a client, it requires a TCP connection to be established with the server. Default port number for HTTP is 80. However, just like any other service, we can run it on other ports as well. 

Requests and Responses

During HTTP communications, clients (Eg: Browsers, curl, netcat etc.) and servers communicate with each other by exchanging individual messages. Each message sent by the client is called a request and the messages received from the server are called responses. 

Following is a sample HTTP Request:

POST /xvwa/vulnerabilities/sqli/ HTTP/1.1

Host: 192.168.1.105

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 14

Origin: http://192.168.1.105

Connection: close

Referer: http://192.168.1.105/xvwa/vulnerabilities/sqli/

Cookie: PHPSESSID=fjv5te289b8he60k9qoss7ldj5

Upgrade-Insecure-Requests: 1

item=2&hidden=1&search=

 

The preceding request contains headers and body. Let us go through some of the headers. The following line from the preceding request specifies that the request method is POST. Usually, POST method is used to submit content to the server whereas GET method is used to request for content. 

POST /xvwa/vulnerabilities/sqli/ HTTP/1.1

 

We have various other methods existing in HTTP such as TRACK, TRACE, PUT, DELETE and OPTIONS. When a request is sent using the GET method, the parameters will be passed through the URL.

Next, the following line in the request specifies the domain name or the IP address of the server with which the client is interacting with. In our case, it is 192.168.1.105

Host: 192.168.1.105

 

Next, let us take a look at the user-Agent header.

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0

 

User-Agent header field helps the server to identify the client software originating the request.

If it is a client other than firefox, the value will be different. For example, we may see the following if the request is sent from curl instead of the browser.

User-Agent: curl/7.30.0

 

Next, let us observe the line with the header Accept.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

 

As we can notice, there are several values specified by the browser in this header. Accept header specifies the Content-Types that are acceptable for the response. Wildcards are also supported to represent any type.

Next, the following header shows the cookie being sent to the server. Cookies are usually used to identify the logged in user.

Cookie: PHPSESSID=fjv5te289b8he60k9qoss7ldj5

 

Lastly, we can see the parameters being passed from the web application to the server in the following excerpt.

item=2&hidden=1&search=

 

There are a few parameters, which also include a parameter named hidden that appears to be a hidden parameter.

Following is a sample HTTP Response returned from the server.

HTTP/1.1 200 OK

Date: Sat, 12 Dec 2020 07:02:06 GMT

Server: Apache/2.4.7 (Ubuntu)

X-Powered-By: PHP/5.5.9-1ubuntu4.19

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Vary: Accept-Encoding

Content-Length: 9819

Connection: close

Content-Type: text/html

<!DOCTYPE html>

<html lang=”en”>

<head>

    <meta charset=”utf-8″>

    <meta http-equiv=”X-UA-Compatible” content=”IE=edge”>

    <meta name=”viewport” content=”width=device-width, initial-scale=1″>

    <meta name=”description” content=””>

    <meta name=”author” content=””>

    <title>XVWA – Xtreme Vulnerable Web Application </title>

…REDACTED…

 

As we can notice, the response contains several headers along with the requested content.

What makes HTTP vulnerabilities possible?

When a web application is developed, it can be susceptible to several different attacks depending on the features the application has. The attacks can range from a simple authentication bypass using default credentials setup to complex attacks based on encryption/decryption and other bypasses. 

Attackers often look for easy ways to attack applications and thus it is important to understand basic problems that can be possible when using HTTP.

Entry points in a HTTP Request

As we can see in the request part of an HTTP communication, there are several fields that can be controlled or tampered by an attacker since they are being sent from the client.

  • Cookies
  • Request headers
  • GET parameters
  • POST parameters
  • Hidden form fields

Most of the attacks against web applications originate due to the poor usage of one of the entry points mentioned above. 

Cookies

HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. But some web applications may have to track the user’s progress from page to page, for example when a web server is required to customize the content of a web page for a user. One of the solutions for this case is use of sessions in the form of cookies. Cookies are as powerful as authentication credentials and user sessions can be compromised if cookies are stolen. Additionally, if cookie values are processed by the server side code, it is possible for other injection based attacks such as deserialization, path traversal and SQL injection.

Request headers

As we observed earlier, there are several request headers sent to the server in each request. There are several attacks possible by header manipulation. For example, host header injection is an attack that is possible when the server redirects the user to a user controlled domain due to a tampered host header. Similarly, attacks based on cross origin resource sharing are performed by manipulating Origin header in a http request.  

GET and POST parameters

Dynamic websites commonly use GET and POST parameters to retrieve content and submit content. These parameters are often susceptible to vulnerabilities due to poor validation on their values. Several types of attacks such as Injection, redirection, deserialization are possible against the websites when these GET and POST parameters are poorly used in web applications.

Hidden form fields

Similar to GET and POST parameters, hidden fields are often poorly used in web applications. Hidden form fields are only to hide data in the clients such as browsers and the data used in hidden fields still has to go in a HTTP request to the server in the form of request parameter or header. Developers often do not realize that these hidden fields can be tampered using an intercepting proxy and these treat hidden form fields as a security protection. 

Conclusion

As discussed in this article, applications using HTTP protocol can be susceptible to various attacks due to the poor design choices and developer mistakes. In the next article we will discuss how to exploit HTTP based vulnerabilities.

 

Sources

  1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
  2. https://owasp.org/www-project-top-ten/
  3. https://sucuri.net/guides/owasp-top-10-security-vulnerabilities-2020/
Posted: December 8, 2020
Articles Author
Srinivas
View Profile

Srinivas is an Information Security professional with 4 years of industry experience in Web, Mobile and Infrastructure Penetration Testing. He is currently a security researcher at Infosec Institute Inc. He holds Offensive Security Certified Professional(OSCP) Certification. He blogs atwww.androidpentesting.com. Email: srini0x00@gmail.com

Leave a Reply

Your email address will not be published. Required fields are marked *