diff options
| -rw-r--r-- | doc/security.mdwn | 40 |
1 files changed, 25 insertions, 15 deletions
diff --git a/doc/security.mdwn b/doc/security.mdwn index 75e91a8a2..956351d70 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -10,21 +10,6 @@ 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? - ## svn commit logs Anyone with svn commit access can forge "web commit from foo" and make it @@ -43,6 +28,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 @@ -130,6 +131,15 @@ 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 |