Google sticks anti-SQL injection vaccine into MySQL MariaDB fork

Google is dropping encryption into MariaDB, the fork of Oracle’s MySQL, to help shut out SQL injection attacks. Mountain View is credited with developing and testing tablespace encryption in MariaDB Server 10.1 - the community edition of MariaDB. The development has been branded a "major enhancement" for MariaDB security by …

[Rob Carriere]

It doesn't

From a ZDnet article:

"The new MariaDB Enterprise release features protection against SQL-injection attacks using a database firewall filter. In a few months community MariaDB will also include the database encryption developed and used internally by Google, which has been using MariaDB for a year."

So that's two separate and unrelated features.

[admiraljkb]

@1980s_coder

Rob's comment nailed it...

For your last bit "Don't we all use SSL tunnels for this already?" - for data in flight yes - this is for encrypting data INSIDE the tables while at rest. This seems like a good feature to have integrated straight into the DB engine without having to take an overhead hit of encrypting everything, but maybe not. I'll need to do a lot more research before I come to a conclusion on it.

[Anonymous Coward]

It is a "good" idea, but also "interesting" of course. It is widely available in other SQL engines. But MySQL didn't traditionally compete with other SQL engines: it was small, light, fast, and feature poor, used mostly in read-heavy applications where the data was published anyway. Adding encryption is another step (already well underway) in expanding out into other areas.

[Adam 1]

So back to 80's coder's question. How have they mitigated SQL injection attacks? SQL injection works because the SQL language by nature interleaves instructions (select/delete/insert/where/etc) and data. Most DBMS have parameterized queries, where you specify the SQL query with placeholders and then pass the data as part of the parameter structure. The DBMS can then correctly escape strings that it is passed to avoid this problem (and reuse query plans which differ only by parameter value)

Without parameters, the developer has to remember to escape (and probably bound check) all the user enterable data before inclusion in the string. Humans forget things, or fail to understand that just because your JavaScript only accepts an integer, the data may be sent across a http post which a malicious user can easily modify.

So how have they stopped developer stupid?

[Ben Tasker]

I'm completely guessing here, though if I get time I'll probably go and have a read of a more reliable source than TFA.

As the SQL Injection protection seems to be within a query firewall (rather than related to the encryption as El Reg claimed), I'm going to hazard a guess that it does simple query interpretation, looking for things like a UNION within a query that, every time it's run previously, has not included a UNION.

i.e if the query is normally

SELECT title,content FROM articles where id=1;

And the following comes through

SELECT title,content FROM articles where id=1 UNION SELECT username,plaintextpass from users

Then it'd be blocked.

It's only a guess mind, but given Google's propensity for behavioural analysis, I wouldn't be surprised if there's some profiling of queries received and then anything outside of the 'normal' profile gets additional filtering to try and identify whether it's an SQLi attempt.

Still better to fix/avoid SQLi at the application though

[Ben Tasker]

So in case anyone's still wondering (or y'know, wants to make the article factually correct).

The Anti-SQLi measures are implemented by sending your queries to the Database Firewall Filter (called MaxScale) rather than direct to MariaDB itself.

Maxscale appears to support a wide range of filters (including things like requiring a WHERE within delete queries), including time based one's (no delete's outside of working hours for example).

There's not a huge amount of documentation on the anti-SQL side of things at the moment (it just says block specific queries) so I'd guess it's using simple pattern matching rather than fingerprinting (which is what this script for MySQL does).

There's a public repo for Maxscale here but I'm guessing the anti-SQLi filter has yet to make it into there as I don't see any commits that stand out as obviously related (and nothing referring to it in the release notes).

[Adam 1]

Doesn't set need to go before where?

[streaky]

????

Uhm, SQL injection is easy to avoid and should always be dealt with at source, namely the application. I'm lost, Google are lost, the world is messed up.

[Bucky 2]

Some Clarification Would Be Nice

I'm betting the anti-injection stuff and the at-rest crypto stuff are related somehow (perhaps the same encryption algorithms are used in each case), but of course, one does not imply the other, and we are all puzzled by the anti-injection claim.

I wonder if the original article was longer, and the editing process managed to obfuscate the main topic somehow.

Some clarification about why this encryption method will succeed while others fail would be a good addition to the article.

[batfastad]

Pls paste into El Reg CMS

TRUNCATE TABLE `el_reg_authors`;

DELETE FROM `articles` WHERE `copy_pasted`=1 OR `proof_read` IS NULL;

[Adam 1]

obligatory