"Meanwhile, on the other side of the web server" - a new write-up by Amit Klein
Meanwhile, on the other side of the web server
A survey of new attacks on the less explored parts
of the web application
Amit Klein, June 2005
Introduction
============
In the beginning, there were the web servers, and they were attacked
(e.g. CodeRed, Nimda), and people learned how to configure web
servers and patch them, and it was good.
Then the dynamic pages and application servers were added, and they
were attacked (XSS, file inclusion/retrieval, price mutation, cookie
poisoning, etc.), and people learned how to sanitize input, and
encode output, and it was good.
Then the backend SQL databases and mainframes and backend servers
were "discovered", and they were attacked, and people learned how to
build parameterized SQL queries, and to avoid various injection
scenarios, and it was good.
Meanwhile, on the other side of the server, servers, devices and
appliances were silently added to the "web presence" of the
application, and these were studied and understood very little. The
other side of the web server, all those web/network "stuff" between
(or alongside) the web-server and the client (browser), and their
impact on security, is the subject of this write-up.
The major claim of this write-up is that we should start looking at
the communication between the web server and the client.
Specifically, we should take a good hard look at the HTTP-aware
entities that process the HTTP requests and responses passing to and
fro between the client and the server. Of course, oftentimes adding
a component to a system increases the overall insecurity, since this
component may be directly broken into. But the more interesting
thing about these entities is that there?s an additional risk here:
a security problem that materializes in a combination of entities,
or (specifically) in the interaction between an entity and the web
application. It is these problems that we?re going to focus on.
Below is a list of such HTTP-aware entities:
(*) 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)
(*) (and there are probably more?)
There are also issues with web-sites that are virtually hosted, i.e.
the same physical web server hosts several sites not in the same
domain (or ownership). We can think of this case as an interaction
between entities such as the web server software and the two virtual
sites.
The known problems
==================
Virtual hosts
-------------
Running a web site as a virtual host, alongside with other,
untrusted virtual hosts, on the same physical server, sharing the
same port (as is usually the case ? this would be port 80), can
result in the following conditions:
1. If there?s also a cache server that shares a TCP connection from
a client to two virtual hosts with the same IP address - Complete
web cache poisoning through HTTP Response Splitting (see [1], p.
26 ? "Cross-host web cache poisoning attack").
2. If there?s also a cache server that shares a TCP connection from
a client to two virtual hosts with the same IP address - Complete
web cache poisoning through HTTP Request Smuggling (see [2], p. 4
? "Special Cases ? more powerful attacks").
3. Escalation of XSS condition (see [3]), if such exists in the
site.
Cache servers (which are proxy servers by definition)
-----------------------------------------------------
Having the HTTP traffic pass through cache servers can result in:
1. Complete web cache poisoning (if there?s an HTTP Response
Splitting vulnerability in the web application ? see [1]).
2. Partial web cache poisoning (through HTTP Request Smuggling ? see
[2]).
Proxy servers (not necessarily caching)
---------------------------------------
Having the HTTP traffic pass through proxy server that shares a TCP
connection to the same host between different clients can result in:
1. Escalating of XSS condition into request hijacking (see [2], p. 7
? "Example #4 ? Request Hijacking").
2. Forceful submission of a request on behalf of a client (see [2],
p. 9 ? "Example #5 ? Request Credential Hijacking").
3. Cross user defacement, if there is an HTTP Response Splitting
vulnerability in the web site (see [1] p. 22 ? "Cross User
Attacks ? The Theory").
4. Hijacking a user response page, if there is an HTTP Response
Splitting vulnerability in the web site (see [1] p. 23 ?
"Hijacking a Page (HTTP Response) with User Sensitive
Information").
HTTP-Aware firewalls (including Web Application Firewalls)
----------------------------------------------------------
While these entities are put in place to protect the application, in
some cases they can be completely or partially bypassed. This in
itself does not mean that the application becomes vulnerable.
However, these "attacks" are listed because they have to do with how
various web-server behaviors enable some attacks (especially in HTTP
Request Smuggling). These "attacks" are:
1. Smuggling a complete request via HTTP Request Smuggling (see [2],
especially p. 4 ? "Example #2: Firewall/IPS/IDS evasion"), that
is, the firewall/IDS won?t block/detect a request (an attack) it
should have.
2. Bypassing some firewall/IDS protection/detection schemes (see [4],
[5]), that is, the firewall/IDS won?t block/detect a request (an
attack) it should have.
So the net effect in this case is that the security of the overall
system is affected by the combination of entities. The only
difference between this item and the previous ones is that in this
item, a security tier (the firewall/IDS) was bypassed, thus
potentially exposing system vulnerabilities, while in the previous
items, the system was shown to be directly vulnerable to attacks.
Web Application Firewalls
-------------------------
Some WAFs employ a technique in which the HTML responses of the
application are used to create a dynamic, per-user policy of allowed
links/forms/actions. In such case, an attack against the WAF?s
security policy would be to inject a link (which represents an
attack against the web server, e.g. a Nimda URL) somehow into the
HTML response. This link would in turn be allowed by the WAF for the
user (the attacker, in this case), who will happily request this
link immediately thereafter. Just like the previous item, this
"attack" simply punctures through the protection suite of the WAF,
it is not a vulnerability in the application. Yet just as the
previous item, the "interaction" between the application and the WAF
may weaken the WAF protection and thus expose vulnerabilities in the
system.
Load balancers and SSL accelerators
-----------------------------------
While no specific attack was reported for these products (other than
attacks that target the devices themselves), it is expected that the
techniques outlined in [2] are applicable to load balancers and to
SSL accelerators, since these devices typically look at the HTTP
requests and route them to their final destination according to the
parsed requests. In that sense, the techniques in [2] may be used to
fool these devices into routing requests to other servers instead.
Summary
=======
The web application, or rather, the web application security,
extends beyond the web server (or the virtual web server), not only
in the backend?s direction, but also in the browser?s direction ? to
the site?s cache/proxy server, SSL accelerator, load balancer, IDS,
firewall and web application firewall, and beyond that, to the
client?s ISP cache/proxy server. It also extends to the neighboring
virtual web servers. More research and understanding is needed in
these areas, in order to comprehend all possible risks and develop
appropriate solutions for them.
References
==========
[1] "Divide and Conquer - HTTP Response Splitting, Web Cache
Poisoning Attacks, and Related Topics", Amit Klein, March 2004.
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[2] "HTTP Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled
and Steve Orrin, June 2005
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
[3] "XS(T) attach variants which can, in some cases, eliminate the
need for TRACE", Amit Klein, WebAppsec mailing list posting,
January 26th, 2003
http://www.securityfocus.com/archive/107/308433
[4] "External Web Application Protection: Impedance Mismatch", Ivan
Ristic, March 9, 2005
http://www.modsecurity.org/blog/archives/000053.html
[5] "A look at whisker's anti-IDS tactics", Rain Forest Puppy,
December 1999
http://www.ussrback.com/docs/papers/IDS/whiskerids.html