How to Be a Smart Wiki Editor
by
, November 3, 2015 at 10:42 AM (82537 Views)
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:
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.Code:<div [template]Public Template[/template] class="myDivStyles"></div>
User-created Tag Vulnerability
Here's another example of bad "Admin Page" code:
This is a simplified example, but let's say the editor of "Admin Page" expects the following content for "Public Template":Code:<[template]Public Template|el=div[/template]> [template]Public Div Content Template[/template] </[template]Public Template|el=div[/template]>
And the following content for "Public Div Content Template":Code:{{{el}}} class="myDivStyles"
Since both of these templates are public, they can be edited like so. For "Public Template":Code:Text that goes in my div.
For "Public Div Content Template":Code:script
Code:alert('I just exploited a vulnerability!');User-created Javascript Vulnerability
Here's an example of bad "Admin Page" code:
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:<script> var myScriptVar = 'Div Title'; var myScriptVar2 = '[template]Public Template[/template]'; var myDiv = document.createElement('div'); myDiv.setAttribute('title', myScriptVar); myDiv.innerHTML = myScriptVar2; </script>
While the example above uses a SCRIPT tag, you should also be careful with IFRAME, OBJECT, APPLET, and other such tags.Code:'; alert('I just exploited a vulnerability!'); '
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.