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
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.