Proxy Caches are a Challenging Threat to Internet Security

Proxy caches, combined with poorly written session management code, can easily leads to serious security flaws similar to what we highlighted in A New Security Breach in Google Docs Revealed.

Web developers have no control over proxy caches in the Internet. However, developers do have control of the code they write and their admin teams have configuration control of their web servers. Developers must assume the worst case Internet scenario with aggressive Internet cache management policies that serve cached data for economic and performance reasons.

As a consequence, this fact-of-life on the Internet sometimes results in multiple web clients being sent the same Set-Cookie HTTP headers, for example.  Caching proxy servers should obtain a fresh cookie for the each new client request. Ideally, proxy caches should not cache session management cookies and distribute cached cookies to multiple clients. However, application developers cannot assume that proxy caches are well behaved, especially for applications where security and privacy are required.

Web developers cannot know whether their content is consumed directly or via a proxy cache. Developers also cannot assume that the HTTP responses will be delivered to the intended browser. Moreover, developers cannot be sure that the intended browser even receives the intended content.  For example, a session ID issued to a client gets used while it is valid or until abandoned and expired. If it is served and delivered in response to an unencrypted HTTP GET request, there’s no guarantee it will be consumed by the intended web browser.

Ideally, SSL should be used on all web transactions that require confidentiality and privacy, including our recent Google Docs breach.  On the other hand, even SSL is not foolproof. For example, many web developers do not correctly set the "Encrypted Sessions Only" cookie property. These incorrectly configured “secure” servers will send HTTPS cookies in the open, unencrypted.

There be dragons …..

Comments

[Ya]

I agree but without cookies , do we have any way to identify user?
a lot of Web developers, they are now aware of Web Denial of services then and one of the solution they are now using is cookie.

[Tim Bass]

Hi Ya,

Cookies are a fact-of-life for web session management. As I mentioned in my post, it is up to web developers to insure (1) session management code is well written and tested in scenarios with aggressive proxies caches, and (2) SSL is used and properly configured.

This means that both the application developer and the web server systems administrator must work to secure their web application via robust session management code and properly configured encryption (SSL).

In other words, even very well written session management code can be compromised by proxy caches if cookies are not encrypted propertly.

Yours faithfully, Tim

[KahYi Chin]

It does sound like those free anonymous proxy service in the internet is most probably another way to steal user information. Because no one simply know if they are properly written or not. If that is the case, user awareness is essential so they don't simply connect. We don't have statistics what is the risk of using these proxies other than the well known benefit of being able to bypass company web filtering and access control.

[BPO Services]

Fine passage regarding the proxy set ups, proxy cashes may stack, also what about the proxy using to unblock the sonic fire wall blocked sites?

Regards

SBL - BPO Services

[Clerkendweller]

A useful reminder about mis-configured, malicious or non standards compliant proxies.

One practice is to check a session cookie against other parameters such as user agent and accepted encodings & languages, but many frameworks don't allow this. Sometimes, this might catch the problem.

Also on sites that have third party content, sometimes that content is not available in SSL. For example Amazon adverts, Google AdSense and Google Maps do not support SSL and this raises warnings about mixed mode in some browsers. I have heard this as a reason not to use SSL on a website more than once.