web commit from 74.6.87.17: poll vote

[git.ikiwiki.info.git] / doc / security.mdwn

diff --git a/doc/security.mdwn b/doc/security.mdwn
index f3567d1558c5c2993571b5dc5a4eb0b9d33d2a46..154566cd8709f7b65a479130a1140d73958af6eb 100644 (file)
--- 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.
 
 others edit pages in your wiki, then some possible security issues do need
 to be kept in mind.
 

+[[toc levels=2]]
+

 ----
 
 # Probable holes
 ----
 
 # Probable holes


@@ -16,7 +18,7 @@ _(The list of things to fix.)_
 
 Anyone with direct commit access can forge "web commit from foo" and
 make it appear on [[RecentChanges]] like foo committed. One way to avoid
 
 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.
+this would be to limit web commits to those done by a certain user.

 
 ## other stuff to look at
 
 
 ## other stuff to look at
 


@@ -134,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.
 
 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
 
 
 ## XSS holes in CGI output
 


@@ -145,6 +149,27 @@ with a username containing html code (anymore).
 It's difficult to know for sure if all such avenues have really been
 closed though.
 
 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.)
+
+----
+
+# Plugins
+
+The security of [[plugins]] depends on how well they're written and what
+external tools they use. The plugins included in ikiwiki are all held to
+the same standards as the rest of ikiwiki, but with that said, here are
+some security notes for them.
+
+* The [[plugins/img]] plugin assumes that imagemagick/perlmagick are secure
+  from malformed image attacks. Imagemagick has had security holes in the
+  past. To be able to exploit such a hole, a user would need to be able to
+  upload images to the wiki.
+

 ----
 
 # Fixed holes
 ----
 
 # Fixed holes


@@ -247,3 +272,10 @@ 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.
 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.