X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/3a23cdde7d5621bc8d723d2226945ee5243115f3..e51089e11fc1093a253fc13ebfbd5d55912eba59:/doc/security.mdwn diff --git a/doc/security.mdwn b/doc/security.mdwn index b3af3db3e..0841abf49 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -6,7 +6,7 @@ security issues with this program than with cat(1). If, however, you let others edit pages in your wiki, then some possible security issues do need to be kept in mind. -[[toc levels=2]] +[[!toc levels=2]] ---- @@ -41,11 +41,12 @@ who's viewing the wiki, that can be a security problem. 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:` @@ -65,8 +66,7 @@ So it's best if only one person can ever directly write to those directories. ## 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 @@ -361,9 +361,9 @@ allow the security hole to be exploited. 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..) @@ -376,7 +376,7 @@ parties. 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 @@ -390,10 +390,20 @@ pre-emtively guard against that, current versions of ikiwiki store password 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.