Cross Site Scripting (XSS)

I was just reading an article about a new kind of cross-site scripting attack called "Session Fixation Vulnerability" in which a malicious user is able to get access to the sessionid (jsessionid or cfid/cftoken as examples) of a user on your site.

This is something I talked about in Javascript and the Art of Motorcycle Maintenance, in which I contended that Adobe can and imo should, but probably won't do anything more to improve the security of ColdFusion from these XSS attacks in the upcoming ColdFusion 9 release.

Now I've never considered myself a "hacker" (at least not in the modern sense), but perhaps the only reason it never occurred to me to do this before is because I wasn't really all that terribly interested in breaking anyone else's sites or applications. I'm not a generally malicious person so those sorts of things don't really cross my mind. It's only upon reading this article that I realized how easily I myself, not being malicious, could probably hack some 80% to 90% of ColdFusion sites in the wild today. How? A relatively simple XSS attack against something potentially as innocuous as a blog comment entry.

Maybe not most blogs -- maybe most blogs don't really use JavaScript to display comments... but I'm not limited to blogs of course, I could for example write a script of my own that sits around and randomly spiders different ColdFusion powered sites, looking for form fields where I could enter my XSS attack which easily fires off an AJAX request to my own server and hands off to me all the cookie information that's available to JavaScript, because my attack was able to execute within the browser's "safe" security sandbox. The browser doesn't know that script tag is malicious. As far as the browser knows, the site owner created that script tag, so it's the browser's job to do what it says and fire off that Ajax request to my server. The user wouldn't know either. All the user would see is another JavaScript error, which they're probably pretty accustomed to seeing (even if they don't understand them).

I considered the possibility of posting code in this article, showing exactly how that XSS attack would be performed... and then I reconsidered. If you're really interested in protecting yourself, read my previous article and if you're smart, you should be able to see just what I'm talking about...

This merely underscores my point in the previous article. Most of the time the web is a decent place -- because people are mostly decent. That one bad apple however can be a real bitch sometimes, and if they're getting your sessionid from a web application, who knows what sensitive information they might be able to glean from that. As a matter of fact, case-in-point I'd be willing to bet that there are hundreds of places in my last employer's website where I could execute this very XSS attack I'm talking about -- and the only thing stopping me is that I'm not a malicious person (and don't have anything against the guys I worked with there, in spite of the fact that I was fired again).

The reason why most applications have this vulnerability in the first place is actually because most people are like me, good folks with good intentions, not looking to cause any trouble, just getting through their day. And so particularly with ColdFusion because it is such an easy language to learn, most of the people working with it (many of whom don't have programming as their first interest), aren't compelled to spend much (if any) time reading articles like this one I'm reading now that talk about this vulnerability. They are by and large blissfully unaware of the problem. And not even the most devout campaign of developer education in the world is going to reach them all. Hell, most of the ColdFusion programmers I've worked with directly over the years refuse to use CFQUERYPARAM because "it's too much work!" Try convincing those same guys they need to update every JSStringFormat() function in their application to protect themselves against XSS attacks, when they're already refusing to protect themselves against SQL injection because it's tedious.

As long as the system (JSStringFormat) stays in its current state, the best we can hope for is to reach maybe 50% of the developers out there (and that's a pretty liberal estimate). And even then, they're liable not to find or fix every instance of the vulnerability, even in their own applications. What they're liable to do is evaluate each on a case by case basis and fix some and leave the others. For example they might see a number being output and think "oh that's a number, it's safe" -- which it absolutely isn't, but it doesn't matter because we're in the habit of thinking of numbers as being safe. (And not everyone will -- or wants to -- use the server's ScriptProtect feature. I don't.)

So here we have a ubiquitous security risk that happens in just about every ColdFusion application in the world. Certainly not all, but most of them. And yet the ColdFusion community at large, especially one of the most well-known and vocal experts Dave Watts of Figleaf Software, say that not only is it not a problem, according to them having this security threat is better than the the alternative of the Adobe ColdFusion team modifying the JSStringFormat() function just very slightly to make it behave the same way as the new SerializeJSON() function, a change that very few of us would even notice. Their argument for the security risk being better than the alternative ultimately boils down to being concerned that a change might (although it probably won't) cause new programming challenges which they can't articulate because they don't know what those challenges might be. In other words, a phantom menace.

Adobe probably should make that change... they also probably will not make that change, because of the widespread vocal response from people like Dave Watts and others who agree with him in his claim that the status quo is the best solution. I thought this was important before I read this article, when I thought all that was at stake was a "fender bender" (to stay with the metaphor) -- but now I realize it's much more serious than that. Now it's, "oh and by the way, 20% of the cars on the road will burst into flames like the Ford Pinto, the barbecue that seats four."