I knew this would happen. I put up a post about spamming and XSS and wouldn’t ya know it, within minutes I was receiving emails that my blog here had some vulnerablities 
. Thank you to the people who let me know about it – it’s been fixed and I let the guys at Telligent know about it. The fix was pretty simple, and it involved opening up /search/default.aspx and setting this line of code:
graffitiContext["title"] = "Search Results for '" + HttpUtility.HtmlEncode(Request.QueryString["q"]) + "'";
The vulnerability didn’t seem to scary at the time – it involved searching my site using this term:
<script>alert("xss hahaha")</script>
This would pop a fun message on the search result page saying “you searched for “”" and boom, up would pop an annoying message. Seems sort of silly to me – who would want to spoof themselves? Why me of course…
[Puts on his Evil Black Hat]
Did I ever show you this really cool site I built? Take a look. You’ll have to login first.
[Removes Evil Hat]
Welly welly well – if you take a good look at that site you might notice something funny. Or maybe you logged in and I stole your login? If you didn’t notice, I appended a bunch of HTML to the Querystring, which included a nice login form that sends you off to some nice site where I can steal your login info and also fill your browser with evil .
The interesting thing about this is that I wrote about this before, in response to some lameness I added to the HTML Helpers. Before you fire up your keyboard, I very much know that encoding everything isn’t the answer – it’s an old post and… well what can I say.
But I also know that I just ran some searches on some random sites and 3 out 7 allowed the above injection. Did you notice my evil link above was an injection? If not have another look.
Html.Encode is Not a Silver Bullet
A few folks had a reaction to my bolded-up, superfly warning wherein I suggested that you can get around a lot of this by using Html.Encode. Steve Sheldon had this to say (snipped a bit for brevity):
I’m going to rant a bit. No offense, but this has bothered me for about 5 years now as I’ve seen one .net web app released after another which suffers from major XSS flaws.
Every solution Microsoft comes up with to deal with XSS involves Html.Encode(). It’s like they only tool they know how to use is a hammer. They came out with the cross site scripting library, which was nothing more than a new version of Html.Encode and as such shows a lack of understanding of the problem, as well as no serious desire to address it.
Quite often on the internet you want to allow users to write formatted entries. We have all kinds of neat little fancy editors like FCK, Cute Editor, Freetextbox, markitup, etc. etc. for this purpose. Sure you think, but I’ve limited the buttons at the top and I don’t let them edit html directly, my users can only do bold and italics and that’s it. But try to cut and paste from another browser and you’ll find that with many of these it pastes in just fine.
The problem of purifying your HTML, only allowing that HTML which you want isn’t an easy one to solve. You can’t just use a regex pattern to allow through a handful of tags, as there are several ways to fool that mechanism. You practically have to parse the text as HTML, and then rewrite it with only the allowed tags and attributes.
<snip>
The answer isn’t HTMLEncoding everything… Stop talking about Html.Encode as if it’s the only solution.
And I would agree with this – it’s good input and I think the message is that you can never be too cautious and “just trust the toolset”. It’s a reasonable thought, but stops short of offering some ideas (Steve followed up in later comments).
I see where Steve’s going, but my sentiment is that Html.Encode should be top of mind – not as a shield, but as a thought-pattern. Sure it won’t solve every problem, but if you’re at least thinking about it, you’re ahead. Which is the place to be. The only way to do this is (keep it in your head) is to keep writing about it – which I’m doing here.
Bertrand Le Roy pinged me today as well, and offered his thoughts that HTML Encode might not be enough in some cases. He has a great writeup here.
Get Educated
That’s my goal. ASP.NET MVC gets you a lot “closer to the metal” in terms of allowing you to customize what you do, etc. It also means that you can possibly get yourself in a little bit more trouble without Web Forms encoding your output inside server controls.
- For a good read on XSS attacks and what they are, have a look at this site.
- Read Damien Guards articles here and here.
Finally – we can help each other out by getting educated. We can also spoof the heck out of each other’s sites (like what happened to me last night). I hesitated a bit to share that first URL, but then thought that if I didn’t … well it’s only burying the problem. As Bertrand points out in his blog, User Input is Evil. Never trust them or the URL they road in on.
