Sprinkling XSS In Your Cookies

Creative Commons attribution licensed image courtesy scuba67

A recent web application vulnerability scan came back with an interesting result - automated cross site scripting tests were showing positive results in cookies.

"Wait! That can't be!" you say, knowing that cookies typically don't contain user visible content that their browser would interpret.

That was my reaction as well, so I went digging. Our environment uses ColdFusion for some application development, so most cookie handling is done via ColdFusion's built in cookie management tools. How was a cookie's content being rolled into the page?

Further digging showed that the error only showed on error pages, and consultation with the developer said that those pages were automatically generated by ColdFusion, and were not custom to his application. This is where having sharp developers comes in handy - the developer paused, looked more closely at the page and noted that he had requested a scan in our development environment - and that the ColdFusion error messages were disabled in our pre-prod and production environments.

Users would never see the XSS in any public facing environment - and, better, would only see the XSS in an error page, not in any valid user page. A false positive due to compensating controls and a very low risk profile even without them.

So, yes, you can have XSS in cookies, but it isn't as tasty as it might sound.

And the sharp developer? He and a co-worker went back through their ColdFusion framework and wrote back to me that the discovery had inspired them to armor their standard framework against similar issues in the future - they proactively updated it and will add that update to all of their standard framework applications.

HTML based portscanning - who needs Javascript?

Most of us are used to disabling scripting in our browsers, and a lost of security folks use the Firefox NoScript applet. Jeremiah Grossman's recent experiments with CSS based port scanning are interesting, and others are delving into the possibilities based on his original post. When you can pull browser histories without scripting, you have a whole new set of issues, and if this can be made to be cross domain, then we will need a whole new set of security techniques to protect our browsers. For now, be aware that browsing to a hostile site could mean that you are revealing more information than you may think that you are.

You say you need a web application security primer?

Heise Security posted their PHP focused Security Know-how for web application security. While it is focused on PHP security, much of the content is applicable in a general way to any web application programming environment. They're targeting a reasonably technical user, so this isn't suited to showing your management to make things easily understood for them, but this is a good article for your local PHP developer to read.

If you don't read anything else, make sure you read the last page - it covers the most important security settings in php.ini.

This catches the other side of Matt's post - build your applications to be secure, and lock them down first, then test them. As all three of us can attest, even good developers make mistakes, but having standards and being aware of security practices is a good start.