GreenSQL is a Database Security Solution, says CTO David Maman (Video)

'GreenSQL is an Open Source database firewall used to protect databases from SQL injection attacks,' says the GreenSQL.net website, which also says, 'GreenSQL works as a proxy and has built-in support for MySQL and PostgreSQL. The logic is based on evaluation of SQL commands using a risk scoring matrix as well as blocking known db administrative commands (DROP, CREATE, etc).' The company also maintains a commercial version as a separate entity. GreenSQL CTO/CoFounder David Maman gives more details about both the company and open source GreenSQL in this video interview.

Comments

Please forgive my likely stupidity

[Anrego]

Don’t worry I don’t do much work with databases any more (nor web apps)... but isn’t the whole SQL injection problem pretty much solved by using prepared statements to decouple data from the query?

I get that prepared statements arn’t a panacea for all vulnerabilities, but I always thought it pretty much did defeated the SQL injection stuff. Are there some this doesn’t eliminate, or is this just one of “those” products (“dear CEO, protect yourself from losing millions like these companies did by installing a DATABASE FIREWALL today”)?

Re:Please forgive my likely stupidity

[ioErr]

Hire competent programmers or hire cheap programmers and install a database firewall instead. Some companies are going to opt for the cheap programmers.

Other than that, I guess you could use the database firewall if you have an old legacy system of questionable quality.

Re:Please forgive my likely stupidity

[Anonymous Coward]

I still work with databases, and yes, this seems like a pretty horrible solution to a not that difficult problem. A "risk scoring matrix" sounds a lot like something that is going to by definition have false positives, which would be a nightmare when trying to debug an app. Not to mention that this thing is going to be another point of failure in general.

To use the obligatory car analogy, I'd say this thing is kind of like wiring a bomb to a fingerprint reader that will go off if someone other than you tries to start your car. Yes, that will probably stop a car thief, but it opens the possibility for some less than ideal side effects, and a better and cheaper solution would probably be to just lock your doors.

Re:Please forgive my likely stupidity

[vlm]

I don't watch videos. Transcript? Maybe the video covers this topic.

My interpretation of a sql firewall is its for when the DBA is smart enough to want to try to prevent injection attacks, but the programmer is not as smart and may not even be working for the same company as the DBA and/or not be open source so you can even find out if it was done correctly.

Traditionally the solution is/was a cluster-y design where you have a "real" db which is periodically synced with the sacrificial "working" db. Essentially a nearly realtime backup system. The replication code copies from "working" to "real" if and only if the request seems reasonable. Add a single record, ok. Truncate a table, um, no thanks. Any detected schema mismatch between the two means alert emails sent as opposed to simply passing them along. Triggers and to a lesser extent stored procedures and to a lesser extent transactions make this a difficult design.

Its possible to design a overall system, using SQL, where turings halting problem applies. Ye Olde "entity attribute value" antipattern is the most obvious situation. That anti-pattern is also known as (and I hold my nose while saying it) "yo dawg I heard you like dbms so I wrote a dbms inside your dbms" Its not as simple as iptables. To some extent you just have to run the sql, hope for the best, and see what happens. So this does not eliminate the need for backups or intelligent security design. More of a replacement for a safety net, than a replacement for a ladder.

Re:Please forgive my likely stupidity

[biodata]

Tell that to the clueless companies that got hacked by LulzSec using SQL injection. There are plenty of companies out there who want a website but don't want the headache of employing people who know how to build one. They can't be bothered to patch their servers, and they think a good 'web designer' is someone with some kind of qualification in graphic design. Once they have an insecure half-baked 'solution', that looks nice, they like to think they can buy in database firewall software to really harden their 'platform' against 'threats'. They don't understand that a website is a machine, and machines should be designed by engineers to stop them breaking all the time. I can see a huge market for this stuff.

Re:Please forgive my likely stupidity

[nahdude812]

SQL injections are impossible if all user input is necessarily relegated to a bound parameter. Unfortunately like pretty much every modern major vulnerability, having a correct way to address the problem doesn't necessarily mean you'll never see it. Saying, "That would never happen to us because we only hire good developers," is not a good affirmative defense.

You can work very, very hard to make sure these sort of common vulnerabilities don't exist in your systems, but you can't guarantee that they never will, even if you control the entire software stack (which many places do not). So in the spirit of defense in depth, it pays to use all the same anti-SQL-injection stuff you're already using, then go ahead and protect yourself in case your other measures have failed.

Unfortunately, however, I dislike the idea that a newly deployed feature might be flagged as suspicious by an intermediary and disabled. This seems like it would create some very hard to diagnose problems - particularly if it rejects some statements from a transaction and not others. Now you may end up in an inconsistent state, and so your security tool might be what actually breaks you.

Re:Please forgive my likely stupidity

[vlm]

Hire competent programmers or hire cheap programmers and install a database firewall instead. Some companies are going to opt for the cheap programmers.

If its a closed source app, even trying to figure out if they used prepared statements probably violates your license and/or a variety of local laws.

Its like the IP firewall argument, you don't need one if your server writers are not idiots, but if its closed source you have no way to figure out if they're idiots, so...

Re:Please forgive my likely stupidity

[Kjella]

Hire competent programmers or hire cheap programmers and install a database firewall instead. Some companies are going to opt for the cheap programmers.

Very many companies will actually, the problem is that all these cheap developers are likely to do all the crazy stuff that triggers the firewall, not to mention fail spectacularly when it's blocked by the firewall. If there's one execution path that may work in cheap software it's the "all is well, no problems encountered" path. So you don't trust them to handle SQL injection, but you do trust them to use transactions correctly and fail gracefully when a firewall blocks statements at random?

Okay not at random but I'm guessing it looks at the arguments too looking for anyone trying to pull a little bobby tables on your database. But if you're looking at anything other than the statement structure, then you're going to run into funny things on production data when "Andy O'Donnell" tries to register for your site that the developers didn't see in testing. Or when someone here on slashdot makes a comment with an SQL snippet, is that someone trying to execute it via some as-yet-unknown exploit? It's just not a good place to put your security.

Re:Please forgive my likely stupidity

[jellomizer]

Yes SQL injections can be solved by proper coding methods, SQL Injections aren't some black magic, they are just due to sloppy coding.
However, They do happen and it is often due to improper training on the topic.

1. Most schools offer a very week teaching in SQL to their college grads. So a lot of new Developers entering in the market are learning as they are going along, and may not always think in terms of SQL injection but coding they were taught in school. String Manipulation in the program then send the final output to the DB server for the Query then you get your results back.

2. A lot of experienced developers where SQL is new to them. Cheap high quality DB solutions have really only been available for little over a decade now. Before you needed to shell out serious dough to get a Relational Database System. So a lot of those old programs were written either using raw file IO. Or some other Non-Relational Database Systems such as BTreave. Now these tools have been enterprise class for a decade that means it is going to take 5-10 years for the developers to integrate the technology in their existing products. And now we have developers while experienced, do not have much skills with SQL and just like the new college grads do not always know the best practices.

3. Business requirements had changed. A lot of apps have grown up from just being a quick tool to scratch an itch to an enterprise level system. These quick tools were made for quick coding and output. Sloppy SQL calls may have been made just because they only had a few hours to make it work. Then requirements are added to it... Then at some point the apps moves from your personal tool to a wider use tool, and its user base expands to a point where you need to consider stronger security, by that time it is often too late and you have too much sloppy legacy code.

SQL is the bastard child in software development. And there is little effort in teaching developers how to use it properly. When I was hiring for programmers I gave them a test... The best way to determine if they would pass or fail is to see if they know how to use a Join statement. A lot of people failed (with SQL on their resumes and decades of experience) when I ask them to give me a basic Join Statement. SQL gets hated for the reason no one ever really teaches it. It is a great system with a lot of cool features... However for most developers they are still wondering why is this any better then file IO

Re:Please forgive my likely stupidity

[Charliemopps]

Over the past year or so I've worked myself into being the technical lead on a bunch of projects, and being an open-source kind of guy in a company that's heavily reliant on many closed source solutions that have not treated us very well in the past I've been pushing for our new contracts, when we're hiring someone to write something for us, to stipulate that the vendor is write code for us, and we get the code... and compile it ourselves. We've had a number of projects where some company wrote us software, and very commonly then jacked up their prices once we were dependent on their software and wanted to modify it. Less commonly, but much worse, sometimes when we'd go back to the vendor for modifications they'd be out of business and we'd basically have to scrap the entire system to make a change. Which we of course wouldn't want to do... so then we'd be stuck using something written all wrong for the processes we're implementing now. Oh how I miss the days when management didn't change business practices every 3 months.

Re:Please forgive my likely stupidity

[Bert64]

The issue with a database firewall (and webapp firewalls in general) however, is that it doesn't fully understand your application and has to guess as to what its trying to do...
As a result, you are likely to get false results, both negative and positive... I have seen several instances where such firewalls break the proper functioning of applications, and other cases where its possible to bypass them.

Re:Please forgive my likely stupidity

[Alex Belits]

No.

You can't possibly generate an exploit-triggering SQL statement unless you either have exploit-triggering expression hardcoded in your code (and then your software is sabotaged already, and any discussion of its security is moot) or applications converts input into constants that are used to generate SQL statements (what the practice you are trying to besmirch, explicitly disallows).

You lack basic understanding of application security, and should never talk about any such subjects ever again.

Re:Please forgive my likely stupidity

[Bert64]

Prepared statements work well and are easy to implement.
Input validation on the other hand is extremely time consuming and error prone to implement, and extremely difficult to get right in all but the simplest of cases.

If you take a blacklist approach, then you open yourself up to unexpected attacks and have to keep adding things to the blacklist.
If you take a whitelist approach, then you will get cases where things break... For instance phone numbers, only allow numerics? what about when someone formats their phone number as xxx-xxx or (xxx) xxxxxx, or +xx xxxx etc... Or names, what about people with names like O'Callaghan or hyphenated names, or names in non latin character sets...

And then for any moderately complex application, you need different input validation rules for different fields, resulting in extreme complexity and plenty of scope for bugs...

At least if you use prepared statements, users won't be able to interrupt the execution flow, and although they might be able to put bogus entries into the database, good output encoding will prevent things like cross site scripting attacks rendering them at best a minor irritation...

Re:Please forgive my likely stupidity

[hcs_$reboot]

Hire competent programmers or hire cheap programmers and install a database firewall instead.

A company that base their programming on "cheap" (incompetent) programmers is likely to face a lot of problems that are not limited to SQL.

Re:Please forgive my likely stupidity

[19thNervousBreakdown]

The need to generate SQL is usually a sign of poor to terrible database design, but even so I know that MS SQL Server at least has identifier escaping functions, and I'd be surprised if any major DB didn't. The usual escaping vs parameters caveats apply, but much, much less so because a.) The SQL server itself is doing the escaping, which presumably is competent to escape its own identifiers, and b.) There are no character set changes to do things like change fancy quotes to ' on you.

Don't miss this important message!

[Anonymous Coward]

'GreenSQL is advertising on Slashdot,' says the GreenSQL.net website, which also says, 'GreenSQL does some stuff and has built-in support for other software. The logic is based on evaluation of input using a buzzword as well as blocking known bad things (death, procreation, etc).' The company also maintains a commercial version as a separate entity. GreenSQL CTO/CoFounder David Maman gives more details about both the company and open source GreenSQL in this video advert.

Re:Don't miss this important message!

[Anonymous Coward]

/. has come to this .. where AC comments get modded as "Insightful" - because the actually are.

Damn right they are. I'm insightful as shit. I'm also funny as hell, informative as fuck, and interesting as goatse.

Am I the first to think...

[HyperQuantum]

Soylent GreenSQL?

Re:Am I the first to think...

[Whalou]

Am I the first to think Soylent GreenSQL?

Reading the posts that came before yours I'd say yes.

Congratulations!

Input sanitization ? Use statement preparation

[bytesex]

Just use SQL statement preparation. It's that easy. Sure, sanitize your inputs, but you'll always have fields that must be able to contain anything, Use 'prepare'. It's there. Yes, it's a shame that PHP doesn't support it (easily), but that's what you get for using an immature language. Use perl. With perl, proper statement preparation comes out of the box and is easy to use. And statement preparation cannot go wrong.

I like it and I hate it

[erroneus]

I hate it for obvious reasons. The fact is, avoiding SQL vulnerabilities is FRIKKEN TRIVIAL and every coder who calls himself professional who enables such vulnerabilities needs to stop calling himself professional. This is a "problem" that shouldn't be fixed from the outside but from the inside.

That said, it's rather like all other things human. You can blame the people for acting like people all day long, but it won't change the fact that they are still people. What's more, if you're not a coder or simply don't have the time and resources to correct the problem or (* worse *) you're using one of those protected PHP programs which can't be fixed except by the guy with the decryption key and/or original source, this may well be the better way to correct and compensate for such problems.

I like that it exists for situations where it's simply needed to protect the business and workflow. I dislike that it's needed at all.

Re:I like it and I hate it

[Bert64]

And people need to stop misusing the word "professional"..

It means someone who is paid to do a job, it doesn't imply any level of competence whatsoever.

Re:Encouraging

[jellomizer]

Not always.
A product like this the could report issues that it found, and lead the developers to bock them. As to keep their logs clean. Espectially you send the developers an email notification every time it tries to get hacked.

Downsides

[biodata]

Apart from the increased consumption of CPU cycles, RAM, file handles etc on the server, the increased latency of DB queries slowing down page returns, the increased testing and debugging load pointed out by others, the false sense of security and the increased cost of infrastructure, the main downside might just be that this could become an interesting new attack vector - how scaleable is this thing? Can it be easily overwhelmed, since it is acting as a bottleneck between database and site? Is it vulnerable to slow loris style attacks? Can it be used for privilege escalation? Until it has survived its first few exploits in the wild we won't really know.

Transcript

[QuasiSteve]

I don't watch videos. Transcript?

Incoming!

-----

Title: David Maman, Co-Founder and CTO of GreenSQL, Talks About Database Security
Description: GreenSQL creates and maintains both proprietary and open source database security software

[00:00] <TITLE>
"GreenSQL is a Database Security Solution..." appears above the SlashdotTV logo bar with "David Maman - Co-Founder & CTO, GreenSQL" in the bottom of the view of a still shot from the interview, showing David Maman over a dark background.

[00:02] David>
My name is David Maman, I'm CTO and founded of GreenSQL.
GreenSQL is a company which provides a solution for database security as well as performance and compliance, eventually.
GreenSQL started as an Open Source project, actually.
In 2006, me and a friend started a very, very nice and easy-going Open Source project, and the Open Source project up 'til today is the only solution available for MySQL database - to secure it.
When I'm saying "securing it", it's not just about hardening password, but it's truly identifying threads in queries running to the database, and detecting it.
Even though it was a very simple solution that we have invested only a few hours in, each one of us, in our free time, the first 3 years we had more than 100,000 downloads of the Open Source project.
The Open Source project was so common that we started receiving a lot of feature requests and a lot of support requests for actually huge organizations - that we were surprised as well.
As time passed we've seen that there is an unmet need in the market; not only that enterprise companies - and I'm talking about high-end telecom and enterprise companies got great solution that they can buy, like Imperva acquired by IBM, and like Secerno which Oracle have purchased 2 years ago, and so on, and so on - but medium and even large organization that can not afford $200k for a basic solution, don't have any solution in the market.
We raised capital, and we started a company and we developed from scratch a new solution, and we call it unified database security.
It's a software-based solution that provides you database security, database auditing, database performance and database masking in one extremely easy to manage, to install, and to troubleshoot software-based solution.
We started sales less than a year ago, and we are going high and up 'til today we got more than 2,000 downloads per month.
The solution is very easy to use, so because we have started from Open Source - and even though it's a completely different solution, that's got nothing to do with the Open Source - we are maintaining the Open Source, but not in a high level.
Even though it's a very easy and simple to use solution, we have decided to also give a free version, so you get the security for free.
You can pay only for additional features like auditing, like masking, like performance and so on, and so on.
So we get more than 2,000 new installations per month at customer premises, and we support, currently, MySQL, Microsoft SQL, PostgreS, and very soon Oracle as well.

[02:54] David>
As a developer, you never take into consideration the entire life cycle of your information, the information itself that is eventually stored inside databases - and it doesn't matter which type of application you develop, and which platform you use, eventually the information is stored inside a database.
Even though you can clear it as "it's okay, and my database is secured", but when unauthorized access is being accessed to your database, unauthorized users, unauthorized application, all the big noise surrounding SQL injection attacks for example, how you can defend from SQL injections.
So naturally, the good developers will say that "I don't need that! I know how to write a secure code!" - and I'm sure most of the people do know how to write secure code.
The problem is that you use a lot of legacy applications and a lot of legacy code, that you

Performance concerns...

[Shoten]

So, I went to the site (be patient; it'll respond eventually) and looked at the section called "GreenSQL Performance Test." I found some fairly interesting benchmarks, which looked good...until I looked at the details. For one thing, they disabled logging...yes, on a security component, they set loglevel to 0. They also disabled the "risk calculation" capability, which is one of their selling (sourcing?) points. I have to wonder what the performance would be like with loglevel set a bit higher, so that you would actually get notice of any failed SQL-based attacks; if the SQL calls are homogenous enough, you can get by without the risk calculation feature by doing a proper ruleset. But no logging? Oy...I can't imagine that would fly in most places where they would be implementing this kind of technology. It certainly fails PCI compliance, that's for sure.

Re:What if.

[Anomalyst]

ripe for plucking ;)

Feathered data, what a concept!