Friday, June 01, 2012

HTTP 304 Not Modified Bad Privacy compromise Security

For a software to be vulnerable there must be a bug but we all know bugs are inevitable so vulnerabilities will always exist.

However something might be vulnerable and yet no major impact will be received from an exploit if the system does not have what the attacker is looking for. Think now of a "honeypot".

Users make decisions in their local Browser that affect their privacy and without knowing it they become vulnerable to an exploit that otherwise won't cause much damage.

Software Engineers can do a lot more than just applying patches when vulnerabilities are discovered. Think about the pill for Colesterol versus changing the lifestyle. Software Engineers can design systems that correctly use caching (for increased performance but with minimum impact in security)

If your application is generating too many HTTP 304 codes (Not Modified) it might mean browsers are asking for resources that should be cached. If on the contrary you do not get 304 ever it might actually mean browsers are caching forever! That might be really bad news for the security of your users.

Take a look at your Server headers and make sure "Expires" and "Cache-Control" directives are used effectively. Get rid of those 304 ensuring your customers will not keep resources locally. The Browser cache is a high Privacy liability, use it wisely to increase the Security of your customers and yours (Remember your application is as weak as the weakest component and your customers/users are indeed part of it).

I have blogged in the past how to achieve correct caching with tomcat and today I can confirm tomcat 7 does a great job after using that ExpiresFilter. Static content BTW should be ideally served from your HTTP Connector (which must not be tomcat for sure). Apache mod_expires is a great caching implementation.

No comments: