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 (although this isn't necessary, either, and should be avoided) but sa. Meaning you have to configure the SQL Server to use mixed mode. And this is a NEW application that runs on Windows. New as in within the last year or so. Meaning there is no justification for requiring a SQL Server based login in the first place. But it does. Once you get the install done, you can change the sa account password and supposedly everything is kosher. We'll see when an update to the product comes down.

Problem #2 is the network access requirement. The product will run on SQL Server Express. SQL Server Express, by default, only enables Shared Memory. That means it cannot be connected to from the network. No problem, because said security application is running on the same server as the SQL Server Express instance. Wait, there's a problem. The application MUST use TCP/IP. So the surface configuration for the SQL Server Express instance has to be modified to make it LESS SECURE.

Brillant. Two thumbs up on how to violate the Principle of Least Privilege. Remember, this is a security product from a security company.

Case #2: Don't require dbo and Don't require db_creator!

Product #2 is another security product. It requires dbo, according to the documentation. Why? Well, it's creating tables within the database as it stores logging information. Okay, I won't even get into the changing schema, but this does NOT require dbo. It doesn't even require db_ddladmin rights. It requires CREATE TABLE rights assigned explicitly to a security principal. Because the security principal will own said created table. Meaning it doesn't get its security checked on said object. Meaning it AUTOMATICALLY has access to said object.

Product #2 also requires db_creator because as it archives data from the first database to an archive database, it wants to create additional databases. This is a BAAAAAAAAAAAAD idea operationally. Great, you've got this new database created. What about the backup jobs? What about optimization jobs since you are going to be reporting from this database? What about sizing to try to prevent autogrowth and disk fragmentation? Oh wait, you only need to create one additional database but you still want db_creator rights?!? Why not let the DBA create the archive database and it get specified in a configuration somewhere? That makes tons more sense.

Another thumbs up for how to violate the Principle of Least Privilege. And need I say it? This, too, is a security product from a security company.

Case #3: Don't require dbo for an Internet facing web application!

Yes, you read that right. The application is on the Internet. And the company built all data access with the understanding that the app had dbo rights into the database. So if the web server gets compromised, the attacker now has a nice little home to settle into and create the objects he or she wants, AT WILL. And if the database owner happens to be sa, and sa is the owner of master... which has cross-database ownership chaining on, because it's required, ouch. And since the attacker is dbo for the application database, turning on ownership chaining on the app database is but an sp_dboption away.

I won't even go into how they attempted to secure the connection credentials within the application. Let's just say that the way they did it Secure Code said not to. Meaning the developers didn't read the book on how to build Microsoft apps securely. Something about a hex editor on the right file and you've got what you need. At least this wasn't a security product or a security company, but yet another thumbs up.

Case #4: Don't have a blank root password for MySQL and don't allow ANY localhost login access to the app database!

Granted, all access must happen from the host. And I understand that under Windows it's a simple thing to change the root password and get access if you have local access to the box and at least power user rights. However, that requires you to down the MySQL service AND change the root password. Those are two footprints you have to leave. And if, for whatever reason, you don't have at least Power User and you don't know any privilege escalation techniques, simply typing mysql -u root won't get you in.

And while we're on that subject, having a blank user with @localost as the host allows anyone locally to connect with simply mysql. And if that has full rights to your app data, yeah. Any local user can therefore do anything they want with that data. Meaning it's not your data any more.

We're going to give this one two thumbs up as well. While it's not a security company with a security product, it's something we use in security because of the type of information it collects.

In Summary

All 4 cases violate database security best practices. The database platform will be blamed, but it's not the database platform that is at issue. It's how security was implemented by the application and/or the vendor. And we're talking about apps written or updated within the last two years. If they were written back in the SQL Server 6.5 days, I might (*might*) give them a pass, because it was a kinder, gentler world then. Not any longer. For the security companies, there's really no excuse. They have people who come in and tell you and products that scan you to tell you these things are no-nos. Yet you find it in their products.

Okay, I'm done ranting... for now.