My SessionSafe-paper is online for quite a while now, but I never found the time to write about it. The paper describes three methods that, if used in combination, allow to protect web applications against session hijacking even in situations when a XSS attack already successfully injected malicious JavaScript code into the application.

           

XSS problems are not always caused by flaws in the web application itself. Instead they may arise due to external factors, like the expect header problem, vulnerable browser extensions (e.g., the Adobe PDF UXSS), or unwise usage of eval() in Greasemonkey-scripts. For this reason such a second line of defence is useful even if an web application is well audited and believed to be secure. The paper was presented at ESORICS 2006 and published in the conference's proceedings.

Abstract (fat free version):

[...] In this paper we classify currently known attack methods to enable the development of countermeasures against [session hijacking]. By close examination of the resulting attack classes, we identify the web application’s characteristics which are responsible for enabling the single attack methods: The availability of session tokens via JavaScript, the pre-knowledge of the application’s URLs and the implicit trust relationship between webpages of same origin. Building on this work we introduce three novel server side techniques to prevent session hijacking attacks. Each proposed countermeasure removes one of the identified prerequisites of the attack classes. SessionSafe, a combination of the proposed methods, protects the web application by removing the fundamental requirements of session hijacking attacks, thus disabling the attacks reliably.

In hindsight I tend to consider the JavaScript based Randomizer object to be the weakest part of the paper as I am not fully convinced that some JavaScript implementation might not provide a non-standard mechanism to either obtain the encapsulated list of nonces or hijack the document.location property. E.g., one of the paper's reviewers warned about an attacker that tries to overwrite the setter-function of the document.location property. While Kuzza55 showed how to counter such an attempt, the whole business still leaves an uneasy feeling. However even the combination of Deferred Loading and Subdomain Switching still provides decent enough protection, as I have discussed in my ph-neutral 0x7d6 presentation. Also implementing the Randomizer object either in Flash or as a Java applet should get rid of my JavaScript worries.

Misc. remarks and updates:

• I have to thank Andre Luerssen. Without him I would not have considered the background-XSS-propagation attack vector.
• Christian Weitendorf implemented the paper's techniques for J2EE as part of his Master's thesis. The thesis is still in review. We are thinking about releasing the code afterwards. Stay tuned.
• Furthermore, after reading the paper, Collin Jackson pointed me to a small but significant error in the paper's example code: Instead of

  nonce = validNonces[path];

  in Listing 1.1 it should better be

  var nonce = validNonces[path];.

  Otherwise the nonce would be stored as a property of the global window object.

A closing remark: The research that did lead to this paper was probably the most fun I yet had in academia.