Since the early days of GreenSQL, many people have written us asking why exactly they should implement a database security solution if they have already hardened their web application and are using a web application firewall, like mod_security, or even a professional closed source web application firewall such as Imperva, Breach, or F5.

The answer is not as simple as you may think, and I’m not going to preach to you about the great advantages using GreenSQL in front of your MySQL or PostgreSQL Database.

I’m going to highlight a few obvious current situations which will help you see the full picture of your Database security needs.

What is the core of the company?

When you come right down to it, the Database, eventually, is the core of your company or organization. All the information that the company is built upon is located in the Database. Without it, your company or organization cannot …

GreenSQL- December 2, 2009

GreenSQL has just announced that version 1.2 of its database firewall will provide PostgreSQL databases with the same protection from SQL Injection already enjoyed by MySQL databases. GreenSQL version 1.2 is now available for download as Open Source software from the company’s website at http://www.greensql.net/download

PostgreSQL is a popular Open Source database in wide use by small to medium-sized businesses. Currently, there is no solution, either Open or Closed Source, that provides a database firewall for PostgreSQL databases. As a result, they may be vulnerable to SQL injection attacks, one of the most widespread ways for gaining access to sensitive information stored in a database and/or taking control of a host server.

SQL injection, widely used by criminals, tricks Web applications into providing protected information from a database by exploiting existing queries such as user …

The answers to the last pop quiz are up: http://www.pythian.com/blogs/868/pop-quiz-mysql-cluster

So here’s another pop quiz. Given the following:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 16450949 to server version: 4.1.14-standard-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select count(*),length(password) from mysql.user group by length(password);
+----------+------------------+
| count(*) | length(password) |
+----------+------------------+
|       49 |               16 |
|       31 |               41 |
+----------+------------------+
2 rows in set (0.00 sec)

mysql> select password('foo');
+-------------------------------------------+
| password('foo')                           |
+-------------------------------------------+
| *F3A2A51A9B0F2BE2468926B4132313728C250DBF | …

I was asked this question recently, and I thought it was a great little tidbit of knowledge to pass along. The short answer is “no”. The slightly longer answer was written up by Jan Kneschke when dealing with a forum post about proxy + connection pooling.

From http://forums.mysql.com/read.php?146,169265,169700

The clear-text password is _never_ transfered in the authentication phase.

On the network we have:
* client connects to server (no data)
* server sends a seed (40 char, one-time, random)
* client sends 40 char hash of (seed + PASSWORD(clear-text-password))
* server compares against the hash(seed + SELECT password FROM mysql.user WHERE username = )

That way we never have the password as clear-text on the wire. (only in SET PASSWORD or GRANT statements).

I was recently asked a question by someone who had attended my Shmoocon talk entitled “Why are Databases So Hard to Secure?”. PDF slides are available (1.34 Mb). I was going to put this into a more formal structure, but the conversational nature works really well. I would love to see comments [...]

I've been dealing with a security product from a security company in recent days that breaks best practices with respect to the database configuration. This has reminded me of the list of issues I've seen over the past six months that have raised my ire. I'll rail mostly at products that use SQL Server as the back-end, but I'll save the last example for one that uses MySQL. It's not the database products that are weak. It's the application implementation on them!

Case #1: Don't EVER use SA and don't enable the network if you don't have to!

This said security product recommends the use of SQL Server if you are using it on over 1,000 users. Okay, no problem. It wants its own instance. Okay... that raises a flag in and of itself. Is performance really that bad? Well, no, not likely. Here's the kicker:

To install the application you must use the sa account. Not a service account with sysadmin rights …