canspice.org

If you’re going to be attending OSCON 2005, there are a few tips you should read.

Tip One: Turn off your cell phone. Don’t be one of Those People who has their cell phone with annoying ring tone go off in the middle of a tutorial. Or, if you really must know when calls come in, put your phone on vibrate.

Corollary to Tip One: If your phone rings in the middle of a tutorial, for the love of God don’t take the call. This one goes out to the guy in Damian Conway’s Presentation Aikido tutorial Monday morning. His phone went off (with annoying ring tone set to the loudest volume possible), and he took the call! “You called me at a really bad time, I’m in the middle of a tutorial.” If it’s such a bad time then why didn’t you turn off the phone? Jesus!

Tip Two: A number of you are overweight. Take the stairs. Don’t get on the escalator. Walk up the stairs to get up to the tutorial rooms. It’s not like you’re climbing the Empire State Building, it’s only about 40 stairs.

Tip Three: A number of you are overweight. I know that food is a valuable and scarce resource and must be hoarded, but when the pastries come out at the tutorial breaks, take one pastry instead of loading your plate.

Tip Four: Turn off the speakers on your laptop. We don’t need to hear the Windows startup sound every time you fire up your laptop, or chimes whenever some kind of warning pops up.

The second half starts off with a recap of session hijacking. To help prevent session hijacking, one could propagate some kind of authentication token that is hard for someone to duplicate. Say, an MD5 hash of something random.

Another attack is cross-site request forgeries, where an attacker can send arbitrary HTTP requests from a victim. Everything looks like it’s coming from a legitimate user with established trust and access, and there’s nothing to show that this user isn’t actually sending the requests. It can be used to, say, make someone buy a book without them knowing. To fix this, Shiflett suggests putting a unique token in every form that you send to the user, then make sure that that same token comes back with every form submission.

Switching to security audits, he’s saying the right things. It’s not preferable to audit your own code, but doing so still has value. Audits take time but are usually more worthy than not doing them. In a security audit nothing should be off-limits, and this includes hardware. For PHP, at the very least an application should filter input and escape output. That really holds for any application, but since this tutorial is in the PHP track…

When doing an audit, have the design explained to you first by the developers. Design documents can help, but the developers know the application best. “A poor or unnecessarily complex design is a security risk.” Try to find where data enters and exits a system, and try to follow the data through the application. If it’s difficult to do, then you’ve probably got a complex design that can lead to security holes.

“Stream-of-consciousness is the most popular design. This is why so many PHP applications are insecure.”

Server configuration is important as well. There are some things to avoid, like turning on register_globals, turning on allow_url_fopen, or displaying errors to the user on a production server.

Question from the audience: “Why is using an uninitialized variable wrong?” Oh dear. I know I’m a Perl programmer and you don’t have to initialize variables (or even predeclare them if you don’t use “use strict”), but I’ve programmed enough in other languages to know that uninitialized variables can access random memory, get set up differently each time, and just generally cause headaches. In PHP it’s even worse because if you turn on register_globals, the user can initialize variables for you. That’s a horrible horrible idea because it can lead to things like SQL injection. Horrible.

Back to auditing, there are two approaches to take: identify the input and trace it forward through the code, and identify the output and trace it backward through the code.

Bad habits to look for in PHP code are error suppression, misguided trust of HTTP request headers (it’s considered to be user input since it comes from the user and can easily be spoofed — don’t use referer-checking for form validation!), and unescaping strings. Common mistakes are sending tainted or unescaped data to the client or a database, storing authorization level in a cookie (bad bad idea), and storing the username and password in a cookie.

That’s it for the tutorial. Some further information can be found at: PHP Security Consortium, its library, its security guide, Chris Shiflett’s website and brainbulb.com.

[link to first half]

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]

Starting off the second half of Damian Conway’s presentation titled “Presentation Aikido” with visual style. Again, it’s about simplicity, using shadows and underlining and whatnot subtly. He’s done shadowing so subtly that we can’t even see it. Clearly one needs to check monitors and projectors before doing a presentation. :-) Luckily his second example worked, although I don’t really care for his choice of colours (yellow on green).

Which transitions nicely into colour schemes. Contrast is essential. Contrast is essential. Contrast is essential. There are many tools that allow you to generate complementary colour schemes: use them. Keep in mind that about 10% of the population has some difficulty with colour perception, so don’t use colour as a tool for discriminating between different texts, use brightness instead (or maybe different fonts). There’s a tool at vischeck.com that one can use to view webpages under different types of colour impairment.

It’s essential to keep people interested, so every so often surprise your audience. Tell them a story, use examples, make comparisons, change your pace and style (but don’t change your pace just for the sake of it). And every so often, give your staircases landings to give people a chance to digest what they’re injesting. You can also use those landings to let people know that a new topic is coming up, to keep the audience oriented with the flow of the presentation.

“Just because you can doesn’t mean you should.” He’s talking about transitions. Make them smooth and elegant, and use the obvious transitions in special occasions, possibly when you come to a “landing.” And for the love of Pete, don’t use transitions between slides, either fade in or just switch to the next one. Don’t zoom in, don’t do cube rotation, don’t do any of that rot.

Don’t use architecture charts. I’ve been guilty of this, and nearly every presentation I’ve seen has one. “Show a chart, lose an entire audience.” If the audience needs to know it, put it in the notes. Ditto for graphs.

If you’re going to put your name and title on your slides (which isn’t a bad idea), make them subtle and ignorable so they don’t interfere with the information on your slides. Lose the logo from each slide, because putting the logo on is distracting and it makes you look like a salesperson. If you have to have a logo because of corporate policy, watermark it.

Moving on to presentation, make it look effortless. Make it look like you’re on TV so your audience doesn’t feel pity for you. That’s something that’s learned and comes with practice. Make it look easy, even if the actual material is difficult, because the audience wants it to look easy and not threatening. And be yourself, but be yourself-less. The presentation isn’t about you, it’s about your material. You’re a conduit for relaying the information to the audience.

“Don’t be paralyzed by the butterflies.” Use your nervousness and turn it into nervous energy. Rituals can help you focus, get you into the same groove. Rituals can be anything, but as long as it takes you back to the familiar it’s good, it’s less frightening. He recommends not ignoring the audience before doing your presentation, but if you talk with someone, talk about them instead of yourself.

Have a backup plan. Always carry backups of your material. Conway’s a little anal about backups (he says “sophisticated”), with five backups in five different locations, but it works for him. It may only save you once, but that’s enough.

Dress how your audience expects you to dress. If you’re a CEO, dress like a CEO. If you’re a hacker, dress like a hacker.

Don’t read your presentation. The audience is perfectly capable of reading the presentation, they don’t need it read for them. Unless you’re reading to 2-year olds, of course. To do this, make sure you rehearse your presentation, and rehearse it aloud. You can have a cheat sheet, but it’s not the script, it’s a list of points you are going to make.

Demonstrations beat descriptions, because it’s easier for the audience to get the point. Make sure that your demonstrations work, though, and make sure that you’ve got local copies of your demos, if they normally live on the Internet somewhere. Use IO::Prompt if at all possible.

Use a microphone, drink water, and make a pitstop before you start. Watch the time, and make sure you stick to your intended schedule.

For handling questions, have a policy. Don’t just take questions randomly, decide where and when and if you’ll take questions, and let the audience know about this policy. When you answer questions, repeat the question and try to paraphrase it. If you don’t know the answer, don’t fake it, say something clever instead like “I don’t know the answer,” or try to redirect the question to someone who might know the answer.

And try to do presentations fairly often. Even if they’re not formal presentations, there are many situations you can use to improve your skills. “The only way to speak better is to speak.”

[link to first half]

I don’t give presentations all that often, but when I do I generally tend to get nervous and flustered and do all the bad things that you’re not supposed to do to give a good presentation. When I saw that Damian Conway was giving a tutorial at OSCON 2005 titled Presentation Aikido, I was jazzed. Conway always does a good talk, and a presentation about giving presentations was just too good to pass up.

20 minutes in and the main point seems to be “be confident.” To be confident you need to know your material beforehand and know it well. If you don’t know it well then you’ll be up there giving a presentation, stumbling all over the place. You need to prepare your presentation and notes beforehand and practice it. You need to talk about what you care about.

You should take quite a bit of time to come up with your presentation. Conway suggested 10 hours of prep for each hour of presentation. 20:1 if you’ve got something relatively tough. He said for this three hour tutorial he took 80 hours to come up with it, and was still fiddling with it the night before.

Oh, and you need to be entertaining: “Entertaining always trumps informative.” Tell a story. Even if it’s made up, it’ll keep the audience interested and keep the presentation topic grounded in reality. Use metaphors, but use good metaphors: “I’ve never considered time as a non-renewable resource.”

Sidenote: This must be a good presentation because in a room full of geeks only a handful have their laptops out, and there are only two or three typing. End sidenote.

You should have five major points that the listener is going to take away with them. Humans don’t have a very big buffer so any more information than this will just leak out of their ears.

He’s currently making the point that presentation is more important than the information: “having great information on a shoddy-looking slide is actually worse than shoddy information on a great-looking slide.” I agree with his point, but for the most part I think he should be making the point that simplicity is more important than attacking the user with graphics. Actually, it looks like he is, but doing so in a bit of a roundabout fashion instead of outright saying it.

Yes, he is promoting simplicity. For presentation style, don’t use the Microsoft standard PowerPoint templates. “Steal from the cool kids: Apple, Bang & Olufsen, The Perl Journal… no substance, but lots of style.” For fonts, don’t use many. Give each font a meaning: italics for headings, classic serif for content, fixed width for code. Don’t use Papyrus (it’s overused) or Comic Sans (it looks amateurish). If you use images, use them meaningfully and in moderation, “like seasoning.” Ditto for animations, but use them even more sparingly: “if I can’t do it easily with the limited facilities in PowerPoint, it’s probably too complex to bother with.” Ditto for video, but use video even less often than animations.

We’re now at the half-way point. Time to get some coffee.

[link to second half]