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.

10 of 108 comments (clear)

  1. Please forgive my likely stupidity by Anrego · · Score: 5, Insightful

    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”)?

    1. Re:Please forgive my likely stupidity by ioErr · · Score: 4, Interesting

      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.

    2. Re:Please forgive my likely stupidity by Anonymous Coward · · Score: 5, Interesting

      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.

    3. Re:Please forgive my likely stupidity by biodata · · Score: 4, Insightful

      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.

      --
      Korma: Good
    4. Re:Please forgive my likely stupidity by nahdude812 · · Score: 4, Insightful

      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.

    5. Re:Please forgive my likely stupidity by vlm · · Score: 4, Insightful

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

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    6. Re:Please forgive my likely stupidity by Charliemopps · · Score: 4, Insightful

      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.

  2. Don't miss this important message! by Anonymous Coward · · Score: 5, Insightful

    '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.

    1. Re:Don't miss this important message! by Anonymous Coward · · Score: 4, Funny

      /. 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.

  3. Downsides by biodata · · Score: 4, Insightful

    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