X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d7aecf6ddc19d1dac30ec5616134c2a7e7f4d573..a986679a1cb446c3123be4a0592a1ddf05db8e77:/doc/security.mdwn?ds=inline diff --git a/doc/security.mdwn b/doc/security.mdwn index 00b8e8824..53000c08e 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.)_ -ikiwiki has not yet been audited to ensure that all cgi script output is -sanitised to prevent XSS attacks. +## svn commit logs -## image files etc attacks +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 + +_(Things not to do.)_ + +## 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,9 +133,20 @@ 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 +_(Unless otherwise noted, these were discovered and immediately fixed by the ikiwiki developers.)_ ## destination directory file replacement @@ -162,12 +184,18 @@ their own can race it. Similarly, a svn commit of a symlink could be made, ikiwiki ignores it because of the above, but the symlink is still there, and then you edit the -page from the web, which follows the symlink when reading the page, and -again when saving the changed page. +page from the web, which follows the symlink when reading the page +(exposing the content), and again when saving the changed page (changing +the content). + +This was fixed for page saving by making ikiwiki refuse to write to files +that are symlinks, or that are in subdirectories that are symlinks, +combined with the above locking. -This was fixed by making ikiwiki refuse to read or write to files that are -symlinks, or that are in subdirectories that are symlinks, combined with -the above locking. +For page editing, it's fixed by ikiwiki checking to make sure that it +already has found a page by scanning the tree, before loading it for +editing, which as described above, also is done in a way that avoids +symlink attacks. ## underlaydir override attacks @@ -176,21 +204,26 @@ pages to all wikis w/o needing to copy them into the wiki. Since ikiwiki internally stores only the base filename from the underlaydir or srcdir, and searches for a file in either directory when reading a page source, there is the potential for ikiwiki's scanner to reject a file from the -srcdir for some reason (such as it being a symlink), find a valid copy of -the file in the underlaydir, and then when loading the file, mistekenly -load the bad file from the srcdir. +srcdir for some reason (such as it being contained in a directory that is +symlinked in), find a valid copy of the file in the underlaydir, and then +when loading the file, mistakenly load the bad file from the srcdir. + +This attack is avoided by making ikiwiki refuse to add any files from the +underlaydir if a file also exists in the srcdir with the same name. -This attack is avoided by making ikiwiki scan the srcdir first, and refuse -to add any files from the underlaydir if a file also exists in the srcdir -with the same name. **But**, note that this assumes that any given page can -be produced from a file with only one name (`page.mdwn` => `page.html`). +## multiple page source issues -If it's possible for files with different names to produce a given page, it -would still be possible to use this attack to confuse ikiwiki into -rendering the wrong thing. This is not currently possible, but must be kept -in mind in the future when for example adding support for generating html -pages from source with some other extension. +Note that I previously worried that underlay override attacks could also be +accomplished if ikiwiki were extended to support other page markup +languages besides markdown. However, a closer look indicates that this is +not a problem: ikiwiki does preserve the file extension when storing the +source filename of a page, so a file with another extension that renders to +the same page name can't bypass the check. Ie, ikiwiki won't skip foo.rst +in the srcdir, find foo.mdwn in the underlay, decide to render page foo and +then read the bad foo.mdwn. Instead it will remember the .rst extension and +only render a file with that 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.