X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/1a382e051f268576b77fe1653512e0b2d12488b5..30afedcfe2799bb6cc4bf329bd273ad9d8dd6da3:/doc/security.mdwn diff --git a/doc/security.mdwn b/doc/security.mdwn index 75e91a8a2..53000c08e 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -10,20 +10,7 @@ to be kept in mind. # Probable holes -## 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. - -## 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 (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? +_(The list of things to fix.)_ ## svn commit logs @@ -43,6 +30,22 @@ ikiwiki escapes any html in svn commit logs to prevent other mischief. _(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 (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? + +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 If multiple people can write to the source directory ikiwiki is using, or @@ -59,7 +62,7 @@ this wiki, BTW. ## 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. @@ -130,11 +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 @@ -172,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 @@ -186,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 [[HtmlSanitization]], 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.