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.
- 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.
- 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.
- Implement The
Microsoft Anti-Cross Site Scripting Library
- Evaluate your content, and look for vulnerabilites.
Repeatedly.
Here are some useful links for those that want to know more.
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.
-
Implement an ANTI-CSRF HttpModule.
- Check the referrer header, and make sure it's your site making
the request. It can be found in
HttpContext.Request.UrlReferrer.
- 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.
- Limit the lifetime of authentication cookies.
- 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.
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.