Smarty

brettz9 · Smarty Regular Joined: 07 Jul 2006 Posts: 93

I was wondering...

If you enable secure mode, and allow any old Joe to have a means of editing the templates and then allow them to be able to share their templated page with others over that server, is there anything native to Smarty to prevent them from adding let's say script tags and nasty code?

DaKaLKa · Posted: Wed Jul 12, 2006 6:31 pm Post subject:

Take a look at http://smarty.php.net/manual/en/variable.php.handling.php
with it you can configure what happens to "php"-Tags in smarty. If you disable php-tags like with SMARTY_PHP_REMOVE then the user can't do something nasty except manipulation variables which were assigned to smarty.
You can also look at http://smarty.php.net/manual/en/variable.security.settings.php, there you can find more security-Settings for smarty and i think, this should be enough for security or do you have an security-breaking-example when using those functions?
Hope that helps you!

boots · Posted: Wed Jul 12, 2006 7:01 pm Post subject:

If you are talking about XSS attacks based on specially crafted HTML/CSS/JS techniques, then no, Smarty does nothing to prevent that. Security mode is meant to restrict access to server features -- but the idea is that even under secure mode, you must have a trusted relationship with your template users and/or your application must take its own steps to protect itself and its clients.

brettz9 · Smarty Regular Joined: 07 Jul 2006 Posts: 93

Thanks for the links DaKaLKa, though I should have been more clear. Yes, boots, that is what I was referring to.

It may be worth making the point you make in the security section of the documentation because use of the word "security" may give some coders a false sense of security.

For anybody coming across this thread looking for protection (XSS stands for cross-site scripting for those who don't know), the following I find quite helpful:

http://ha.ckers.org/xss.html
http://alistapart.com/articles/secureyourcode2 (esp. the solutions)
http://quickwired.com/kallahar/smallprojects/php_xss_filter_function.php (a function you can use to supposedly filter for all possible XSS--but without taking out harmless tags)

One other quite obvious issue is not to have or especially share any template code with templaters which displays any (normally hidden) links to unvalidated administrative functions (not a good idea anyways), assuming (falsely) that any admin flag verification will not be omitted (or reassigned if that is possible?) by the templater.

brettz9 · Smarty Regular Joined: 07 Jul 2006 Posts: 93

Since my interest is to allow CSS to users, I think your http://smarty.incutio.com/?page=SmartyDoc (the domain seems to be blocked in China for some reason--where I am now, though I got to it from a proxy) would be a big help potentially, allowing users to add (prefiltered) CSS to the template but having it processed into the head.

As far as I can tell though, your most comprehensive addition is singly missing the option to add style tags (unless to an imported url)? Is there some reason for this?

To my mind, the other head tags would have the least relevance to the average designer who'd work on the templates (though I see it could be convenient for admins not wanting to take the time to move the tags to the right place), whereas style would have a lot of relevance.

Mabye I'm missing something here...

thanks again,
Brett

boots · Posted: Thu Jul 13, 2006 3:54 am Post subject:

Hi.

Just to maybe clarify the XSS / security issue: XSS goes far beyond a pure template engine's purvey. Indeed, Smarty can be (and is) used to generate things other than webpages/client (browser) based code. Smarty's security mode is only intended to help prevent template users from screwing with your server by injecting straight PHP code into the template. As you rightly point out, stopping XSS requires a much more comprehensive approach to designing your application and dealing with client generated responses.

As for SmartyDoc and <style> tags targeted for they <head>, they are possible using the {doc_raw} block -- but that simply dumps anything in the {doc_raw} block into the <head>.