RIP Posted February 12, 2010 Report Posted February 12, 2010 If you spend enough time looking for Cross-Site Scripting (XSS) vulnerabilities, you are bound to come across a cookie-based version eventually -- where the script injection is located in the Cookie header. The problem is there’s no good way (in a modern browser) to force a victims browser to send an HTTP request with a modified Cookie value (to include HTML/JS). While the website or Web application is still technically vulnerable to XSS this is usually considered unimplementable since no PoC code can be created and the risk/threat is therefore lowered.I was having this conversation with Rob Tate, a member of WhiteHat’s Engineering team, who enlightened to something I hadn’t previously considered. Cookie-based XSS can be made very useful after all!Consider an online bank with an XSS through a username Cookie parameter. After successful login the resulting page would read something like, "Hello ."Cookie: username=Setting the Cookie will most likely require another (non-persistent) XSS vulnerability, which as we know is extremely common. By combining these two vulnerabilities, an unimplementable and non-persistent XSS, you could create a persistent XSS scenario.What the attacker could do is use the non-persistent XSS to inject a data mining JavaScript function into the browser’s Cookie username parameter via document.cookie. Afterwards every time the victim logs-in the JavaScript will execute in the DOM. Now you have an a persistent XSS attack sticking with the browser over multiple sessions.Update: Related work by Mike Bailey, Cross-subdomain Cookie Attacks: Screen1, Screen2Source: Jeremiah Grossman's Blog Quote
