X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/8a5f9f6e0047149040c50db571faac89ab443085..024a88895410fa60c454c14e09bf0bf34b3e8d3f:/doc/security.mdwn?ds=inline

diff --git a/doc/security.mdwn b/doc/security.mdwn
index 4db756e2e..fea0eb727 100644
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -6,6 +6,8 @@ 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.
 
+[[toc levels=2]]
+
 ----
 
 # Probable holes
@@ -18,14 +20,6 @@ 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.
 
-## XML::Parser
-
-XML::Parser is used by the aggregation plugin, and has some security holes
-that are still open in Debian unstable as of this writing. #378411 does not
-seem to affect our use, since the data is not encoded as utf-8 at that
-point. #378412 could affect us, although it doesn't seem very exploitable.
-It has a simple fix, which should be NMUed or something..
-
 ## other stuff to look at
 
 I need to audit the git backend a bit, and have been meaning to
@@ -91,6 +85,10 @@ _(AKA, the assumptions that will be the root of most security holes...)_
 Someone could add bad content to the wiki and hope to exploit ikiwiki.
 Note that ikiwiki runs with perl taint checks on, so this is unlikely.
 
+One fun thing in ikiwiki is its handling of a PageSpec, which involves
+translating it into perl and running the perl. Of course, this is done
+*very* carefully to guard against injecting arbitrary perl code.
+
 ## publishing cgi scripts
 
 ikiwiki does not allow cgi scripts to be published as part of the wiki. Or
@@ -138,7 +136,9 @@ file not be world readable.
 
 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.
+If you care, you can use https, I suppose. If you do use https either for
+all of the wiki, or just the cgi access, then consider using the sslcookie
+option.
 
 ## XSS holes in CGI output
 
@@ -149,6 +149,13 @@ with a username containing html code (anymore).
 It's difficult to know for sure if all such avenues have really been
 closed though.
 
+## HTML::Template security
+
+If the [[plugins/template]] plugin is enabled, users can modify templates
+like any other part of the wiki. This assumes that HTML::Template is secure
+when used with untrusted/malicious templates. (Note that includes are not
+allowed, so that's not a problem.)
+
 ----
 
 # Fixed holes
@@ -242,3 +249,19 @@ 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.
+
+## XML::Parser
+
+XML::Parser is used by the aggregation plugin, and has some security holes. 
+Bug #[378411](http://bugs.debian.org/378411) does not
+seem to affect our use, since the data is not encoded as utf-8 at that
+point. #[378412](http://bugs.debian.org/378412) could affect us, although it
+doesn't seem very exploitable. It has a simple fix, and has been fixed in
+Debian unstable.
+
+## include loops
+
+Various directives that cause one page to be included into another could
+be exploited to DOS the wiki, by causing a loop. Ikiwiki has always guarded
+against this one way or another; the current solution should detect all
+types of loops involving preprocessor directives.