http://qs1969.pair.com?node_id=680753


in reply to default_escape for Template::Toolkit?

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?
  • Comment on Re: default_escape for Template::Toolkit?

Replies are listed 'Best First'.
Re^2: default_escape for Template::Toolkit?
by Corion (Patriarch) on Apr 16, 2008 at 10:03 UTC

    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.

[reply]
[d/l]
[select]
Re^2: default_escape for Template::Toolkit?
by andreas1234567 (Vicar) on Apr 16, 2008 at 10:40 UTC
    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>

      [download]
      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.
    --
    When you earnestly believe you can compensate for a lack of skill by doubling your efforts, there's no end to what you can't do. [1]
[reply]
[d/l]
[select]
      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.

[reply]
        I agree that I have taken tinita's last question in Re: default_escape for Template::Toolkit? out of the original context.

        So what do the TT users do?
        I have no idea. Except consider how important such a feature is, and given it's important, switch to a templating system that supports it.
        --
        When you earnestly believe you can compensate for a lack of skill by doubling your efforts, there's no end to what you can't do. [1]
[reply]

In Section Seekers of Perl Wisdom