search

notes

hashtag
What is HTTP request smuggling?

  • technique for interfering with the way a web stie processes sequences of HTTP requests that are received from one or more users

  • Request smuggling vulnerabilities are often critical in nature, allowing an attacker to

    • bypass security controls

    • gain unauthorized access to sensitive data, and

    • directly compromise other application users

hashtag
What happens in an HTTP request smuggling attack?

  • For most of today's web application, users send requests to a front-end server (load balancer or reverse proxy) and this server forwards requests to one or more back-end servers

  • it typically sends several requests over the same back-end network connection

pic1

  • HTTP requests are sent on after another, and the receiving server parses the HTTP request headers to determine where one request ends and the next one begins

  • In this situation, it is crucial that the front-end and back-end systems agree about the boundaries between requests

  • an attacker might be able to send an ambiguous request that gets interpreted differently by the front-end and back-end systems

pic2

hashtag
How do HTTP request smuggling vulnerabilities arise?

  • the HTTP specification provides two different ways to specify where a request ends: the Content-Length header and the Transfer-Encoding header

  • Content-Length - specifies the length of the message body in bytes

  • Transfer-Encoding - specifies that the message body uses chunked encoding; message body contains one or more chunks of data; each chunk consists of the chunk size in bytes (in hexadecimal) followed by a newline, followed by the chunk contents

  • since the HTTP specification provides two different methods for specifying the length of HTTP messages, it is possible for a single message to use both methods at once, such that they conflict with each other

  • if both headers are present, Content-Length should be ignored (only a single server is in play and not for two or more servers are chained together)

  • if the front-end and back-end servers behave differently for the Transfer-Encoding, then they might disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities

hashtag
How to perform an attack?

  • placing both the Content-Length and Transfer-Encoding headers into a single HTTP request and manipulating these so that the front-end and back-end servers process the request differently

  • it depends on the behavior of the two servers:

    • CL.TE - front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header

    • TE.CL - front-end uses Transfer-Encoding and back-end uses Content-Length

    • TE.TE - both front and back-end support Transfer-Encoding but one of the servers can be induced not to process it by obfuscating the header in some way

hashtag
CL.TE vulnerabilities

  • Front-end server processes the Content-Length header and request body has 13 bytes long, up to the end of SMUGGLED

  • Back-end server processes the Transfer-Encoding which is chunked and processes the first chunk which is stated to be zero length, and treated as terminating the request

  • So, the following bytes, SMUGGLED are left unprocessed and the back-end server will treat these as being the start of next request in the sequence

hashtag
TE.CL vulnerabilities

  • front-end - Transfer-Encoding

  • back-end - Content-Length

  • front-end server processes the Transfer-Encoding header, and treat the message body as using chunked encoding. It processes the first chunk which is stated as 8 bytes long, up to the end of SMUGGLED and it processes the second chunk, which is stated to be zero length and treated as terminating the request. Then forwarded to the back-end server

  • back-end server processes the Content-Length header and determines that the request body as 3 bytes long, up to the end of 8. The following bytes, starting with SMUGGLED are left unprocessed and the back-end server will treat these as being the start of the next request in the sequence.

hashtag
TE.TE behavior: obfuscating the TE header

  • both front and back-end support Transfer-Encoding

  • but one of the servers can be induced not to process it by obfuscating the header

  • many ways to obfuscate the Transfer-Encoding header

  • eg

hashtag
How to identify HTTP request smuggling

hashtag
Using timing techniques

Finding CL.TE vulnerabilities

  • if the application is vulnerable to the CL.TE variant of request smuggling, sending a request like the following will often cause a time delay:

  • front-end uses Content-Length, it will forward only part of this request, omitting X

  • back-end uses Transfer-Encoding, processes the first chunk, and waits for the next chunk to arrive and will cause an observable time delay

Findng TE.CL vulnerabilities

  • front-end uses Transfer-Encoding, it will forward only part of this request, omitting the X

  • back-end uses Content-Length, expect more content in the message body and will cause time delay

hashtag
Confirming HTTP request smuggling vulnerabilities using differential responses

  • sending two requests to the application in quick succession:

    • attack request that is designed to interfere with the processing of the next request

    • normal request

  • if the response to the normal request contains the expected interference, the vulnerability is confirmed.

eg - normal request looks like:

  • This request normally receives an HTTP response with status code 200, containing some search results

  • attack request depends on variant of whether CL.TE vs TE.CL

Confirming CL.TE

  • if the attack is successful, the last two lines of the request are treated by the back-end server as belonging to the next request that is received and cause the subsequent normal request to look like this

  • the request contains an invalid URL, the server will response with status code 404

Confirming TE.CL

  • attack request like this:

  • if the attack is successful, everything from GET /404 onwards is treated by the back-end server as belonging to the next request that is received.

attack request and normal request should be sent to the server using different network connection. Sending both from the same connection won't prove that the vulnerability exists attack request and normal request should use the same URL and parameter names should send the normal request immediately after the attack request

hashtag
Exploiting HTTP request smuggling vulnerabilities

hashtag
Bypass front-end security controls

  • suppose an application uses the front-end server to implement access control restrictions, only forwarding requests if the user is authorized to access the requested URL

  • back-end server honors every request without further checking

  • suppose current user is permitted to access /home but not /admin

  • this can bypass by using the following smuggling attack

hashtag
Revealing front-end request rewriting

  • before sending to backend server, front-end server adds some additional request headers. eg.

    • terminate the TLS connection and add some headers describing the protocol and ciphers that were used

    • add an X-Forwarded-For header containing the user's IP address

    • determine the user's ID based on their session token and add a header identifying the user

    • add some sensitive information that is of interest for other attacks

  • so, in some situations, if your smuggled requests are missing some headers that are normally added by the front-end server, the back-end server might not process the requests in normal way and result in smuggled requests failing to have the intended effects

  • to reveal how the front-end server is rewriting requests

    • Find a POST request that reflects the value of a request parameter into the application's response

    • shuffle the parameters so that the reflected parameter appears last in the message body

    • smuggle this request to the back-end server, followed directly by a normal request whose rewritten from you want to reveal

  • eg - an application that reflects the value of the email parameter

  • that results in

  • for this application, the following request smuggling attack can be used to reveal the rewriting that is performed by the front-end server

  • this requests will be written by the front-end server to include the additional headers, and then the back-end server will process the smuggled request and reflect this value back in the response to the second request

  • for Content-Length header in smuggled request, it should be set a bit bigger than the submitted request and gradually increase the value to retrieve more information

  • if it is known how the front-end server is rewriting requests, it can be applied the necessary rewrites to the smuggled requests, to ensure they are processed in the intended way by the back-end server

hashtag
Bypassing client authentication

  • as part of TLS handshake, servers authenticate themselves with the client (browser) by providing a certificate that contains common name (CN) which should match their registered hostname

  • client can use this to verify that they're talking to a legitimate server belonging to the expected domain

  • CN is often a username which can be used in the back-end application logic as part of an access control mechanism

  • eg -

  • they are completely hidden from users

  • you're able to send the right combination of headers and values and can bypass access controls

hashtag
Capturing other user's requests

  • if the application contains any kind of functionality that allows textual data to be stored and retrieved, HTTP request smuggling can be used to capture the contents of other users' requests which include session tokens, enabling session hijacking attacks, or other sensitive data submitted by the user

  • an application uses the following request to submit a blog post comment which will be stored and displayed on the blog:

  • to perform HTTP request smuggling to the data storage request to the back-end server

  • when another user's request is processed by the back-end server, it will be appended to the smuggled request, with the result that the user's request gets stored including victim user's session cookie and any other sensitive data

hashtag
Turn an on-site redirect into an open redirect

  • default behavior of Apache and IIS web servers, where a request for a folder without a trailing slash receives a redirect to the same folder including the trailing slash

  • with request smuggling attack to redirect other users to an external domain

  • eg

  • the smuggled request will trigger a redirect to the attacker's website, which will affect the next user's request that is processed by the back-end server

Turning root-relative redirects into open directs

  • some servers redirect that use the path to construct a root-relative URL for the Location header

  • to exploit

hashtag
Perform web cache poisoning

Leave for later

hashtag
HTTP/2 Request Smuggling

  • Request smuggling is fundamentally about exploiting discrepancies between how different servers interpret the length of a request

  • HTTP/2 messages are sent over the wire as a series of separate "frames"

  • each frame is preceded by an explicit length field which tells the server exactly how many bytes to read in and the length of the request is the sum of its frame lengths

  • vulnerabilities occur due to HTTP/2 downgrading

HTTP/2 downgrading

  • front-end servers rewrite each incoming HTTP/2 request using HTTP/1 syntax and downgraded request is forwarded to the back-end server and vice versa

HTTP/2 to 1

hashtag
H2.CL vulnerabilities

  • front-end use HTTP/2 length to determine where the request ends but the HTTP/1 back-end has to refer to the Content-Length header derived from the injected one, resulting in a desync

  • HTTP/2 requests don't have to specify their length explicitly in a header

  • during downgrading, front-end servers often add an HTTP/1 Content-Length header, deriving its value using HTTP/2 build-in length mechanism and some front-end servers will reuse this value in the resulting HTTP/1 request

  • any Content-Length header in a HTTP/2 request must match the length calculated using the built-in mechanism but this isn't always validated properly before downgrading; it may be possible to smuggle requests by injecting a misleading Content-Length header

  • eg

    • Front-end (HTTP/2)

    • Back-end(HTTP/1)

PreviousHTTP Request SmugglingNextlabs

Last updated