X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d7aecf6ddc19d1dac30ec5616134c2a7e7f4d573..f0f3a430f33a5fe3bbb2396f999dbbfd63d1bf19:/doc/security.mdwn?ds=sidebyside diff --git a/doc/security.mdwn b/doc/security.mdwn index 00b8e8824..73d98a3ae 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -6,14 +6,31 @@ 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. +---- + # Probable holes -## XSS holes in CGI output +_(The list of things to fix.)_ + +## svn commit logs + +Anyone with svn commit access can forge "web commit from foo" and make it +appear on [[RecentChanges]] like foo committed. One way to avoid this would +be to limit web commits to those done by a certian user. + +It's actually possible to force a whole series of svn commits to appear to +have come just before yours, by forging svn log output. This could be +guarded against by using svn log --xml. + +ikiwiki escapes any html in svn commit logs to prevent other mischief. + +---- + +# Potential gotchas -ikiwiki has not yet been audited to ensure that all cgi script output is -sanitised to prevent XSS attacks. +_(Things not to do.)_ -## image files etc attacks +## image file etc attacks If it enounters a file type it does not understand, ikiwiki just copies it into place. So if you let users add any kind of file they like, they can @@ -23,11 +40,11 @@ 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? -## web server attacks - -If your web server does any parsing of special sorts of files (for example, -server parsed html files), then if you let anyone else add files to the wiki, -they can try to use this to exploit your web server. +Currently only people with direct svn commit access can upload such files +(and if you wanted to you could block that with a svn pre-commit hook). +Wsers 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. ## multiple accessors of wiki directory @@ -43,30 +60,24 @@ Setup files are not safe to keep in subversion with the rest of the wiki. Just don't do it. [[ikiwiki.setup]] is *not* used as the setup file for this wiki, BTW. -## svn commit logs - -Anyone with svn commit access can forge "web commit from foo" and make it -appear on [[RecentChanges]] like foo committed. One way to avoid this would -be to limit web commits to those done by a certian user. - -It's actually possible to force a whole series of svn commits to appear to -have come just before yours, by forging svn log output. This could be -guarded against by using svn log --xml. - -ikiwiki escapes any html in svn commit logs to prevent other mischief. - ## page locking can be bypassed via direct svn commits -A [[lock]]ed page can only be edited on the web by an admin, but +A locked page can only be edited on the web by an admin, but anyone who is allowed to commit direct to svn can bypass this. This is by design, although a subversion pre-commit hook could be used to prevent editing of locked pages when using subversion, if you really need to. +## web server attacks + +If your web server does any parsing of special sorts of files (for example, +server parsed html files), then if you let anyone else add files to the wiki, +they can try to use this to exploit your web server. + ---- # Hopefully non-holes -(AKA, the assumptions that will be the root of most security holes...) +_(AKA, the assumptions that will be the root of most security holes...)_ ## exploting ikiwiki with bad content @@ -122,6 +133,17 @@ Login to the wiki involves sending a password in cleartext over the net. Cracking the password only allows editing the wiki as that user though. If you care, you can use https, I suppose. +## XSS holes in CGI output + +ikiwiki has not yet been audited to ensure that all cgi script input/output +is sanitised to prevent XSS attacks. For example, a user can't register +with a username containing html code (anymore). + +It's difficult to know for sure if all such avenues have really been +closed though. + +---- + # Fixed holes _(Unless otherwise noted, these were discovered and immediatey fixed by the @@ -193,4 +215,5 @@ pages from source with some other extension. ## XSS attacks in page content -ikiwiki supports [[HtmlSanitistion]], though it can be turned off. +ikiwiki supports protecting users from their own broken browsers via the +[[plugins/htmlscrubber]] plugin, which is enabled by default.