Input Validation and pattern matching in Template Toolkit

dipit has asked for the wisdom of the Perl Monks concerning the following question:

[% META
    title = 'Add xyz'
%]

[% attack = params.taskid_login %]
[% IF attack.search('<script>') || attack.search('</script>') || attac
+k.search('alert') %] [% attack = params.taskid_login | uri | html %]
[% ELSE %][% attack = params.taskid_login %]

<p>
    To add a new task ID member to <b>[% attack %]</b>, select one or 
+more users from the table below.
</p>

[% WRAPPER filter.tt filterTitle='Users filter' filterAction='add_task
+id_member' %]
    [% INCLUDE form_textfield.tt fieldName='filter_login' fieldValue=p
+arams.filter_login maxLength=100 %]
[% END %]

[%# Show global message is one or more members have been added... %]
[% IF NumberOfAddedRecords %]
    [% INCLUDE global_message.tt globalMessage=NumberOfAddedRecords _ 
+' users have been added.' %]
[% END %]

[% INCLUDE form_table.tt table=PossibleMembersTable %]
[download]

Hello All. Here i have created a varibale named "attack" and checking some validation over it. params.taskid_login is the input value to "attack" variable here. I want to detect <script> and alert tags here. I think my syntax is wrong so my page containing this template is not loading. Please help?

Comment on Input Validation and pattern matching in Template Toolkit Download Code

Replies are listed 'Best First'.
Re: Input Validation for Template Toolkit by Corion (Patriarch) on Jun 20, 2018 at 08:04 UTC
I think your approach of trying to filter out common known attacks will be a constant battle. Instead of attempting that, why don't you simply HTML-filter `attack`? Usernames should not contain (or be interpolated as) HTML. See for example homoglyph attacks like `tye&nbsbp;` which really, really looks like `tye` but with whitespace at the end.	[reply] [d/l] [select]
Re^2: Input Validation for Template Toolkit by dipit (Sexton) on Jun 20, 2018 at 09:40 UTC
Hello Corion! Thanks for your response. "attack" can contain values such as xxx@domain.com. In this case, every input is escaped or encoded but i need to encode only attacking ones like login=<script>...</script> etc. Thats why, i wanted to match the input with keywords and display the template accordingly.	[reply]
Re^3: Input Validation for Template Toolkit by Corion (Patriarch) on Jun 20, 2018 at 10:32 UTC
Sure, but then somebody could submit `login=<img src="http://evil.example.com/attack.js">`, and you would have to catch that too. And certainly, there are other attacks. I would recommend to escape all data that is user-supplied.	[reply] [d/l]
Re: Input Validation and pattern matching in Template Toolkit by hippo (Archbishop) on Jun 20, 2018 at 08:12 UTC
Have you considered doing this in your code before it even gets to the template? I'd suggest that if you wait until processing the output to detect bad input you are already too late. Validate whatever variable holds `attack` in your code. If it is good, continue. If it is bad, throw an error which includes the bad input and then in your template by all means sanitize that error. If you still want help debugging a template, please provide an SSCCE.	[reply] [d/l]
Re: Input Validation and pattern matching in Template Toolkit by nikosv (Deacon) on Jun 20, 2018 at 20:45 UTC
There's just too many Context/attack vectors for the the template to handle;there's the CSS context,the Javascript,the URL, the HTML, the JSON...The Perl counterpart,which I don't know what that would be, of an anti-XSS library such as Coverity's is recommended. For example,have a look at the various escapers offered by this library: https://coverity.github.io/coverity-security-library/com/coverity/security/Escape.html	[reply]
Re: Input Validation and pattern matching in Template Toolkit by Anonymous Monk on Jun 20, 2018 at 14:26 UTC
Definitely agree that an output template is the wrong place to try to detect problems with the input.	[reply]
Re: Input Validation and pattern matching in Template Toolkit by locked_user sundialsvc4 (Abbot) on Jun 20, 2018 at 21:09 UTC
In my view, a template is not the appropriate place to do this. Your application should be regarding its inputs, checking-for and defending against various attacks, and, if need be, setting variables in the template context which will cause appropriate HTML (etc.) to be inserted into the output by the template. The template should not be making decisions, or contain application logic.