default_escape for Template::Toolkit?

[moritz]

I quite like HTML::Template's and HTML::Template::Compiled's default_escape options.

They take care that any variable in the template is escaped unless specified otherwise. That's nice if you forget to escape your variables (and still don't like XSS).

Is there such an option for Template-Toolkit?

I'm not very familiar with Template toolkit, so I guess it would be some kind of a plugin, and you could write [% variable | unhtml %] or some such to prevent encoding.

(Actually tinita asked that on the 10. German Perl Workshop during her talk on web security and got no answer).

[pc88mxer]

I created a patch for this about six months ago and discussed it on the TT mailing list. It allows you to write:

[% GETFILTER '::html_escape' %]
  ... all gets are now filtered through the function ::html_escape ...
  Hello, [% name %]
  [% GETFILTER '' %]
  ... turn off filtering ...
  [% END %]
  ... previous filtering resumes ...
[% END %]

It maintains a stack of filters, and there's no reason why you couldn't pre-initialize it with a default filter.

At the time it seemed to generate some interest, although not enough for me to do much more with it. Perhaps by now some form of it has made it's way into the latest release - I haven't checked.

[moritz]

Perhaps by now some form of it has made it's way into the latest release - I haven't checked.

I grepped the latest release for 'getfilter', no results. So it doesn't seem to be implemented, or at least not with that syntax. I didn't find anything in the Changes file either.

Thanks for your response anyway.

[pc88mxer]

It's trivial to implement. Check out the TT mailing list archives for Nov 2007.

I'm not sure why there wasn't more interest in it. I think this capability would be a great boon for creating robust HTML using TT.

[tinita]

wow, interesting, that so few seem interested.
default_escape is IMHO the solution against XSS. since i know it i don't want to miss it. it's so comfortable to create templates while knowing that you can't forget to html-escape. at the same time you often stumble across embarrassing XSS issues on other pages, and you can be sure that this very probably won't happen to you.
so why seem most of the TT users here not to be interested? what do you do to prevent XSS reliably?

[Corion]

Personally, I don't accept input from (untrusted) users. But that approach certainly isn't feasible if you want to create a website that allows users to enter data. When I output stuff, I'd really like a way to specify the escaping in the templates like the Free Nodelet allows, by appending &, % etc..

Something that I'm thinking about from time to time would be a more typed version of Taint mode where you can "color" strings according to their provenience (user input, db input, etc.). You would also need to be able to color the filehandles and other output/system methods accordingly, and a HTML-colored output filehandle would either die fatally when it encounters input in the wrong color or convert the input by html-escaping it.

To make this idea feasible at all, concatenation with constant strings would need to bleed the color into the result and some translation rules would need to exist. I'm not sure where Perl has hooks for that. I believe Taint mode is implemented through magic, so maybe the colors could be implemented through the same magic, except that a colored string is both tainted ("lead paint") but in a special color.

[andreas1234567]

what do you do to prevent XSS reliably?

• Sanitize user input using a accept known good only approach (link to owasp.com). I find Embperl::Form::Validate very useful, although there are many others as well.
• Flip HTML::Mason's default_escape_flags so that if someone enters:

  <script>load_malicious_javascript_from_hacker_site;</script>
  

  into a text field in your blog, it is displayed verbatim rather than turned into executable code.
The OWASP Guide to Building Secure Web Applications version 3 draft is out. Is is certainly an interesting read for those concerned about web application security.

[moritz]

I think the question was directed at TT users. At least mine was.

Flip HTML::Mason's default_escape_flags

That's the point. TT doesn't seem to have such a flag (or at least nobody knows about it). HTML::Template and HTML::Mason (documented in HTML::Mason::Compiler have some default escaping mechanism. So what do the TT users do?

I can't believe they never forget to escape something and therefore don't need a better solution.

[Arunbear]

Probably not what you want, but you can apply escaping to a template with

[% INCLUDE mytemplate | html %]

[moritz]

Quite the reverse: I'd like a default escaping mechanism to not escape includes, results of macros and the like, but interpolated variables.

[Rhandom]

At this point, this node is rather historic (look at this post date vs that of the other posts in this node), but I think as this node is a good historic point of question, that it is worth referencing a recent node that answers the questions. How to test all TT2 tags are escaped.