canspice.org

The Monday afternoon tutorial session I’m attending is titled PHP Security and is given by Chris Shiflett. I don’t do PHP programming, but there was nothing else remotely interesting for this afternoon’s session. I’m hoping I can take away some of the techniques or methods given here and possibly use them for various CGI scripts the Joint Astronomy Centre runs.

First off: party foul on Shiflett’s part. Cube rotation as slide transition. At least the slides are readable from the back of the room.

It’s hard to define security, as it’s not absolute (different people have different security standards), it’s difficult to measure (it’s like art — you know it when you see it, but it’s hard to describe what art is), and it must be balanced with usability and expense.

A few principles for security are defense in depth (multiple levels and redundant safeguards), least privilege (only grant the rights that are necessary), keep it simple, and minimize exposure.

Basic steps: consider malicious use of your program, educate yourself, and filter input data.

Another party foul: architecture diagram. Eyes glaze.

“It’s good that we don’t trust users.” Well yeah.

To be able to filter data, you need to identify its source. User input data must certainly be filtered, and (editorial time) I’m of the opinion that every bit of input data should be filtered, even if you’re trusting of the source. It’s just safer that way. (end editorial time) So what is filtering? It’s simply the process by which you inspect data to prove its validity. Don’t try to correct it, as you might make some kind of error and accidentally let malicious data slip through. “Force the user to play by your rules.” Use a whitelist for filtering when possible — assume the data is invalid unless you prove otherwise.

So far it’s been fairly generic, now we’re getting into the more PHP-specific side of things. Coming from a Perl viewpoint, it seems odd to me that PHP doesn’t have built-in taint checking, given its most-common use for web-based programs where user input is processed in some way. The examples being given wouldn’t pass Perl’s taint checking…

It seems there’s something cool called PHP Data Objects that acts as an abstraction layer between PHP data and database data, so that any PHP data you pass to a database will be interpreted only as data and can’t be executed as code. It’s a good idea, in my opinion.

Two most common security vulnerabilities: SQL injection and Cross-Site Scripting.

Huh, strange. He just said he doesn’t try to guess what the bad guys are going to do, which contradicts the first basic step for security, “consider malicious uses of your application.”

Solution to SQL injection: filter input and escape output.

Solution to cross-site scripting: filter input and escape output. PHP programmers must be easily pleased because that one got a laugh from the crowd.

I’m completely missing the point he’s trying to make about exposing code from include files. First off, include files shouldn’t contain purely executable code. It should include functions. I suppose his point is that you could have security through obscurity and making the code visible removes that obscurity. Fair enough, although I thought that this conference was called the O’Reilly Open Source Convention… I bet I’m just missing the point.

Don’t rely on session identifiers that are supplied by the client. Those are considered as user input, and remember that we can’t trust the user. The solution is to use a function called session_regenerate_id() whenever there’s a change in the level of privilege.

Session hijacking involves a hacker impersonating another user by obtaining that user’s session identifier. It’s generally hard to obtain a session identifier by any method besides capturing it by cross-site scripting or looking at logs, to give two examples. To solve this, the PHP programmer should try to protect the session identifier from exposure. One could use SSL, one could propagate it in a cookie, one could use a different domain for embedded resources (say, one domain for images).

And that ends the first half.

[link to second half]