pegasus

Templates are a very powerful tool for building pages out of multiple parts; however, interchanging parts that have different access permissions, without thinking it through, can have serious implications for the security of your final wiki page.

VaultWiki does its best to clean user inputs in template arguments and to sandbox the permissions in nested templates. However, wiki editors should be aware that careless use of templates in privileged environments can still allow the creation of new security vulnerabilities by the editor.

For example, we have a template "Public Template" that any user can edit, but it does not allow HTML.
We have a page "Admin Page" that only admins can edit, but it does allow HTML.

If the editor of "Admin Page" is careless when implementing "Public Template", it is possible to run the content of "Public Template" in a privileged state even though it has been sandboxed.

Why this is the Editor's Responsibility

For other security reasons and for permitting other legitimate usages, the sandbox for "Public Template" cannot consider the outside context in which it used. Thus, VaultWiki cannot be made to detect and pre-empt a bad usage of the following types. So it becomes the responsibility of the editor of "Admin Page" not to actively create the following vulnerabilities.

User-created Attribute Vulnerability

Here's an example of bad "Admin Page" code:

Code:

<div [template]Public Template[/template] class="myDivStyles"></div>

In this case, an editor of "Public Template" might be able to add onclick Javascript events to your div, without writing any real HTML code themselves.

User-created Tag Vulnerability

Here's another example of bad "Admin Page" code:

Code:

<[template]Public Template|el=div[/template]>
[template]Public Div Content Template[/template]
</[template]Public Template|el=div[/template]>

This is a simplified example, but let's say the editor of "Admin Page" expects the following content for "Public Template":

Code:

{{{el}}} class="myDivStyles"

And the following content for "Public Div Content Template":

Code:

Text that goes in my div.

Since both of these templates are public, they can be edited like so. For "Public Template":

Code:

script

For "Public Div Content Template":

Code:

alert('I just exploited a vulnerability!');

User-created Javascript Vulnerability

Here's an example of bad "Admin Page" code:

Code:

<script>
var myScriptVar = 'Div Title';
var myScriptVar2 = '[template]Public Template[/template]';

var myDiv = document.createElement('div');
myDiv.setAttribute('title', myScriptVar);
myDiv.innerHTML = myScriptVar2;
</script>

It's great that the editor wants to dynamically create a new DIV and wants to fill it with the content of Public Template, but he has just allowed editors of "Public Template" to access a Javascript scope on this page. Example "Public Template":

Code:

'; alert('I just exploited a vulnerability!'); '

While the example above uses a SCRIPT tag, you should also be careful with IFRAME, OBJECT, APPLET, and other such tags.

Conclusion

In conclusion, if you have HTML privileges, be responsible, and do not place templates in foolish places. These rules apply not only to the outside page, but also if you are nesting multiple templates.