Video GreenSQL is a Database Security Solution, says CTO David Maman (Video) 108
Video no longer available.
'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.
Please forgive my likely stupidity (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”)?
Don't miss this important message! (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.
Re:Please forgive my likely stupidity (Score:5, Insightful)
Re:Please forgive my likely stupidity (Score:5, 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.
Re:Please forgive my likely stupidity (Score:5, 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...
I like it and I hate it (Score:4, Insightful)
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:Please forgive my likely stupidity (Score:5, Insightful)
Re:Please forgive my likely stupidity (Score:4, Insightful)
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 (Score:4, Insightful)
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...
Downsides (Score:5, Insightful)