This is a Rant

Edit: see end of post

Linux.com :: Protecting your MySQL database from SQL injection attacks with GreenSQL

This is an article (written by a very clueless person) about GreenSQL which is a tool (written by a very clueless person) that acts as a proxy between an application and a MySQL database which attempts to detect malicious, likely-injected SQL statements.

Do not interpolate strings into your SQL statements.

Then, there are all the hilariously dreadful comments.

"better yet, encode the bloody data before you shove it in there" --Anonymous

Do not interpolate strings into your SQL statements.

"Do you honestly think that anybody who doesn't know how to use simple, foolproof SQL-quoting functions is really going to be able to figure out how to correctly set up a package like this?" --Anonymous

Do not interpolate strings into your SQL statements.

"Why don't you try to actually learn to secure your code instead of being a lazy (or completely unskilled) administrator? Surely mysql_real_escape_string() isn't too hard to incorporate?" --Anonymous

Do not interpolate strings into your SQL statements.

Look, it's simple. Most database interfaces have a function called 'execute' or similar which takes two arguments: a string of SQL with markers like '?' in it, and then a tuple of arguments to be used as the values of those markers.

execute('SELECT * FROM users WHERE name = ? AND email = ?', ("radix", "radix@twistedmatrix.com"))

Do that. Don't do any of the following:

execute('SELECT * FROM users WHERE name = %s and email = %s' % ("radix", "radix@twistedmatrix.com"))

name = "radix";
email = "radix@twistedmatrix.com";
execute('SELECT * FROM users WHERE name = $name and email = $email');

String escaping is an absolutely retarded alternative to this. Why would you bother escaping or "encoding" your strings when you can simply use the database API as it was intended, without interpolating strings?

Edit: This concept of passing parameters has nothing at all to do with the "prepared statements" feature of popular databases. This is a much simpler feature. This is not a new feature. This feature is commonly called "bind parameters", and it has been around for decades.

Why do so few people know about this?

Gmail and HTTPS

If you use gmail, all of your email is probably going unencrypted over the Internet, allowing fairly easy snooping of all your sensitive data. You may feel good that there's an "https://" in your address bar after you type "gmail.com" into it and hit enter, but notice that after you authenticate and start reading email, it's gone back to "http://".

It's been possible for a while to work around this and use https even for email content if you knew what to do in the address bar, but now gmail has made it easier. There's a new option in the main Settings screen called "Always use https". I strongly encourage all gmail users to turn this option on.

It's still really lame that they haven't made it the default mode of operation. Come on, gmail, don't you care about privacy?

Ecru

Remember how I was talking about restricted execution, and mentioned that thing "Monte" that doesn't actually exist? Well actually I was trying to refer to Ecru, a new E implementation in C. After being announced to positive reactions on the E mailing list, Allen posted on his blog about Ecru and why he started the project.

I'm excited about this project. E is a language which is specifically designed to solve the types of problems that I want to solve, but Ecru has a long way to go until it gets there. I hope it gets more contributors!

As for Lua: I do think it's feasible for some serious restricted execution work (or at least I think it might be - I haven't really proven it yet), but I'd much prefer Ecru, because E is so much more sensible a language.