HTTP request smuggling

Last updated

HTTP request smuggling (HRS) is a security exploit on the HTTP protocol that takes advantage of an inconsistency between the interpretation of Content-Length and Transfer-Encoding headers between HTTP server implementations in an HTTP proxy server chain. [1] [2] It was first documented in 2005 by Linhart et al. [3]

Contents

The Transfer-Encoding header works by defining a directive on how to interpret the body of the HTTP request, with the common and necessary directive for this attack being the chunked transfer encoding. [4] When the Transfer-Encoding header is present, the Content-Length header is supposed to be omitted. [4] Working similarly but with a different syntax, the Content-Length header works by specifying the size in bytes of the body as a value in the header itself. [5] Vulnerabilities arise when both of these headers are included in a malicious HTTP request, bypassing security functions meant to prevent malicious HTTP queries to the server by causing either the front-end or back-end server to incorrectly interpret the request. [6] HTTP request smuggling commonly takes the form of CL.TE, TE.CL, or TE.TE, although more complex attacks using HRS do exist. [6]

Types

CL.TE

In this type of HTTP request smuggling, the front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header. [2] The attack would be carried out with the first part of the request declaring a zero length chunk. [6] The front end server seeing this would only read the first part of the request and unintentionally pass the second part to the back end server. [6] Once passed through to the back end server, it would be treated as the next request and processed, carrying out the attackers hidden request. [6]

TE.CL

In this type of HTTP request smuggling, the front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header. [2] In this attack, a hacker would declare the valid length of the first chunk, which houses the malicious request and then declare a second chunk with a length of 0. [6] When the front end server sees the second chunk with a length of 0 it believes the request to be complete and passes it along to the back end server. [6] The back end server processes the request using the Content-Length header, however, and as a result the malicious request left in the first chunk go unprocessed until they are treating as being at the start of next request in the sequence and are carried out. [2]

TE.TE

In this type of HTTP request smuggling, the front end and backend both process the request using Transfer-Encoding header, but the header can be obfuscated in a way (for example by nonstandard whitespace formatting or duplicate headers) that makes one of the servers but not the other one ignore it. [2] Obscuring the header may take the form of adding in an incorrect character, such as Transfer-Encoding: xchunked, or an unusual new line character between 'Transfer-Encoding' and ': chunked'. [6] If one of the front of back end servers still processes these obfuscated HTTP requests, then the rest of the attack will be similar to how CL.TE or TE.CL attacks work. [6]

Prevention

The best prevention to these attacks would clearly be if front end and back end servers interpreted HTTP requests the same way. However, this is usually not an option as load balancers support backend servers run on distinct platforms, using different software. [6] Most variants[ specify ] of this attack can be prevented by using HTTP/2, as it uses a different method to determine the length of a request. Another method of avoiding the attack is for the frontend server to normalize HTTP requests before passing them to the backend, ensuring that they get interpreted in the same way. [2] Configuring a web application firewall is another good way to prevent HRS attacks as many feature technology that identify attack attempts and either blocks or sanitize the suspicious incoming requests. [6]

Grenfeldt et al. (2021) found that most front-end web servers (e.g. proxy servers) provided the parsing features for hindering in practice, all the known HRS attacks on the back-end web servers. [7] Huang et al. (2022) proposed a method using Flask so to implement suitable parsing features that prevent HRS attacks, from a front-end program or web server. [8]

Related Research Articles

In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">Proxy server</span> Computer server that makes and receives requests on behalf of a user

In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource.

A Web cache is a system for optimizing the World Wide Web. It is implemented both client-side and server-side. The caching of multimedias and other files can result in less overall delay when browsing the Web.

URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org.

<span class="mw-page-title-main">Reverse proxy</span> Type of proxy server

In computer networks, a reverse proxy is an application that sits in front of back-end applications and forwards client requests to those applications. Reverse proxies help increase scalability, performance, resilience and security. The resources returned to the client appear as if they originated from the web server itself.

<span class="mw-page-title-main">Same-origin policy</span> Security measure for client-side scripting

In computing, the same-origin policy (SOP) is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.

The Internet Content Adaptation Protocol (ICAP) is a lightweight HTTP-like protocol specified in RFC 3507 which is used to extend transparent proxy servers, thereby freeing up resources and standardizing the way in which new features are implemented. ICAP is generally used to implement virus scanning and content filters in transparent HTTP proxy caches. Content adaptation refers to performing the particular value added service for the associated client request/response.

The Simple Common Gateway Interface (SCGI) is a protocol for applications to interface with HTTP servers, as an alternative to the CGI protocol. It is similar to FastCGI but is designed to be easier to parse. Unlike CGI, it permits a long-running service process to continue serving requests, thus avoiding delays in responding to requests due to setup overhead.

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

<span class="mw-page-title-main">HTTP compression</span> Capability that can be built into web servers and web clients

HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page, from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. No knowledge of the data stream outside the currently-being-processed chunk is necessary for both the sender and the receiver at any given time.

<span class="mw-page-title-main">HTTP persistent connection</span> Using a single TCP connection to send and receive multiple HTTP requests/responses

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

<span class="mw-page-title-main">Byte serving</span> HTTP facility to fetch a specific part of a file

Byte serving is the process introduced in HTTP protocol 1.1 of sending only a portion of a message from a server to a client. Byte serving begins when an HTTP server advertises its willingness to serve partial requests using the Accept-Ranges response header. A client then requests a specific part of a file from the server using the Range request header. If the range is valid, the server sends it to the client with a 206 Partial Content status code and a Content-Range header listing the range sent. If the range is invalid, the server responds with a 416 Requested Range Not Satisfiable status code.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

Server-side request forgery (SSRF) is a type of computer security exploit where an attacker abuses the functionality of a server causing it to access or manipulate information in the realm of that server that would otherwise not be directly accessible to the attacker.

References

  1. ↑ "CWE - CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') (4.0)". cwe.mitre.org. Retrieved 2020-03-13.
  2. 1 2 3 4 5 6 "What is HTTP request smuggling? Tutorial & Examples | Web Security Academy". portswigger.net. Retrieved 2020-03-13.
  3. ↑ Linhart, Chaim; Klein, Amit; Heled, Ronen; Orrin, Steve (2005). "HTTP request smuggling" (PDF).
  4. 1 2 "Transfer-Encoding". developer.mozilla.org. Retrieved 2022-12-15.
  5. ↑ "Content-Length". developer.mozilla.org. Retrieved 2022-12-15.
  6. 1 2 3 4 5 6 7 8 9 10 11 "HTTP Request Smuggling". imperva.com. Retrieved 2022-12-15.
  7. ↑ Grenfeldt M, Olofsson A, Engström V, Lagerström R (2021). "Attacking websites using HTTP request smuggling: empirical testing of servers and proxies". 2021 IEEE 25th international enterprise distributed object computing conference (EDOC). Australia: IEEE. pp. 173–181. doi:10.1109/EDOC52215.2021.00028.
  8. ↑ Huang Q, Chiu M, Chen Y, Sun H (2022). "Attacking websites: detecting and preventing HTTP request smuggling attacks". Security and Communication Networks. 2022: 1–14. doi: 10.1155/2022/3121177 .
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.