[WEB SECURITY] "Meanwhile, on the other side of the web server" - a writeup by Amit Klein
rcbarnett at gmail.com
Thu Jun 9 21:08:07 EDT 2005
This is great stuff! You know, it might be worth mentioning the
different techniques used to identify intermediary devices such as
proxies, etc... This would need to be accomplished prior to running
the attacks that you outline. Here are some examples -
1) Use of the HTTP TRACE Method
The old traceroute for the web - You can send off the trace request to
web sites and any intermediate HTTP proxies will add their name to the
"Via" header. I am still surprised at the number of proxies that are
still forwarding TRACE requests...
2) Inspecting Location Response Headers
Reverse proxies may leak the back-end host within the location header.
3) Hostname disclosures
DNS lookups and some error pages from proxies may disclose a hostname
that indicates that it is a proxy. Take a look at the Netcraft
SearchDNS interface. I put in a search for any domain name that
starts with "cache.*" and it returned over 300 entries -
4) Virtual Hostname Errors
You might also be able to identify reverse proxies by munging the
"Host:" request header. You could leave it blank, leave off the
domian extension or append a dot at the end - such as
"www.companyx.com." - as different reverse proxies handle the requests
differently (semantic) and display different status codes and error
5) HTTP Fingerprinting
A tool such as HTTPrint may be able to identify some HTTP devices (the
current signature set has a few fingerprints that may help such as for
Those are all I can think of off the top of my head. Does anyone else
have any techniques for identifying intermediate proxies, etc...???
Again, great work with presenting this data. It is certainly an area
that security professionals need to examine with trying to secure a
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
On 6/9/05, Amit Klein (AKsecurity) <aksecurity at hotpop.com> wrote:
> 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
> 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
> 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 , 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 , p. 4
> – "Special Cases – more powerful attacks").
> 3. Escalation of XSS condition (see ), if such exists in the
> 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 ).
> 2. Partial web cache poisoning (through HTTP Request Smuggling – see
> 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 , p. 7
> – "Example #4 – Request Hijacking").
> 2. Forceful submission of a request on behalf of a client (see ,
> p. 9 – "Example #5 – Request Credential Hijacking").
> 3. Cross user defacement, if there is an HTTP Response Splitting
> vulnerability in the web site (see  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  p. 23 –
> "Hijacking a Page (HTTP Response) with User Sensitive
> 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 ,
> 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 ,
> ), 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
> 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  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  may be used to
> fool these devices into routing requests to other servers instead.
> 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.
>  "Divide and Conquer - HTTP Response Splitting, Web Cache
> Poisoning Attacks, and Related Topics", Amit Klein, March 2004.
>  "HTTP Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled
> and Steve Orrin, June 2005
>  "XS(T) attach variants which can, in some cases, eliminate the
> need for TRACE", Amit Klein, WebAppsec mailing list posting,
> January 26th, 2003
>  "External Web Application Protection: Impedance Mismatch", Ivan
> Ristic, March 9, 2005
>  "A look at whisker's anti-IDS tactics", Rain Forest Puppy,
> December 1999
> The Web Security Mailing List
> The Web Security Mailing List Archives
More information about the websecurity