others edit pages in your wiki, then some possible security issues do need
to be kept in mind.
-[[toc levels=2]]
+[[!toc levels=2]]
----
Of course nobody else seems to worry about this in other wikis, so should we?
-Currently only people with direct commit access can upload such files
+People with direct commit access can upload such files
(and if you wanted to you could block that with a pre-commit hook).
-Users with only web commit access are limited to editing pages as ikiwiki
-doesn't support file uploads from browsers (yet), so they can't exploit
-this.
+
+The attachments plugin is not enabled by default. If you choose to
+enable it, you should make use of its powerful abilities to filter allowed
+types of attachments, and only let trusted users upload.
It is possible to embed an image in a page edited over the web, by using
`img src="data:image/png;"`. Ikiwiki's htmlscrubber only allows `data:`
## setup files
Setup files are not safe to keep in the same revision control repository
-with the rest of the wiki. Just don't do it. [[ikiwiki.setup]] is *not*
-used as the setup file for this wiki, BTW.
+with the rest of the wiki. Just don't do it.
## page locking can be bypassed via direct commits
The htmlscrubber did not block javascript in uris. This was fixed by adding
a whitelist of valid uri types, which does not include javascript.
-([[cve CVE-2008-0809]]) Some urls specifyable by the meta plugin could also
+([[!cve CVE-2008-0809]]) Some urls specifyable by the meta plugin could also
theoretically have been used to inject javascript; this was also blocked
-([[cve CVE-2008-0808]]).
+([[!cve CVE-2008-0808]]).
This hole was discovered on 10 February 2008 and fixed the same day
with the release of ikiwiki 2.31.1. (And a few subsequent versions..)
Cross Site Request Forging could be used to constuct a link that would
change a logged-in user's password or other preferences if they clicked on
the link. It could also be used to construct a link that would cause a wiki
-page to be modified by a logged-in user. ([[cve CVE-2008-0165]])
+page to be modified by a logged-in user. ([[!cve CVE-2008-0165]])
These holes were discovered on 10 April 2008 and fixed the same day with
the release of ikiwiki 2.42. A fix was also backported to Debian etch, as
hashes (using Eksblowfish).
If you use the [[plugins/passwordauth]] plugin, I recommend upgrading to
-ikiwiki 2.48, installing the [[Authen::Passphrase]] perl module, and running
+ikiwiki 2.48, installing the [[!cpan Authen::Passphrase]] perl module, and running
`ikiwiki-transition hashpassword` to replace all existing cleartext passwords
with strong blowfish hashes.
You might also consider changing to [[plugins/openid]], which does not
require ikiwiki deal with passwords at all, and does not involve users sending
passwords in cleartext over the net to log in, either.
+
+## Empty password security hole
+
+This hole allowed ikiwiki to accept logins using empty passwords, to openid
+accounts that didn't use a password. It was introduced in version 1.34, and
+fixed in version 2.48. The [bug](http://bugs.debian.org/483770) was
+discovered on 30 May 2008 and fixed the same day. ([[!cve CVE-2008-0169]])
+
+I recommend upgrading to 2.48 immediatly if your wiki allows both password
+and openid logins.
+
+## Malformed UTF-8 DOS
+
+Feeding ikiwiki page sources containing certian forms of malformed UTF-8
+can cause it to crash. This can potentially be used for a denial of service
+attack.
+
+intrigeri discovered this problem on 12 Nov 2008 and a patch put in place
+later that day, in version 2.70. The fix was backported to testing as version
+2.53.3, and to stable as version 1.33.7.