CAPEC-33 - HTTP Request Smuggling

HTTP Request Smuggling results from the discrepancies in parsing HTTP requests between HTTP entities such as web caching proxies or application firewalls. Entities such as web servers, web caching proxies, application firewalls or simple proxies often parse HTTP requests in slightly different ways. Under specific situations where there are two or more such entities in the path of the HTTP request, a specially crafted request is seen by two attacked entities as two different sets of requests. This allows certain requests to be smuggled through to a second entity without the first one realizing it.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 2
  • Protocol Manipulation
  • Injection
  • Purposes 1
  • Penetration
  • Sec Principles 2
  • Economy of Mechanism
  • Securing the Weakest Link
  • Scopes 3
  • Execute unauthorized code or commands
  • Availability
  • Integrity
  • Confidentiality
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality
  • Modify application data
  • Integrity

High level: The attacker has to have detailed knowledge of the HTTP protocol specifics and must also possess exact details on the discrepancies between the two targeted entities in parsing HTTP requests.

An additional HTTP entity such as an application firewall or a web caching proxy between the attacker and the second entity such as a web server

Differences in the way the two HTTP entities parse HTTP requests

None

If system documentation is available, the attacker can look up the exact versions of the two targeted entities, since different versions of the same system often behave differently. The attacker can also use product-specific documentation to figure out differences in parsing HTTP requests between the two entities.

In case where no documentation is available, the attacker needs to reliably fingerprint the targeted entities to discover the nature and version of the entities. Having done this, the attacker then needs to experimentally determine how the two entities differ in parsing requests.

Carefully Study Other Systems Before Incorporating Them into Your System

Design Configuration Subsystems Correctly and Distribute Safe Default Configurations

Step 1 - Identify HTTP parsing chain

Determine the technologies used in the target environment such as types of web servers, application firewalls, proxies, etc..

Tecnique ID: 1 - Environment(s) env-Web

Investigation of the target environment to determine the types of technologies used to parse the incoming HTTP requests. Attempt to understand the parsing chain traversed by the incoming HTTP request.

Outcome ID: 1

Type: Success

Full HTTP parsing chain for the application has been identified



Step 1 - Probe for vulnerable differences in HTTP parsing chain

Attacker sends malformed HTTP Requests to the application looking for differences in the ways that individual layers in the parsing chain parse requests. When differences are identified, the attacker crafts specially malformed HTTP requests to determine if the identified parsing differences will allow extra requests to be smuggled through parsing layers..

Tecnique ID: 1 - Environment(s) env-Web

Create many consecutive requests to the server. Some of which must be malformed.

Tecnique ID: 2 - Environment(s) env-Web

Use a proxy tool to record the HTTP responses headers.

Indicator ID: 1 - Environment(s) env-Web

Type: Positive

At some point, the server is waiting for more request information to send the last response.

Indicator ID: 2 - Environment(s) env-Web

Type: Inconclusive

No response is being received.

Indicator ID: 3 - Environment(s) env-Web

Type: Negative

Malformed HTTP requests are being totally ignored.

Indicator ID: 4 - Environment(s) env-Web

Type: Negative

Responses are being sent even if the HTTP header is incomplete.


Security Control ID: 1

Type: Detective

Monitor requests to the server that seem malformed.


Outcome ID: 1

Type: Success

One layer in the application's HTTP parsing chain processes HTTP Requests that other layers do not. The server smuggles the user request into the last attacker's request and transport data such as cookie, etc.

Outcome ID: 2

Type: Failure

The server replies with an error to the last attacker's request.

Outcome ID: 3

Type: Inconclusive

No response for the last incomplete request from the attacker by the server



Step 1 - Cache poisoning

The attacker decides to target the cache server. The server will then cache the request and serve a wrong page to a legitimate user's request. The malicious request will most likely exploit a Cross-Site Scripting or another injection typed vulnerability..

Tecnique ID: 1 - Environment(s) env-Web

Leverage the vulnerabilities identified in the Experiment Phase to inject malicious HTTP request that contains HTTP Request syntax that will be processed and acted on by the outer parsing layer of the cache server but not by the inner application layer. In this way it will be cached by the server without obvious sign from the application and the corrupt data will be served to future requesters.

Security Control ID: 1

Type: Detective

Monitor server logs for consecutive suspicious HTTP requests.


Outcome ID: 1

Type: Success

The attacker gets the users to be served with this cached malicious HTTP request.


Step 2 - Session Hijacking

The attacker decides to target the web server by crafting a malicious HTTP Request containing a second HTTP Request using syntax that will not be processed and acted on by an outer "filter" parsing layer but will be acted on by the inner web server/application processing layers. The application/web server will then act on the malicious HTTP Request as if it is a valid request from the client potentially subverting session management..

Tecnique ID: 1 - Environment(s) env-Web

Leverage the vulnerabilities identified in the Experiment Phase to inject malicious HTTP request that contains HTTP Request syntax that will not be processed and acted on by the outer parsing layer of the malicious content filters but will be by the inner application/web server layer. In this way it will be acted on by the application/web server as if it is a valid request from the client.

Security Control ID: 1

Type: Preventative

Monitor server logs for consecutive suspicious HTTP requests.


Outcome ID: 1

Type: Success

The attacker gets the application/web server to act on the malicious HTTP request and allows the attacker to gain control of the target user's session.



System integration testing must include security checks to protect against Multiple Interpretation Errors across systems.

HTTP Request Smuggling is usually targeted at web servers. Therefore, in such cases, careful analysis of the entities must occur during system design prior to deployment. If there are known differences in the way the entities parse HTTP requests, the choice of entities needs consideration.

Employing an application firewall can help. However, there are instances of the firewalls being susceptible to HTTP Request Smuggling as well.