-Let's do an ikiwiki security analysis..
+Let's do an ikiwiki security analysis.
If you are using ikiwiki to render pages that only you can edit, do not
generate any wrappers, and do not use the cgi, then there are no more
_(The list of things to fix.)_
-## svn commit logs
+## commit spoofing
-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.
+Anyone with direct 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.
+## other stuff to look at
-ikiwiki escapes any html in svn commit logs to prevent other mischief.
+I need to audit the git backend a bit, and have been meaning to
+see if any CRLF injection type things can be done in the CGI code.
----
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
+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.
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
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 protecting users from their own broken browsers via the
[[plugins/htmlscrubber]] plugin, which is enabled by default.
+
+## svn commit logs
+
+It's was possible to force a whole series of svn commits to appear to
+have come just before yours, by forging svn log output. This was
+guarded against by using svn log --xml.
+
+ikiwiki escapes any html in svn commit logs to prevent other mischief.
sipb-www / ikiwiki.git / blobdiff