X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/698aeb20168b7e22a2ce3618a28fdee32ed4a417..30afedcfe2799bb6cc4bf329bd273ad9d8dd6da3:/doc/security.mdwn diff --git a/doc/security.mdwn b/doc/security.mdwn index a8f8f20ac..53000c08e 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -6,34 +6,45 @@ 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 -## html attacks +_(The list of things to fix.)_ -ikiwiki does not attempt to do any santization of the html on the wiki. -[[MarkDown]] allows embedding of arbitrary html into a markdown document. If -you let anyone else edit files on the wiki, then anyone can have fun exploiting -the web browser bug of the day. This type of attack is typically referred -to as an XSS attack ([google](http://www.google.com/search?q=xss+attack)). +## svn commit logs -TODO: determine whether to try to deal with XSS attacks or whether this is -just something people using ikiwiki will need to keep in mind. +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. -## image files etc attacks +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 -upload images, movies, windows executables, css files, etc. If these files -exploit security holes in the browser of someone who's viewing the wiki, -that can be a security problem. +upload images, movies, windows executables, css files, etc (though not html +files). If these files exploit security holes in the browser of someone +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 @@ -49,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 @@ -128,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 @@ -168,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 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. +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. + +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 @@ -182,17 +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. - -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`). - -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. +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. + +## multiple page source issues + +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 protecting users from their own broken browsers via the +[[plugins/htmlscrubber]] plugin, which is enabled by default.