Ubuntu Wiki

Dev Week -- Writing secure software -- kees -- Wed Sep 2nd, 2009

UTC

(03:05:31 PM) kees: so, if I understand correctly, discussion and questions are in #ubuntu-classroom-chat
(03:05:51 PM) kees: I'll be watching in there for stuff marked with QUESTION:  so feel free to ask away.  :)
(03:06:16 PM) kees: this session is a relatively quick overview on ways to try to keep software more secure.
(03:06:26 PM) kees: I kind of think of it as a "best-pratices" review.
(03:06:59 PM) kees: given that there is a lot of material in this area, I try to talor my topics to langauges people are familiar with.
(03:07:44 PM) kees: as a kind of "show of hands", out of HTML, JavaScript, C, C++, Perl, Python, SQL, what are people familiar with?  (just shout out on the -chat channel)
(03:07:57 PM) kees: (oh, and Ruby)
(03:08:33 PM) kees: okay, cool, looks like a pretty wide variety.  :)
(03:09:04 PM) kees: I'm adapting this overview from some slides I used to give at talk at the Oregon State University.
(03:09:20 PM) kees: you can find that here: http://outflux.net/osu/oss-security.odp
(03:09:48 PM) kees: the main thing about secure coding is to take an "offensive" attitude when testing your software.
(03:10:03 PM) kees: if you think to yourself "the user would never type _that_", then you probably want to rethink it.  :)
(03:10:59 PM) kees: I have two opposing quotes: "given enough eyeballs all bugs are shallow" - Eric Raymond, and "most people ... don't explicitly look for security bugs" - John Viega
(03:11:30 PM) kees: I think both are true -- if enough people start thinking about how their code could be abused by some bad-guy, we'll be better able to stop them.
(03:11:52 PM) kees: so, when I say "security", what do I mean?
(03:11:55 PM) kees: basically...
(03:12:19 PM) kees: I mean a bug with how the program functions that allows another person to change the behavior against the desire of the main user
(03:12:29 PM) kees: if someone can read all my cookies out of firefox, that's bad.
(03:12:38 PM) kees: if someone can become root on my server, that's bad, etc.
(03:13:07 PM) kees: so, I tend to limit this overview to stuff like gaining access, reading or writing someone else's data, causing outages, etc.
(03:13:21 PM) kees: I'll start with programming for the web.
(03:13:46 PM) kees: when handling input in CGIs, etc, it needs to be carefully handled.
(03:14:09 PM) kees: the first example of mis-handling input is "Cross Site Scripting" ("XSS").
(03:14:53 PM) kees: if someone puts <b>hi</b> in some form data, and the application returns exactly that, then the bad-guy can send arbitrary HTML
(03:15:02 PM) kees: output needs to be filtered for html entites.
(03:15:30 PM) kees: luckily, a lot of frameworks exist for doing the right thing: Catalyst (Perl), Smarty (PHP), Django (Python), Rail (Ruby).
(03:16:02 PM) kees: another issue is Cross Site Request Forgery (CSRF).
(03:16:30 PM) kees: the issue here is that HTTP was designed so that "GET" (urls) would be for reading data, and "POST" (forms) would be used for changing data.
(03:16:44 PM) kees: if back-end data changes as a result of a "GET", you may have a CSRF.
(03:16:54 PM) kees: I have a demo of this here: http://research.outflux.net/demo/csrf.html
(03:17:15 PM) kees: imdb.com lets users add "favorite" movies to their lists.
(03:17:29 PM) kees: but it operates via a URL http://imdb.com/rg/title-gold/mymovies/mymovies/list?pending&add=0113243
(03:17:52 PM) kees: so, if I put that URL on my website, and you're logged into imdb, I can make changes to your imdb account.
(03:18:09 PM) kees: so, use forms.  :)
(03:18:20 PM) kees: (or "nonces", though I won't go into that for the moment)
(03:18:34 PM) kees: another form of input validation is SQL.
(03:19:13 PM) kees: if SQL queries aren't escaped, you can end up in odd situations
(03:19:15 PM) kees: SELECT secret FROM users
(03:19:23 PM) kees: WHERE password = '$password'
(03:19:39 PM) kees: with that SQL, what happens if the supplied password is    ' OR 1=1 --
(03:19:51 PM) kees: it'll be true and will allow logging in.
(03:20:15 PM) kees: my rule of thumb is to _always_ use the SQL bindings that exist for your language, and to never attempt to manually escape strings.
(03:20:32 PM) kees: so, for perl
(03:20:34 PM) kees:     my $query = $self->{'dbh'}->prepare(
(03:20:34 PM) kees:         "SELECT secret FROM users
(03:20:34 PM) kees:          WHERE password = ?");
(03:20:35 PM) kees:     $query->execute($password);
(03:21:03 PM) kees: this lets the SQL library you're using do the escaping.  it's easier to maintain, and it's much safer in the long-run.
(03:21:37 PM) kees: some examples of SQL and XSS are seen here:  http://research.outflux.net/demo/sql-bad.cgi
(03:22:07 PM) kees: If I put: <blink>oh my eyes</blink>   in the form, it'll pass through
(03:22:42 PM) kees: if I put:   ' OR 1=1 --     in the form, I log in, etc
(03:23:08 PM) kees: http://research.outflux.net/demo/sql-better.cgi   seeks to solve these problems.
(03:23:32 PM) kees: another thing about web coding is to think about where files live
(03:23:59 PM) kees: yet another way around the sql-bad.cgi example is to just download the SQLite database it's using.
(03:24:22 PM) kees: so, either keeping files out the documentroot, or protecting them: http://research.outflux.net/demo/htaccess-better
(03:25:11 PM) kees: so, moving from web to more language agnostic stuff
(03:25:28 PM) kees: when your need to use "system()", go find a better method.
(03:25:57 PM) kees: if you're constructing a system()-like call with a string, you'll run into problems.  you always want to implement this with an array.
(03:26:06 PM) kees: python's subprocess.call() for example.
(03:26:30 PM) kees: this stops the program from being run in a shell (where arguments may be processes or split up)
(03:26:52 PM) kees: for example, http://research.outflux.net/demo/progs/system.pl
(03:26:59 PM) kees: no good: system("ls -la $ARGV[0]");
(03:27:05 PM) kees: better: system("ls","-la",$ARGV[0]);
(03:27:10 PM) kees: best: system("ls","-la","--",$ARGV[0]);
(03:27:35 PM) kees: in array context, the arguments are passed directly.  in string context, the first argument may be processed in other ways.
(03:28:15 PM) kees: handling temporary files is another area.
(03:28:37 PM) kees: static files or files based on process id, etc, shouldn't be used since they are easily guessed.
(03:28:54 PM) kees: all languages have some kind of reasonable safe temp-file-creation method.
(03:29:12 PM) kees: File::Temp in perl, tempfile in python, "mktemp" in shell, etc
(03:29:40 PM) kees: i.e. bad:  TEMPFILE="/tmp/kees.$$"
(03:29:52 PM) kees: good: TEMPFILE=$(mktemp -t kees-XXXXXX)
...