Security Guidelines for Plugin Authors
Creating plugins for DokuWiki is very easy even for novice PHP programmers. To make sure your plugin does not compromise the security of the whole DokuWiki it is installed on, you should follow the guidelines outlined on this page.
this page is in a very raw state and should be extended with more indepth info, links and examples.
Common Issues
Here is a list of common security issues and how to avoid them.
Cross Site Scripting (XSS)
DokuWiki's plugin mechanism gives plugin developers a great deal of flexibility. In the case of syntax plugins in particular, the framework gives plugins the ability to write raw unprocessed output.
And therein lies the problem of Cross-site scripting.
Cross Site Scripting refers to an attack where malicious JavaScript code is introduced into a website. This can be used to redirect innocent users to malicious websites or to steal authentication cookies. This is the most common issue in DokuWiki plugins. To avoid it the simple answer is to always escape all output using the htmlspecialchars or rawurlencode; although there are cases where this is not straightforward.
Unless plugin developers are extremely careful, it is easy to write a plugin that works as intended, but also has unintended 'features' that may be of benefit to an attacker. Cross Site Scripting is an example of this.
| Q: | What types of DokuWiki installations are vulnerable? |
|---|---|
| A: | DokuWikis that use one of the vulnerable plugins and have “allow HTML” set to false or have “allow php” set to false. If you “allow PHP” then you implicitly “allow HTML” - if you “allow HTML” then an attacker has an easier way to do the sorts of attacks that are possible via vulnerable plugins. DokuWikis that allow users to register themselves and allow such users to edit any page are particularly vulnerable - if they have a vulnerable plugin. |
| Q: | Which plugins are at risk? |
|---|---|
| A: | Syntax plugins are most likely to have this sort of problem. But any plugin that writes output could be vulnerable. Of course, not all plugins are vulnerable. |
| Q: | How does the attack work? |
|---|---|
| A: | The attacker will try to include JavaScript in the use of a plugin, somehow. The details of the attack will vary depending on how the plugin works |
| Q: | And how might they do that? |
|---|---|
| A: | There are a couple of places where JavaScript can be included in HTML: 1. between <script> and </script> tags - eg <script>alert('XSS attack')</script> 2. as an intrinsic event. Many HTML tags can use intrinsic events, like say <div/>. This might look something like <div onmouseover=“alert('XSS attack')”></div>. There are a large number of intrinsic events. When the even occurs, the script will fire. onmouseover will fire when the user moves their pointing device (pointer) over the rendered version of the HTML tag (object, image, paragraph, whatever).3. As attribute value substitutions. This may look something like <div class=&{alert('XSS')};></div>4. as part of a URI. Quite a few plugins provide a way to include a remote object (eg Flash, RealPlayer, etc). This might look something like <object data=“javascript:alert('XSS attack')”/> |
| Q: | How do you stop the attacker? |
|---|---|
| A: | There are 3 main methods, which can be summarized as “limit inputs”, “validate inputs” and “encode outputs” - all three may be necessary: 1. Limit the characters that can be included in an attack. In the connectTo() function, specify a regular expression that is as restrictive as you can. For example, if an attacker can only use something like [a-zA-Z0-9] or \w then they are not likely to be able to do an interesting attack.2. Don't assume that the inputs that the plugin receives are benevolent. Any of the inputs could be malicious, so you should check them very carefully before using them. For example, if the plugin intends to give the user the ability to control the HTML attributes to give them extra flexibility then it may not be convenient to limit the inputs enough to prevent an attack. However, is it intended to give the user the ability to use intrinsic events? This in effect turns on the “allow HTML” flag. In this case we may want the user to be able to specify all the elements except the intrinsic events. It is usually safer to parse the users input to check that they are only using the permitted attributes, rather than to try to parse out the prohibited attributes. This is often referred to as “whitelisting” the permitted things in preference to “blacklisting” the prohibited ones. This is safer as there are foten ways to bypass the blacklists. 3. Finally, where you are outputting something that you received from outside the plugin (whether from the user or from an external site), you should ensure that the output is appropriately encoded for where it is going to be used. In the context of plugins, this may include URL encoding (eg converting spaces to + or %20) and/or HTML encoding (eg converting < to <). Note that in many cases, such encoding is necessary for a plugin to work correctly with a wide variety of valid inputs. |
need practical examples of whitelist/blacklist REGEXs, whitelisting attributes, when to use htmlspecialchars() and rawurlencode() and how to review a plugin.
Remote Code Inclusion
This attack allows an attacker to inject (PHP) code into your application. This may occur on including files, or using unsafe operations functions like eval or system.
Always filter any input that will be used to load files or that is passed as an argument to external commands.
Information leaks
This attack may lead to the exposure of files that should usually be protected by DokuWiki's ACL or it might expose files on the server (like /etc/passwd).
Always filter any input that will be used to load files or that is passed as an argument to external commands.
Always use DokuWiki's ACL check functions when accessing page data.
SQL injection
This attack is rarely relevant in DokuWiki because no database is used. However if your plugin accesses a database always escape all values before using them in SQL statements.
More info:
Reporting Security Issues
If you encounter an issue with a plugin please inform the author of the plugin via email.
Additionally a securityissue field with a short description of the problem should be added to the data on the page of the plugin. This will create a red warning box and will delist the plugin from the main plugin list.
Once the issue was fixed and a new release was made, this field should be removed again.
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
