Request Smuggling Vulnerability

Basel Al-Sayed

Software Engineer @ Foothill Solutions

Introduction

  • Http requests are sent over network in binary data format.
  • the server needs to interpret that network traffic and convert it to multiple requests.

Introduction

  • Since there are always will be subsequent requests to the target server, It needs to use a mechanism to determine the boundary of each request (i.e where the request begins, ends and the next request begins) and so on.
  • Each request must have be supplied with (in the header) of what the mechanism is used to determine its boundary.

Specifying the Boundary

There are two approaches to determine the boundary of each single request:

  1. Content Length Header: it specifies the length of the message body in bytes

Specifying the Boundary

  1. Transfer Encoding Header: used to specify that the message body uses chunked encoding.
    • The message body contains one or more chunks of data.
    • Each chunk consists of (the chunk size in bytes, a new line, and the chunk’s contents).
    • The request body is terminated with a chunk of size zero.

Specifying the Boundary

The Architecture

The Architecture

  • The frontend server could be: caching server, proxy, firewall, load balancer
  • The backend server: is the resource server

The Issue

  • The issue appear when we have more that one server transferring the request
  • Each server is free to use and support any mechanism to determine the request boundary
  • The issue arises when the servers processing the same request use different mechanisms.
    • So what is considered as an end of request to one server, it might be not considered the same from the second server perspective and it keep waiting for the request to complete (and vise versa)

The Issue

What if the Servers has determined the boundary in a wrong way?

  • The server has to determine the request boundary in order to server it correctly (fulfill the request purpose)
  • The server serves requests are from different clients, so each request should be totally separated from other requests, If not so, the requests will be overlapped and wrong responses will be sent to the users which may affect the user experience, privacy and the application security.

HTTP Request Smuggling

HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users

Request Smuggling Attack Requirements

  • When we have two or more servers process the same request. (ex. load balancer arch.)
  • The two mechanisms have to be specified in the request (content Length and transfer encoding)

Request Smuggling Attack Requirements

  • Server does not support the transfer encoding technique
    • When both techniques are specified, the transfer encoding well be considered and the content length will be ignored.

The Impact of Request Smuggling

  • Bad user experience
  • Session Hijacking
  • Bypass security controls
  • Cache poisoning
  • Bypassing client authentication

How It works?

Consider the following scenario, in this network traffic which sent by a client application, the two target servers may interpret it differently!

How It works?

Let’s assume that:

  • the front-end server uses the content length: so it will see two requests for /home
  • The backend server uses the transfer encoding: so it will see one request for /home and another request for /admin

So What ?!
Where is the issue here ?

The server will send back wrong responses accordingly
which will harm the user experience

And ... guess what else?

Exploiting request smuggling vulnerabilities: bypass front-end security controls

  • In a situation where the front-end web server is used to implement some security controls, deciding whether to allow individual requests to be processed. Allowed requests are forwarded to the back-end server.

Exploiting request smuggling vulnerabilities: bypass front-end security controls

  • The back-end server will assume every request reached to it is allowed and will process it without further checking
  • In the previous scenario, assume that is the case, so the user who access to /home will always get access to /admin

Protection Against HTTP Request Smuggling

  • Use the same boundary mechanism in all servers that process the requests as much as possible.
  • Detect and block ambiguous requests

Protection Against HTTP Request Smuggling

  • Prefer HTTP/2 over HTTP/1: since it uses a robust mechanism for determining the length of requests
    • Much better when it’s used as end-to-end (i.e both servers uses the HTTP/2)
    • Since some servers only support HTTP/1 we may have to perform HTTP downgrade (from HTTP/2 to HTTP/1)

HTTP Downgrading Attack

  • The attacker forces a network channel to switch to an unprotected or less secure data transmission standard.
  • It is a man-in-the-middle attack, in which the traffic is intercepted.
  • Example: redirecting a user from an HTTPS version of a resource to an HTTP copy.
  • To avoid such attack: make sure you validate the rewritten request against the HTTP/1.1 specification and standards.

Structures are vulnerable to the attack

  • Caching server
  • Proxy server: any sever that prevent direct access to the backend server
  • Load balancer
  • WAF (Firewall)

Thank You