There’s been so much drama recently about MySQL’s public web site getting hacked. It’s causing mis-directed hyperbole about the MySQL database. I’m sure vendors of closed source technologies love the bad press for MySQL, but as a user of production MySQL databases and database administrator specializing in MySQL technology, I’m hearing people ask the question “What does this mean for me?”
As any responsible system administrator will tell you, one must first assess what truly happened. In all cases the MySQL database did exactly what it was asked to do and never failed. How could this be, you may ask? Well, the database is the “persistance” layer in the stack of technologies used to present the mysql.com web site. There are scripts and programs in front of the database that request, accept, process and request storage from the database long before the data actually gets there.
In all cases the database stored exactly the data that requested of it to be stored. It returned exactly the data that it had stored in it. So you can see, the problem wasn’t the database itself, but further up the stack in the presentation layer where there were at least two (2) opportunities to get it right. The first opportunity was on the data input request when the application could have noticed that this data was unacceptable or could have been sanitized. The second opportunity was on the data output / request when the front end application could have used logic to sanitize output knowing it would be handed to browsers and could be malicious.
What is the lesson here?
If you have a web application that takes user input, it needs to be checked, tested and sanitized by the application accepting the data. If your database of choice provides opportunities for security, leverage those as well. These may include stored procedures and prepared statements. Build levels and layers of security. Don’t be afraid to reject user input if it does not pass your standards… and for that matter, have standards… nudge, nudge mysql.com!
Nonetheless, the MySQL database wasn’t the problem, lazy programming was.