web commit by joey

[ikiwiki.git] / doc / security.mdwn

diff --git a/doc/security.mdwn b/doc/security.mdwn
index 3c85f57de39d8a8aadf5bf7d3823556506c5737b..77552b1b2e2d2c3abe04d273200b23412b7f9219 100644 (file)
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -6,22 +6,11 @@ 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
-
-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.
+# Probable holes
 
-Of course nobody else seems to worry about this in other wikis, so should we?
+_(The list of things to fix.)_
 
 ## svn commit logs
 
@@ -39,7 +28,23 @@ ikiwiki escapes any html in svn commit logs to prevent other mischief.
 
 # Potential gotchas
 
-Things not to do.
+_(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
 
@@ -57,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.
@@ -72,7 +77,7 @@ 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,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
@@ -199,4 +215,4 @@ pages from source with some other extension.
 
 ## XSS attacks in page content
 
-ikiwiki supports [[HtmlSanitistion]], though it can be turned off.
+ikiwiki supports [[HtmlSanitization]], though it can be turned off.