Notes from the EPiServer Meetup in Stockholm.

Yesterday I was at the EPiServer Meetup, which was kindly hosted by KnowIT. It started off with a VERY interesting talk on XSS/CSRF. After a short break with thai food, there was a presentation on developing EPiServer templates that validate and are SEO friendly.

I'm not going to cover the validation/SEO friendlyness here, not because I believe that what they said was bullcrap, but rather because I believe that their approach doesn't give the client the freedom of choice I think goes hand-in-hand with using a large scale CMS like EPiServer. When a client uses EPiServer, and tires of their development partner, they should be able to switch over-night. Furthermore, development time is, and this is only my personal oppinion, increased, since developers have to build their own post-back mechanisms. But enough on that, what they said mostly made sense :).

XSS, or Cross-Site-Scripting, is when someone injects HTML or a script, into a site. There are two different kinds, Non-persistent/Reflected or Persisted/Stored.

The Reflected approach is when someone exploits a XSS vulnerability, for example, modifies a querystring parameter so that html and/or javascript is rendered directly onto the page. They then spread a link to their modified URL, and anyone logging on there might be subjected to some form of fraud or some other malignant attempt at their data.

The Stored approach is when someone submits, for instance to a forum or blog comment, html and/or javascript that is then stored on the page for other visitors to be subjected to. Like as if a blog comment here would contain html and javascript that would render a login form on every page, but when fileld out, would send that data to a third party. In short, it would suck. Big time.

Now, how to protect yourself?

In short: Don't allow HTML being posted to your forms. Oh, and check for scripts too.

OK. But that won't always do. I know, so here's a few more lengthy pointers.

1. Enable validateRequest in web.config in system.web/pages - if this isn't an option for you, i.e. EPiServer's editor won't work, consider using it in combination with your <location> segments, only disabling it where absolutely needed.
2. Clean your output. HTML-Encode any input sent from the user, or use RegEx to clean those tags/attributes that can cause harm. For me anyway, RegEx is awesome, but I can NEVER seem to learn them.
3. Implement The Microsoft Anti-Cross Site Scripting Library
4. Evaluate your content, and look for vulnerabilites. Repeatedly.

Here are some useful links for those that want to know more.

• XSS Prevention Cheat Sheet
• Security Compass Exploit-Me Firefox Add-On
• XSS on Wikipedia
• The Microsoft Anti-Cross Site Scripting Library

So, what then is that other abbreviation, CSRF? CSRF, or Cross-Site Request Forgery, is when a malignant website uses valid data from your browser, like hi-jacking a validation cookie, and sends a request with that valid data, in your name. This was a wake-up call for me.

A possible scenario is, when you're out in your sunday best, couch-surfing. You check your mail at Gmail in one tab, and doing some "grown-up's surfing" in another tab. Your browser then has an authorization cookie for Gmail, certifying that you're logged in, and everything is A-OK. The grown-up-site you're watching has some malicious code on it, that tries to send data to Gmail behind your back, and since your browser is authorized, Gmail accepts that incoming request, forged as it may be.

Working around this can be a hassle, but it isn't impossible, here are a few tips.

1. Implement an ANTI-CSRF HttpModule.
2. Check the referrer header, and make sure it's your site making the request. It can be found in HttpContext.Request.UrlReferrer.
3. Make sure that any crossdomain.xml doesn't allow everything. This is a Flash thing, so if you don't have any Flash on your site, you don't need to bother.
4. Limit the lifetime of authentication cookies.
5. If you're using ASP.NET MVC, use the Html.AntiForgeryToken() helper in conjuction with the [ValidateAntiForgeryToken] attribute on your post method.

Here are some useful links for those that want to know more.

• .NET CSRF Guard
• CSRF on Wikipedia

I'll be testing Umbraco in general, and the Blog4Umbraco package specifically, for XSS vulnerabilites in the next few days, I'll keep you posted.

Finally, thanks to Sergio Molero at Concrete IT for an excellent presentation.