Securing the templates

From Invenzzia wiki

In this article, we are going to show, how to secure your templates from unauthorized access to your script structures. This is very important, if you are going to allow the users of your website to modify the templates in order to customize the look of some services (i.e. a blog). However, may programmers will find them useful in an everyday practice, because the techniques described here allow them to avoid errors and make the templates more clean.

Contents 1 General security issues 2 No PHP in templates 3 Using PHP functions in templates 4 Using objects in templates 5 Error reporting 6 Conclusion

General security issues

OPT by default does not provide any access to its internal configuration from templates. The templates are executed within the Opt_View object context, whereas the configuration is stored in Opt_Class. The template variables are safely kept in the internal arrays, so no template variable matches any physical PHP variable, but an array field.

No PHP in templates

The first security rule is to throw away any PHP code from templates. Everything that can be achieved with PHP, is available also with pure OPT syntax. By default, OPT does not provide any instruction that allows to enclose PHP code snippets within OPT templates, but it is possible to write such instruction. By allowing the users to write in PHP, you give them access to all your PHP script structure, and if they know, what framework and libraries you are using, you may get into very big trouble. For example, the attacker may write a template that accesses to the session object and modifies the logged user identifier to the admin user one.

Using PHP functions in templates

OPT allows you to use PHP functions in templates. The available functions must be registered in OPT before they are used:

$tpl->register(Opt_Class::PHP_FUNCTION, 'templateName', 'phpName');

If OPT encounters an unknown function call, it generates an exception. Moreover, it allows you to give the registered function a different name that it has in the PHP script. In this way, you can even register static methods as functions or refer to the items in a namespace, hiding the internal script structure from the end-user. In fact, most of default OPT functions are static methods of Opt_Function class.

Do not register any dangerous functions in the templates. If you register a function from your framework, make sure that it does not introduce any extra functionality that may be used to attack your website.

Using objects in templates

OPT provides also the support for the PHP object oriented programming. You can access the object methods and fields, and (in a limited way) cloning and creating new objects. However, all this object-oriented stuff is considered as dangerous. Although OPT requires you to register all the classes that can be used to create new objects in the templates, there is no way to check during the compilation the existing objects that have been passed to the compiler.

The objects that can be affected with OOP syntax in templates are:

1. Opt_View objects - you can pass entire views to another views in order to be executed in some places. They are stored as template variables then.
2. Objective sections - in some places, the sections can iterate through objects. As the section data are stored in the template variables, the template designer can call their methods then.
3. Components and blocks - implemented as PHP objects.
4. Any other objects that you assign directly to the views.

In the OPT configuration, there are two options that allow you to deal with OOP:

1. advancedOOP - if set to true, the template designers can create new objects of registered classes and clone existing objects.
2. basicOOP - if set to false, the OOP features in the templates are disabled.

If the security if a critical requirement, set both of them to false and redesign your script so that the templates do not have to access directly to your objects. For example, you can create some wrapper functions that read the correct object from the script registry and perform some "safe" operations on them in a controlled environment. Another way is to extend Opt_View, add the new fields and register new functions that refer to them:

class MyViewWrapper extends Opt_View
{
   public $object1;
   public $object2;
   public $object3;
} // end MyViewWrapper;
 
$tpl->register(Opt_Class::PHP_FUNCTION, 'safeOperation', '$this->object1->safeOperation');
$tpl->register(Opt_Class::PHP_FUNCTION, 'anotherSafeOperation', '$this->object2->anotherSafeOperation');

Now the template designers even do not know that the functions are in fact the method calls.

Error reporting

All the OPT errors are reported with PHP exceptions. This allows you to customize the error handling depending on your needs. If the security is a critical issue, your exception handler must not show any dangerous information to the end user, such as paths or stack traces. Note that if the debug mode is disabled, the default exception handler, hides that information, too.

Conclusion

Remember that the weakest part of the security are humans. The technology can give you the tools, but you have to use them properly. The declarative style offered by OPT is one of them, but at the same time you have to disable the access to some other features. Keep your software up to date, especially when it comes to the security issues.