Fixing XSS in Catalyst with a really big hammer

A few friends of mine are currently working on a community website of sorts, which means they'll have tons of user-provided content and interaction. This also means there are possible XSS problems all over the place.

So they stated dutifully adding `| html` all over the place. But that's stupid. It's playing whackamole because this sort of issue will keep cropping up again and again, often only to be noticed after it's abused.

However now it's really easy to fix this by having the html filter applied to all tokens in a template:

To break this down:

This is your typical TT view for your Catalyst app. It uses on Catalyst::View::TT as base class, but defines v0.37 as a minimum. This version (released today) supports the CLASS parameter, which allows you to set the class to be used to create the TT object.

That makes it possible to use Template::AutoFilter instead of pure Template. This is great because T::AF automatically applies a filter (html by default) to any unfiltered template tokens. (Excluding a bunch of control tokens that either pull in other templates or have no output.)

What this means is that with this little code snippet above you have a view that automatically converts any user input so all html elements are rendered as entities and displayed plainly to the user instead of being interpreted by the browser. Of course, you'll want some parts to not be filtered, and that's easy to do, since you can either apply some other filter, or just add `| none` to skip the auto-filtering.

This means there's no way for an attacker to inject html or javascript into the template-driven parts of your website unless you explicitly enable it.


I think this would make a great addition to the Catalyst Tutorial.

Leave a comment

About Mithaldu

user-pic Not writing much, but often found pawing at CPAN with other #perl-cats