Slashdot Mirror
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.
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”)?
'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.
Why not just fix your crummy code that is vulnerable to SQL injection?
Really, who doesn't sanitize their inputs anyway? Never trust anything submitted by anyone until you have verified it against your own rules.
Good old Little Bobby Tables
Soylent GreenSQL?
I am not really here right now.
And by encouraging, I mean, encouraging devs everywhere to write even more sloppy code.
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.
Religion is what happens when nature strikes and groupthink goes wrong.
Wouldn't it be easier just to fix your goddamn code?
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
Dude! The horses have broken away from the green bandwagon and the brake has failed. The green bandwagon is careening out of control down the hillside and towards the precipice.
You picked a really bad time to jump on to the green bandwagon by naming your product GreenSQL.
Every post I've read so far makes the critical error of assuming that an application can be perfected, and that when it is perfected, it cannot participate in a SQL injection attack. That's really poor analysis.
It is common for SQL to be synthesized within plpgsql/PL/whatever (database extension language) functions the same as it is in PHP or Java, and the result can be an SQL injection vulnerability. No proxy will protect from that. You must sanitize inputs on database functions that synthesize SQL, just the same as application functions that synthesize SQL or prepare statements.
In other words, a partial solution is not a solution.
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.
Okay so you block admin queries, great. But most people attempting to hack are not out to destroy your db - they're trying to get data from it. The same kind of data that your applications need, and so can't be reliably blocked via heuristics. Chances are if you're naive enough to think that it will, you've also stored some nice juicy plaintext data in your db, ripe for plucking ;)
create a file containing a string like this...
(SUBSTRING|COLLATE|HEX|BIN|CONCAT|LOAD DATA INFILE|LOAD_FILE|CHAR|DROP|\;|\-\-|HAVING|1=1|CAST|CONVERT|UNION ALL SELECT|UNION SELECT|BENCHMARK|WAITFOR|\#|\@\@|SHUTDOWN|WAIT|VERSION)
Then use a stored function defined like this...
DELIMITER //
CREATE DEFINER=`user`@`host` FUNCTION `greenSQL`(`fileName` LONGTEXT, `sqlStmt` LONGTEXT) RETURNS INT(1)
SQL SECURITY INVOKER
COMMENT 'Loads file specified and compares against supplied SQL statement for blacklisted commands'
BEGIN
DECLARE fText AS TEXT;
SET fText=LOAD_DATA(fileName);
DECLARE x INT(1) DEFAULT 0;
SELECT sqlStmt REGEXP fText INTO x;
RETURN x;
END//
DELIMITER ;
and execute it prior to the actual SQL statement like so?
CALL greenSQL('//path//to//blacklistSQL', 'SELECT * FROM table WHERE 1=1')
On second thought, forget the hurray.
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.
Korma: Good
"Green" is another meaningless buzzword, anyone who uses it should be beaten with a carbon-neutral recyclable tapered cylinder, e.g. wooden club. Might mean something uses less energy than another thing, might mean economical to a person but with heavy government subsidies, might mean could be recyclable if ground into powder and used as cheap filler to cut a good mix. fuck green.
I put a SQL in front of your SQL so you can SQL while you SQL...
Or you could just put all SQL commands thru a function that made sure there were no administrative commands. This would be fast and seems like a good
precaution. Could be an option for the major SQL wrappers (php, perl, Ruby). Enabled by default.
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
...as they are slashdotted into next Tuesday.
Who did what now?
So, how exactly is GreenSQL a better approach than mod_security? AFAIK it is possible to just filter out all attempts at injecting MySQL statements with mod_security.
they think a good 'web designer' is someone with some kind of qualification in graphic design
And they would be correct. A good web designer IS somebody with some kind of qualification in graphic design at least 90% of the time.
A good web developer is what most companies don't realize that they need.
There are good designers a plenty in this world, but good developers seem to be spread a bit sparsely these days.
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
If you are running MySQL, typically you don’t want to allow direct connection from outside. In most cases, you might have web server running on the same server where the MySQL database runs so just set the proper IPTABLES rules and you then mitigate a huge potential breach. Then, if the mole is inside you can dig-dug them out and publicly flog them later. Right?
Because configuring your existing SQL server to not run multiple queries wouldn't solve 90% of the problems, and connecting through a user that doesn't have DROP would solve the other 10%.
I love smart solutions for dumb people, they're exactly the same as dumb solutions for smart people. Maybe that's the conservation of dumbness law. Even the name fits the law.
Aren't there moderators to filter out spam like this?
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.
For your security, this post has been encrypted with ROT-13, twice.
MongoDB is.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I'll just sanitize my SQL inside my application, rather than purchasing some totally unneeded shit solution looking for a problem.
somehow the hacker-gods here missed that most of the web-apps in the world still connect to the database with a single DB user. meaning, if someone compromised the web server (or application server) through *any* means (say, an incredible remotely exploitable hole in RDP, just to throw a crazy example) he can do *anything* in the database with the hardcoded user-name and password. There's not much you can do about that, other than building the app with tight DB permissions (which no one ever does), or put up a database firewall to allow only a pre-fixed set of commands.
can't do that with mod_security, can ya?
plz to be a little less silly, k? thx
1998 called, they want their troll back. It's called PDO, its been part of the core since 5.1 (released 7 years ago) is easier to use than any of the dated SQL functions.
Others have commented on the security benefits of prepared statements, but one problem with them, at least on Postgres: Since you're planning the query before executing it, the planner doesn't have as much information as it will at execution time, and it might not pick the optimal plan - especially if the database changes significantly between PREPARE and EXECUTE.
OTOH, I suppose you could take every statement and turn it into a group of PREPARE/EXECUTE/DEALLOCATE. Not sure if there are performance implications with that, though.
... as well as blocking known db administrative commands (DROP, CREATE, etc).
I'm not a MySQL expert, but why would you connect to a database from an app in production with an account with the privilege to execute commands like DROP or CREATE?
This entire thread has been a trainwreck from top to bottom. It ignores two critical concepts:
Security is hard.
Programming is hard.
Programmers screw up, even the good ones, and brilliant software architects make the occasional bone-headed blunder, or the slick new library or framework has a hidden bug or backdoor you didn't count on. Yet programmers keep saying security is easy, if only everyone uses Silver Bullet Tool or the Simple Fix Pattern or just fire all the bozos, then everything will be swell! What a load of baloney.
This is a new class of firewalls that filter based on deep packet inspection and application-specific criteria, and they are going to be deployed pretty much everywhere in the next couple of years. In addition to database-specific firewalls and proxies, I've deployed web-application firewalls designed to identify and kill XSS attacks. Yes, it's expensive. Yes, it's insanely hard to configure and troubleshoot. Yes, it adds latency. No, it's not 100% guaranteed effective in all cases, there is no silver bullet. Our network security architects and our webmasters are thrilled to have it... because the alternative - "y u no get more better programs?" - is stupid. I mean, one mouth-breather in this thread suggested we only buy open-sourced products, as if we'd have the domain experience and budget to run a code audit on a major database-dependent application from a third party.
Next up in the lab? IP-Telephony specific firewalls - it will pick out and validate SiP packets without letting anything else thru, and block malicious traffic based on known attack signatures. Yes, the signatures are updated constantly, and the firewall "learns" new ones. Pretty slick actually. More of its kind are headed our way. Open Source, until now, has been really lagging behind in network defense. It's a shame, as OSS tools are pretty up to date in IDS and network hardening.
How will this work for poor Bobby Tables?
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
Hi Everyone,
The GreenSQL description in this post has nothing to do with the video content.
This text was taken from our open source project web site, which is not our main focus any more (due to a free version) and is not being updated frequently.
GreenSQL has been working hard on a completely new product, (that got nothing to do with the open source version), which is also available for free to secure one database server, you can download it at www.greensql.com
GreenSQL Unified Database Security (UDS) Solution provides Database Security, Database Auditing, Database performance and Real Time data masking.
Supporting Microsoft SQL Server, MySQL and PostgreSQL database and running on Windows and Linux operating systems.
David