Eli White from Digg presented. It was an interesting talk… He covered:

You are going to get hacked…
- SQL injection
- XSS
- CSRF (cross site request forgery)
- Session Hijacking

Slides (PDF, ODP) have SQL injection/XSS example, with the hole, the attack, and the prevention.

Technorati Tags: mysqlconf, mysql, mysqluc08, mysqluc2008, eli white, …

 Properties:

Description:

This variable determines how many interrupted connections can occur from a host. If the number of interrupted connections from this host surpasses this number, that host is blocked from further connections. All of the …

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 [...]

As a rule I always execute the following commands on a fresh database installation. Then for each user that is granted privileges, of course they are given a password and the host permissions are locked down as much as possible for their needs, alternately table and column privs as well. I’m not going to get into the parts the manual covers, but rather mention a couple of things on my mind.

First the initial commands:


mysql> use mysql
mysql> delete from user where User='';
mysql> delete from db where User='';
mysql> update user set Password=password('password_here') where User=’root’;
mysql> flush privileges;


However, one thing I’ve noticed is that when you hand over a server to someone that doesn’t necessarily follow your same understanding or regard to user privilege security, bad things can happen. Such as users created without a password. …

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 …

As a follow up to my post about Cesar Cerrudo's new whitepaper, earlier this month David Litchfield talked about putting honeypots in the database in his blog post, Database tripwires..., to catch someone snooping around. The basic idea for non-Oracle databases is to create some sort of alerting function (such as one that fires an email) that gets called by a view with an interesting sounding name or interesting sounding column names. Triggers could work for INSERT, UPDATE, and DELETE, if the attacker is attempting to alter data. However, if the attacker is simply collecting information, then triggers aren't effective because triggers can't be defined on SELECT operations. This is why he …

Cesar Cerrudo of Argeniss Information Security has put out a new whitepaper (.pdf format), Data0: Next generation malware for stealing databases, describing how malware could be crafted to steal information out of databases. For the most part, it stays at a high-level, however, Cesar does give a few example queries (for SQL Server), the appropriate API calls to perform certain operations, etc., which delve a bit more into the technical side, but even these are fairly straight-forward. To demonstrate what he talks about in the whitepaper, he built a simple proof of concept (PoC), but based on what's in the whitepaper (and what is generally accepted as what's possible), nothing seemed outlandish or hard-to-do. Just for those worried about that PoC being …

While researching an article I came across a piece at http://www.simple-talk.com/sql/t-sql-programming/cursors-and-embedded-sql/. Basically the author says “embedded SQL” is bad — meaning developers should never put SQL in their code. Nor should they use ORM tools to generate SQL for them.

Instead, they should access everything they need through stored procedures. I have mixed feelings about this. On one hand, you have to give table-access permissions to users and then deal with the resulting security risks sounds very control-freakish to me. On the other hand, I agree that embedded code can be bad because if you change the database model in any way, you have to rewrite the procedural code that relies on the existence of the previous model.

And of course, stored procedures also help make your code more …