The Suburban Chicago PHP & Web Development Meetup

Learn valuable coding skills…from the folks at Google, for free through Google Code University.

In case you didn’t see the news, tens of thousands of web sites were hacked to infect visitors and hijack their PCs. The sites were apparently modified by a script that found SQL injection vulnerabilities in sites and used them to add its own code to, well, pretty much every field on every record in the database, hoping one of those fields would be part of the site’s content.

SQL injection is one of the biggest security problems in the PHP world. But, it doesn’t have to be a problem.

The simplest thing you can do to prevent SQL injection is to sanitize your inputs. If you’re expecting an integer, check that the value is an integer before you plug it into your query. Some people suggest using the addslashes() function on any value you plug into a query, but that still leaves room for improvement. The mysql_real_escape_string() function provides a little better security.

An even better way to thwart SQL injection is through prepared statements. They’re supported by the MDB2 library from the PEAR project, and I’m sure many other libraries support them. A prepared statement query looks something like this:

SELECT * FROM users WHERE username = ?

When you run the query, you give the database library a list of values to match up with the ?s in the prepared statement. The library then passes those values to the database, saying “I want you to find this exact value. Don’t interpret it, just look for this value verbatim.” If someone tries SQL injection against a prepared statement, they’re just going to get 0 results back.

Sure, there’s a performance penalty for doing prepared statements, but the security benefits are well worth the overhead. You don’t want your site to be one of the “tens of thousands” infecting other people’s PCs, now, do you?

---

Edit: modsecurity.org has the query string used in this attack, and information on how the mod_security Apache module can filter out attacks like this.

I wish I had bookmarked a blog entry I read this morning on how PHP is a dead language for everyone except $7.95/mo web hosts. I certainly don’t see that as the case, but I may be biased being a PHP developer with an overly full workload who knows a bunch of people who like and use PHP. I’ve given some thought to the future of PHP, though, and I have to agree it’s on the way out, but only in the same sense that Java is on the way out.

Java is still out there, and I get tons of calls & emails from recruiters every week looking to fill Java positions (even though I haven’t updated my online resume in over a year). Java positions tend to pay well, and are usually with big, dependable companies. They’re safe, but probably not very “fun”. Very few new open source projects are written in Java — that’s not where the action is anymore. Likewise, PHP started out as a hobbyist thing but grew into a language used by Google, Yahoo!, and other big names on the Internet. PHP is where Java was a year or two ago. Python is where PHP was a year or two ago, and Ruby is where Python was back then.

With one company (Zend) dominating the community like they do, and with big companies using it, PHP seems to have become kinda “corporate”. Remember when your favorite band signed with a big label? PHP kind of did that. The indie fans who dug its original sound and obscurity have moved on to other cool & obscure languages. The sound changed, man. It used to be about the music, man, but now it’s all about writing songs for yuppies to listen to while they drink their lattes in their BMWs!

Ok, this metaphor is getting out of hand. But, you get where I’m going with this, right?

Ruby and Haskell are the big “indie” programming languages these days. The 20% kind of programmers see them pushing the boundaries and breaking us out of the C++/Java influenced paradigms which have dominated for more than a decade. They’re the programming languages of rebels…digital Che Guevara t-shirts, if you will.

Know what else they’ve got? Why the Lucky Stiff.

Why’s (Poignant) Guide to Ruby is a programming book, the likes of which I haven’t seen since Mr. Bunny’s Big Cup o’ Java back in ’99. It teaches the basics of Ruby programming through surreal cartoons, personal anecdotes (usually not about programming), and code examples. It’s fun, it’s catchy (chunky bacon!), and it’s unlike any book I’ve seen the PHP community produce. It’s even published online with a Creative Commons license, for that extra bit of indie cred.

Think what you will of a programming book written in this style, but you have to admit that it’s “out there”. It’s different, and that makes it attractive. PHP doesn’t have Why the Lucky Stiff. We have Zend. And, while I’m sure the Zend crew knows how to party, their website doesn’t reflect it. When you’re pushing a $250/seat IDE, it has to look attractive to the kind of people who cut checks to order $250/seat IDEs, not the kind of people who stay up into the wee hours of the morning learning new programming languages.

I’m not saying we should go out and steal this idea, but maybe ask ourselves why the PHP community doesn’t have a Why, and what might prevent us from having one in the future. If the answer involves the words “management”, “corporate”, or “inappropriate”, we’re doomed. Now that PHP 5.x is coming into it’s own, attention will be focussed on PHP 6.x for a glimpse of what the future holds. If PHP is to remain popular among the passionate programmers out there, it needs to catch up feature-wise. I, for one, dislike writing complex apps in a language that doesn’t have namespaces. It also needs to start pushing boundaries.

If PHP “sells out”, it wont mean the immediate death of the language, community, or even the job market — Java has proven that. But it will start it on the path of decline, and once you’re on that path it’s hard to get off it. We need to make PHP fun again. PHP needs chunky bacon.