This doesn't say word one about user supplied input. The only way a user input is getting into a template is by assigning the input to a var and adding that var to the template. It appears, by this information in the manual, that the $security flag only affects the template and use of Smarty template tags within the template. In any event, it seems that the most reasonable way in which someone may want to attempt to execute PHP code within the template would be to hijack the template, in which case why waste your time with the template? Why not just hijack the core code?The Smarty Manual wrote:$security
$security true/false, default is false. Security is good for situations when you have untrusted parties editing the templates (via ftp for example) and you want to reduce the risk of system security compromises through the template language. Turning on security enforces the following rules to the template language, unless specifially overridden with $security_settings:
- If $php_handling is set to SMARTY_PHP_ALLOW, this is implicitly changed to SMARTY_PHP_PASSTHRU
- PHP functions are not allowed in {if} statements, except those specified in the $security_settings
- templates can only be included from directories listed in the $secure_dir array
- local files can only be fetched from directories listed in the $secure_dir array using {fetch}
- {php}{/php} tags are not allowed
- PHP functions are not allowed as modifiers, except those specified in the $security_settings
Is this thread even talking about the right thing? I mean, seriously, unless a developer is taking user supplied data and echoing it to the template without some form of validation, it would seem that a template is not going to execute code unless the developer tells it to. If the developer is not sanitizing data, then that developer is opening themselves up to issues, not the app they are using. Or am I wrong?