(no commit message)
[ikiwiki] / doc / security / discussion.mdwn
1 Copied from an email I sent --[[Joey]]
2
3 > Apart from restricting escape characters and characters with special
4 > meanings to the filesystem (such as '/') or the version control system
5 > (which may not cope with \n), why limit filenames at all?
6
7 Suppose that git-add and git-commit a shell scripts:
8
9         #!/bin/sh
10         /opt/git/git commit $1
11
12         #!/bin/sh
13         /opt/git/git add $1
14
15 Ok, that's crappy code, but git add and commit are only run by a trusted 
16 user at the command line, so it's hardly a security hole. (And frankly, 
17 I'm not all too impressed with the real shell code I've seen in git-* 
18 ..) 
19
20 But there's no security problem until ikiwiki calls it on a filename 
21 that a web user made up. Now, suppose that ikiwiki decided to allow
22 spaces in filenames. Nothing else new, just spaces. Of course, the above 
23 bad code will fail to add and commit such files.
24
25 But it won't just fail, it can even expose private data. Suppose that $1
26 is "foo.mdwn .ikiwiki/userdb foo.mdwn". Then the userdb, with its
27 passwords and emails is committed, along with foo.mdwn.
28
29 Moral: ikiwiki interfaces with code that was not necessarily written for the
30 security context that ikiwiki runs in. Even the most innocuous filenames can do
31 very unexpected things if you let the shell get ahold of them. Ikiwiki needs to
32 sanitize the hell out of user inputted data before letting it anywhere near the
33 shell.