Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Roblimo posted more than 2 years ago | from the database-security-for-the-masses dept.

Security 108

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

cancel ×

108 comments

Please forgive my likely stupidity (5, Insightful)

Anrego (830717) | more than 2 years ago | (#39547457)

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 (0)

Anonymous Coward | more than 2 years ago | (#39547483)

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

It's an appliance for the paper MCSE they hired since they were too cheap-o to get somebody with real skill.

Re:Please forgive my likely stupidity (4, Interesting)

ioErr (691174) | more than 2 years ago | (#39547497)

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 (4, Insightful)

vlm (69642) | more than 2 years ago | (#39547539)

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 (4, Insightful)

Charliemopps (1157495) | more than 2 years ago | (#39547677)

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 (0)

Anonymous Coward | more than 2 years ago | (#39551577)

If your company is hiring consultants/contractors who don't *automatically* provide the source code along with any software deliverable, then you're doing it wrong. There are plenty of consultants like me who provide source. Frankly, though, most clients have no idea what to do with it and are likely to lose it, so I always end up archiving it for them anyway.

- T

Re:Please forgive my likely stupidity (1)

bjourne (1034822) | more than 2 years ago | (#39547593)

Installation and maintenance of the database firewall isn't cheap either. A sensible company has to consider the probability of a successful SQL injection attack times the amount of damage caused versus the monthly cost of running the firewall.

Re:Please forgive my likely stupidity (2)

Kjella (173770) | more than 2 years ago | (#39547629)

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 (0)

bleh-of-the-huns (17740) | more than 2 years ago | (#39547685)

This really has nothing to do with cheap, programmers. Even cheap programmers are competent in the basics, and while prepared statements (for the original OP of this thread) work, the best solution, and really only solution for many of these types of attacks, would be input validation. That would prevent the ability to send garbage attacks in the first place, and would also negate the need for a third party program to protect the assets.

Re:Please forgive my likely stupidity (3, Insightful)

Bert64 (520050) | more than 2 years ago | (#39547851)

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 (0)

Anonymous Coward | more than 2 years ago | (#39553883)

Your use of the comma, wow! Stupid!

Re:Please forgive my likely stupidity (2)

Bert64 (520050) | more than 2 years ago | (#39547775)

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 (2)

hcs_$reboot (1536101) | more than 2 years ago | (#39548077)

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 (5, Interesting)

Anonymous Coward | more than 2 years ago | (#39547513)

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 (1)

Charliemopps (1157495) | more than 2 years ago | (#39547735)

Well, I'm guessing it depends on how the logging and notification part of the app works and how those features are implemented. We've got a rather large vendor that needs to pull mail from one of our servers. They have a process that does this. If the process fails it logs this. If it fails 100x it a row, it logs that to. They don't send us these logs, they don't call us. We have no idea that the process has failed. It's implemented in the stupidest way possible. I basically had to write my own process that checks to see if we've gotten any data from them in the past couple of hours, and if not it sends out alerts so we can call them and they say "Oh hey, looky there!" But we shouldn't have to do that. But the vendor has absolutely refused to do anything more about the notification process telling us its technically not possible. Which is an outright lie... they really want us to use their email service instead of our own, they charge ridiculous fees for it.. we aren't going to pay for that so they are making the solution we did chose as difficult as possible. Yes, I know we should get a new vendor, but as you likely all know it's a lot more complicated than that.

Re:Please forgive my likely stupidity (0)

Anonymous Coward | more than 2 years ago | (#39547821)

Yup ur spot on... It also sounds like
'You should not have given the db user rights to drop the database table, so if i will sit in the middle like a proxy n stop such commands' instead of teaching people to not use root for db.

Re:Please forgive my likely stupidity (1)

Bert64 (520050) | more than 2 years ago | (#39547895)

This will sell to non technical upper management, who will buy into it purely on the word of the salesman and without consulting any impartial technical staff...
They will see it as a "solution" to the risk of exploitation, and buy in...

A lot of management types see buying a product that claims to solve their problems as the thing to do, rather than actually fixing what they already have.

This is obviously a nasty kludge, but people are used to being stuck with proprietary software they can't fix and thus implementing all kinds of nasty hacky workarounds to make it do what they want.

Re:Please forgive my likely stupidity (1)

DarkOx (621550) | more than 2 years ago | (#39552713)

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.

Well welcome to world IT now lives in. We have piles of s**t apps that are unmaintained, and filled with issues. We have stuff that is current that has unresolved zero days. This is just one more wrinkle but probably has a place. IPS/host IPS/ as well as various anti virus, anti malware, and isolation/sand boxing solutions have been adding a non deterministic element application debugging for a long time now. You just need lots of logs and some way to correlate them.

Re:Please forgive my likely stupidity (2)

vlm (69642) | more than 2 years ago | (#39547521)

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.

Transcript (3, Informative)

QuasiSteve (2042606) | more than 2 years ago | (#39548055)

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 can not review ten, hundred, millions of lines, and so on.
The thing is about security, that you make sure that the information will not be accessed and will not be retrieved by an unauthorized source.
A source can be a user, an application, a computer, an IP address and so on, and so on.
Regarding masking, for example, if any organization have to comply with regulation, like PCI DSS, like Sarbanes-Oxley, and so on, they have to mask sensitive information.
The most simple example is to mask credit card numbers, for example, when a CRM representative from the call center, when he's accessing the customer information, he should only see the last 4 digits.
If you have written the application yourself, and you have the time, and you have the option to go back to when you have developed it, and to add a masking algorithms and to add masking function inside your code, it will take time.
You can not be sure that the application won't be affected by other bugs as you touch it in the code.
With GreenSQL you can just decide "those 3 columns contain sensitive information and I would like to mask them with a specific masking behavior."
It takes exactly 2 seconds to configure it.
So developers, and actually it's surprising but the kind of people who pushes GreenSQL inside the organizations are the developers as well as the DBAs (Database Administrators) as well, because they can understand exactly how they can benefit from the GreenSQL solution.

[05:19] David>
Security, as you already know and everyone knows, there isn't any magic solution for security.
Security comes side-to-side, across all your IT operations.
Which means that it starts from the network and goes to the Operating System level that goes to the application level and so on, and so on.
There are few buzzwords that have been used a lot for the past few years, for example 'The Cloud'.
A lot of companies have moved to the cloud, but taking into consideration the real problems with security, there isn't any cloud security solution.
You can encrypt some of the data, you can encrypt some of the operating system, you can encrypt ...
But there isn't any solution - there are few interesting, very interesting, start-ups that working on that like PrivateCore for example, that are providing you a secured infrastructure to the cloud.
Because today, if we will take the high-level organization that are planning to move to the cloud, so they are purchasing huge cages, but eventually someone can get to this cage, and just dump the memory of the Operating System - he can get anything that he wishes.
This is a major problem that organization are not[sic] starting to understand, how we treat this.
A second major issue is mobile devices, because today, you know, the mobile devices [...]

[06:34] <TITLE>
David pulls a phone from his vest pocket.

[06:34] David>
[...] that I use, like anyone else, it's not a mobile device anymore, it's a full computer.
You can run all your business applications, you can run your own code - I actually compile some of my code on a mobile device - so you can do whatever you wish, and the problems are huge.
There's a lot of different solutions, by McAfee who purchased a company by other.. Juniper that also purchased a company.
There isn't any cover-to-cover solution to stupidity.
The problem is, and it will always be, the person who's using the computer, the device or the mobile.
But when a person is running his most sensitive information and documents on a mobile device, and at night he's just going to the market, or the app store and downloading endless number of application and he's running them, then how, exactly, can the device be secured?
The answer is, never.
For that, there are few and new interesting solution.
The third issue that I would like to raise is the problem is the information.
Even though I'm from GreenSQL, and I'm coming to protect and increase performance in databases, the problem is that eventually - and we've seen it with a lot of the 'hacktivism' process, you know Anonymous and other groups that are penetrating and the target is the information, and information is stored on the databases.p
It's not about defacement, it's not about denial-of-service anymore, it's not about anything, it's about stealing the sensitive information.
It can be your customer information, it can be any type of information that you store in your database.
Take a look at what happen in SONY.
Funny thing about [the hack at, ed.] SONY they stole 100,000,000 users' information.
What was the most common password?
Seinfeld.
Which means that most of the gamers are not 15 years old, are in their thirties *laughs*, which is just something funny that came out of the major SONY breach.

[08:32] David>
I think that eventually there is gonna be a true mobile device security solution that will provide you a separate running environment to run your secured application and secured contact information, as well as public information.
A lot of major companies like VMWare and others have started developing their own hypervisor-level to mobile devices which is just crazy regarding performance.
But I think in the next year we'll see mobile devices with 4 CPU cores, not only 2 cores, and we will see 2 or even 4 GiB of RAM.
So it will be possible to provide you a virtualized environment to your mobile device.
As long as you run your proprietary business information on one instant of virtual environment - and all the other games, music, videos and the connectivity that your kid is connecting the USB dongle to his own mobile device, will be completely separated - only then business can be, will be able to rest assured that their information is secured.

[09:33] <TITLE>
"GreenSQL: www.greensql.net" fades into view with the SlashdotTV logo bar with "David Maman - Co-Founder & CTO, GreenSQL" in the bottom of the view.

Re:Please forgive my likely stupidity (1)

Anomalyst (742352) | more than 2 years ago | (#39549803)

I don't watch videos. Transcript?

Indeed TIDW (Too illiterate, Didn't Watch), feel free to substitute idiotic as needed.

Re:Please forgive my likely stupidity (4, Insightful)

biodata (1981610) | more than 2 years ago | (#39547525)

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 (0)

Anonymous Coward | more than 2 years ago | (#39548181)

Ha, too depressingly true...

they think a good 'web designer' is someone with some kind of qualification in graphic design.

The below was actually a question from a meeting from a senior executive who just sat for 30 minutes nodding in agreement while I'm talking about database replication.

Can the link text be green?

What could possibly go wrong with Western civilization when we have management and decision makers of this calibre?

 

Re:Please forgive my likely stupidity (1)

growse (928427) | more than 2 years ago | (#39548681)

If you're talking to a senior exec about database replication, you're doing it wrong. They don't care. They just want the text link to be green, and don't understand why these crazy-haired people underneath them keep banging on about unimportant things like database replication.

Re:Please forgive my likely stupidity (1)

Johann Lau (1040920) | more than 2 years ago | (#39549435)

What good is a database that is safe and sound if nobody is looking at the data because the links aren't an inviting color, like green? There's a reason people who consider the big picture tend to be managers and whatnot.

Ahem (1)

intellitech (1912116) | more than 2 years ago | (#39548351)

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.

Re:Please forgive my likely stupidity (4, Insightful)

nahdude812 (88157) | more than 2 years ago | (#39547529)

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 (1)

buchanmilne (258619) | more than 2 years ago | (#39547565)

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.

Just make sure you have the same system running in QA, and your QA people can log a defect against the developer from dirtcheapistan.

In certain environments it is useful having a tool like this, just so you have a contractual means of penalising the outsourced development house.

Re:Please forgive my likely stupidity (-1)

Anonymous Coward | more than 2 years ago | (#39547691)

SQL injections are impossible if all user input is necessarily relegated to a bound parameter.

 

Wrong on the facts, there. You have discounted the potential for internal injection attack. Databases have functions that synthesize SQL and must sanitize and quote inputs appropriately or suffer vulnerability. The application is merely the first stop in the chain of injection attacks, but bulletproofing the app does not confer protection to the database.

Re:Please forgive my likely stupidity (3, Insightful)

Alex Belits (437) | more than 2 years ago | (#39547835)

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 (0)

Anonymous Coward | more than 2 years ago | (#39554005)

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

This is slashdot. Most users speak with authority on subjects they clearly have absolutely no concept of the things to which they speak. It didn't used to be that way. These days, most comments which are moderated +5 might be +2 or +3 years ago. And all too often, many +5 comments should actually be -1 Troll. Worse, I commonly see 0 and -1 posts which should be at +5. Ya, really. The fact is, slashdot is a shell of its former glory and most users know nothing of the subject matter, aside from what they are mindlessly parroting; without regard for any supportive facts or comments which invalidate the argument on which they predicate their parroting.

In fact, its far more likely for a factually accurate, little known post to be troll moderated than it is for a factually inaccurate, yet widely believed opinion, to be moderated up. Which is not to say either is rare by any stretch of the imagination. And the fact is, far, far too many factually inaccurate posts are moderated up these days. It happens pretty much every day and frequently, many, many times within a single article, in multiple threads.

People no longer come to slashdot to learn and exchange, they come here to get their egos stroked by reguritating the same misinformation they all generally hold - without any regard for its accuracy or correctness. Far too often, +5 moderation translates to mean, "Yep, you're as stupid as me, the moderator."

I do not believe Linux was correct about /. when he originated stated this, but he absolutely is correct today. Slashdot is an ego circle jerk.

Re:Please forgive my likely stupidity (2)

19thNervousBreakdown (768619) | more than 2 years ago | (#39548099)

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.

Re:Please forgive my likely stupidity (1)

Bert64 (520050) | more than 2 years ago | (#39547945)

The best way to ensure security, is simplicity...

Having thousands of layers of security may look good in theory, and may sell well to someone without a technical background, but ultimately the more complexity you have the more scope there is for vulnerabilities to exist.

I have seen many cases where the underlying system was ok, while the complex firewall/authentication/ids/whatever system sitting infront of it had exploitable vulnerabilities that got you onto the network.

Re:Please forgive my likely stupidity (0)

Anonymous Coward | more than 2 years ago | (#39548959)

SQL injections are impossible if all user input is necessarily relegated to a bound parameter.

It's a crucial level of security, but poorly written procs can still be vulnerable.

I've come across stored-procs that take the nice safe parameter, insert the value into the middle of a SQL string as criteria, and execute the string. Which completely bypasses the safe parameter-passing! Instant SQL injection vulnerability, even with parameters.

When pressed, the author claimed it was safe because it was inside a proc, and not app-side dynamic SQL.

Re:Please forgive my likely stupidity (1)

rollingcalf (605357) | more than 2 years ago | (#39547531)

That's correct. But when management outsources the software development to Dirtcheapistan, the programmers there often don't know or care about that. Sure, the in-house programmers should do code reviews and catch that -- but sometimes the management decides to save money by stopping the in-house programmers from doing reviews of the outsourced code, or not allocating sufficient time for proper reviews.

Re:Please forgive my likely stupidity (1)

Compaqt (1758360) | more than 2 years ago | (#39547541)

Multiple levels of security, friend. Do you want to put all your eggs in the basket of programmer competence? In addition, many popular PHP/MySQL apps don't do that, but people (you work for) want them installed anyway.

Also, another point regarding a lot of prebuilt PHP/MySQL packages: They often require DDL (data definition language) access like CREATE, DROP permissions. But that's only for initial installation.

What you "should" do is then drop those permissions and only allow SELECT, UPDATE, etc.

But I doubt anyone does that.

Re:Please forgive my likely stupidity (0)

Anonymous Coward | more than 2 years ago | (#39552653)

Update Products set name='dodo', price = 0,category = NULL,rebate100 = -1;
That's as good as "drop Products".

Re:Please forgive my likely stupidity (0)

Anonymous Coward | more than 2 years ago | (#39547545)

You run web hosting service and want to cut down support costs - your customers can not be trusted to write decent apps, but you want to secure them (because you do not really want sites start redirecting people to malware distribution because someone has managed to insert bit of javascript into article that is on homepage.)

Re:Please forgive my likely stupidity (1)

Opportunist (166417) | more than 2 years ago | (#39547643)

Yup. But now consider you have a huge webservice written by the cheapest programmers possible. What's cheaper, buying this IDS solution (which is, btw, pretty much the same as any other IDS solution I know of, so what's the news?) or having those programmers (possibly the same idiots, i.e. resulting in code that is by no means any more secure) rewrite everything?

Yes, it's not really a good solution. But it's what management wants: A box to put somewhere and we're safe.

Re:Please forgive my likely stupidity (1)

Bert64 (520050) | more than 2 years ago | (#39547985)

Only...

1, buying, configuring, managing and keeping updated the ids system is not cheap either, and it will be an ongoing cost unlike fixing your code.
2, you're not safe, it may make attacks less likely but don't fool yourself into thinking it makes you safe.
3, it adds new risk, you now have an additional system in the path which may have exploitable vulnerabilities, and may fail causing an outage.

Re:Please forgive my likely stupidity (1)

Opportunist (166417) | more than 2 years ago | (#39549869)

1. Pointless. It looks great in the quarter report, that's what counts. Reality? Doesn't matter.
You are, technically, correct. But the decision will be made by a beancounter who tries to make ends meet with this year's budget. Ongoing cost is no problem, as long as they are predictable.

2. It does not. It would maybe be a nice additional layer of security, and that way I would treat it (actually, the IDS/IPS of the systems I'm responsible for is just one layer of security, nothing more, nothing less). NOTHING you do will make you safe in all eternity. There is no such thing. The question is just one of risk management: cost vs impact times likelyhood. And in this formula it looks quite ok. Hell, considering the sorry state of many systems I've had to deal with, a lock on the server room would be an incredible increase of security.

3. True (you were at my speech in January? :)). There's little I could field against this argument, mostly because it's usually my argument. Of course the system has to be evaluated and tested for its cost/risk/benefit balance.

What it comes down to is, when you've spent a lot of time going from company to company and system to system, you start being happy if there's at least ANY kind of security in place. This isn't going to be the be-all, end-all silver bullet black box the managements of this planet dream of. What they really want is something that they buy, put in a corner and then never have to deal with it again. Even if that costs a lot of money annually, as long as it promises them that they won't have to deal with those sticky "security things", they will buy it.

It's very hard to talk them out of believing that such a solution exists. What makes this box attractive is that it's getting close to that dream box. Is it perfect? No. Is it absolutely secure? Hell no. But it's better than the current situation in most companies, which is crappy code with huge security holes and no such box.

Re:Please forgive my likely stupidity (1)

Bert64 (520050) | more than 2 years ago | (#39552363)

What it comes down to is, when you've spent a lot of time going from company to company and system to system, you start being happy if there's at least ANY kind of security in place.

Sounds like you do a similar job to me...

You hit the nail on the head, most organisations have horrendously poor security, and those few that try to do anything about it whatsoever generally take a complete sub-optimal approach, driven by entirely non technical people who believe marketing propaganda and salesmen rather than get proper unbiased competent advice.

Security is generally seen as a cost until something bad happens, and only then does it become important...

The problem however, is that no matter how flawed most of these places security is, so long as they don't have worm-targeted holes exposed to the internet chances are noone will ever expend any effort to attack them.. So although their systems are deeply flawed, they often wont get compromised and assume that this means there secure, and not that there's simply no motivation for anyone yet.

Re:Please forgive my likely stupidity (2)

jellomizer (103300) | more than 2 years ago | (#39547667)

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 (0)

arglebargle_xiv (2212710) | more than 2 years ago | (#39547961)

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

Not only is the problem not solved (see other comments above), but you often don't even know you're running an SQL database as part of some other app. For example I recently noticed that my dad's computer was running two full-blown SQL database servers,one (Firebird) was included in some crappy photo-editing program he was using and another (SQL Server Express) was part of something that I never managed to track down. So without even knowing it he was running at least two full SQL database engines, as well as a cut-down embedded one, SQLite,all without ever consciously doing anything that you'd think would involve databases. Holy fsck, he uses his computer to send email, order crap off ebay, and create photo slideshows, and it's running at least three SQL database engines! So you may be vulnerable to this problem, in multiple forms, without even knowing about it.

Re:Please forgive my likely stupidity (1)

Unordained (262962) | more than 2 years ago | (#39549207)

OT: Firebird can be run in 'embedded' mode, much like SQLLite, where the app that uses it loads a DLL that is the entire engine for its own use, but without listening on any sockets when running, and without running all the time (as a service.) That's generally the preferred way to deploy Firebird for single-user desktop apps; it can be "upgraded" to multi-user by swapping out a different client DLL and running a server instance, if that becomes necessary -- or, in your case, the other way around. It's unfortunate that the designers of the app in question weren't more careful.

Re:Please forgive my likely stupidity (0)

ArsenneLupin (766289) | more than 2 years ago | (#39548489)

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,

Well support you need to sort columns according to a variable criteria.

sort firstname,lastname,birthdate from user sort by ?
doesn't unfortunately work. So in that case you'd still need to use string concatenation to get the column name into the statement. So this needs to be sanitized/compared to a list of known-good values if it comes from a web from.

Re:Please forgive my likely stupidity (1)

Johann Lau (1040920) | more than 2 years ago | (#39549809)

That's right... "Don't trust user input". 4 simple words, and if you follow them, many problems disappear. If you don't, I doubt a DB firewall will help much.

Re:Please forgive my likely stupidity (1)

Anrego (830717) | more than 2 years ago | (#39550187)

Mm, good point.

I like to think if I came upon that problem a red flag would go off in my brain saying "ok, we need to do something here" .. but I can definitely see something like that getting missed and some programmer just pounding the data in there directly.

Re:Please forgive my likely stupidity (1)

Threni (635302) | more than 2 years ago | (#39549073)

> isnâ(TM)t the whole SQL injection problem pretty much solved by using prepared statements
> to decouple data from the query?

Yes, if your developers aren't incompetent muppets.

You see the problem, right?

Performance vs. security (1)

Jay L (74152) | more than 2 years ago | (#39554909)

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.

Re:Please forgive my likely stupidity (0)

Anonymous Coward | more than 2 years ago | (#39555307)

1) You would be surprised how much software in the open source and closed source community still does not use prepared statements with parameters. As a DBA in charge of Oracle and SQL Server databases it is painful to watch our developers continue to maintain code and copy/paste bad ASP code and to install products by security oriented vendors, ERP, and DMS applications that do not use statements with parameters.

2) Many vendor packages provide some type of ad-hoc query capability and if the RDBMS does not have adequate built-in auditing then a database firewall could be of benefit to individuals looking at data they should not be able to look at.

Don't miss this important message! (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39547475)

'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! (0)

Pieroxy (222434) | more than 2 years ago | (#39547587)

'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 No More Mod Points

The oly thing I don't know is if I should advocate for you to get a +1 Funny or +1 Insightful

Re:Don't miss this important message! (0)

OzPeter (195038) | more than 2 years ago | (#39547589)

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

Re:Don't miss this important message! (4, Funny)

Anonymous Coward | more than 2 years ago | (#39547891)

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

Re:Don't miss this important message! (1)

Anonymous Coward | more than 2 years ago | (#39548737)

Sad news for you. For a couple of years now, most of the best comments come from ACs these days. Many more have been censored by the ignorant masses who simply have no clue about the subject matter yet pretend them do.

The fact is, every day I find factually wrong or just horribly inaccurate comments rated +5 on /. which should honestly be at 0 or -1. EVERY DAY.

Re:Don't miss this important message! (1)

Anonymous Coward | more than 2 years ago | (#39550149)

Oh, so you mean like slashdot has always been right from the start? I've been here since late 97. Anonymous comments have always been insightful and informative, frequently more so than logged in commenters who insist on reposting retarded soviet russia style crap that was never funny.

It's the code, stupid! (1)

jimmifett (2434568) | more than 2 years ago | (#39547481)

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

Re:It's the code, stupid! (1)

Lord_Byron (13168) | more than 2 years ago | (#39550913)

Lots of people fail at preventing SQL Injection. Lots of people who really ought to know better: http://web.nvd.nist.gov/view/vuln/search-results?query=SQL+Injection&search_type=all&cves=on [nist.gov]

This isn't magic, and it's no replacement for a good secure software development program, but it's a fair bit better than nothing.

Am I the first to think... (2)

HyperQuantum (1032422) | more than 2 years ago | (#39547499)

Soylent GreenSQL?

Re:Am I the first to think... (2)

Whalou (721698) | more than 2 years ago | (#39547535)

Am I the first to think Soylent GreenSQL?

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

Congratulations!

Re:Am I the first to think... (0)

Anonymous Coward | more than 2 years ago | (#39548719)

More likely others thought about it but didn't post about it because it's neither interesting nor funny.

Encouraging (1)

DustPuppySnr (899790) | more than 2 years ago | (#39547523)

And by encouraging, I mean, encouraging devs everywhere to write even more sloppy code.

Re:Encouraging (2)

jellomizer (103300) | more than 2 years ago | (#39547715)

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.

Input sanitization ? Use statement preparation (2)

bytesex (112972) | more than 2 years ago | (#39547549)

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.

Re:Input sanitization ? Use statement preparation (1)

Bert64 (520050) | more than 2 years ago | (#39548177)

PHP has pretty good prepared statement support, at least for postgres... I use it quite heavily.

Re:Input sanitization ? Use statement preparation (0)

Anonymous Coward | more than 2 years ago | (#39550775)

Look up PDO - the support is there for MySQL as well

PDO (0)

Anonymous Coward | more than 2 years ago | (#39554435)

1998 called, they want their troll back. It's called PDO [php.net] , its been part of the core since 5.1 (released 7 years ago) is easier to use than any of the dated SQL functions.

Just fix it (1)

Curunir_wolf (588405) | more than 2 years ago | (#39547583)

Wouldn't it be easier just to fix your goddamn code?

Re:Just fix it (1)

horza (87255) | more than 2 years ago | (#39548819)

I don't think people that write code are the target audience. I'm not going to bother watching the video, but I presume it's aimed at ISPs. The price would presumably be pitched at a price which would be competitive to not having to deal with all the "I've been hacked" support calls from customers. They would then have a "SQL injection protection" tick they can put on their front page, and icon on their control panel users can activate.

Phillip.

Green? (0)

Anonymous Coward | more than 2 years ago | (#39547623)

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.

meaningless as "the cloud" or "web 2.0" (1)

rubycodez (864176) | more than 2 years ago | (#39547967)

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

Re:meaningless as "the cloud" or "web 2.0" (0)

Anonymous Coward | more than 2 years ago | (#39548179)

I named it after my grandfather, a legendary database security analyst named "Siud Green", you insensitive clod.

Database Developer here (0, Informative)

Anonymous Coward | more than 2 years ago | (#39547635)

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.

Re:Database Developer here (1)

Bert64 (520050) | more than 2 years ago | (#39548209)

And an SQL firewall is at best a "partial solution"... The problem is that it will be marketed to non technical people as "the ultimate solution to all database vulnerabilities", and they will lap it up.

I like it and I hate it (3, Insightful)

erroneus (253617) | more than 2 years ago | (#39547655)

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 (2)

Bert64 (520050) | more than 2 years ago | (#39548227)

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.

What if. (1)

thePowerOfGrayskull (905905) | more than 2 years ago | (#39547689)

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 ;)

Re:What if. (2)

Anomalyst (742352) | more than 2 years ago | (#39549897)

ripe for plucking ;)

Feathered data, what a concept!

Re:What if. (1)

thePowerOfGrayskull (905905) | more than 2 years ago | (#39553399)

I was going for fruity data...

Re:What if. (1)

Anomalyst (742352) | more than 2 years ago | (#39553933)

I was going for fruity data...

That can be the pits.

Why not... (0)

Anonymous Coward | more than 2 years ago | (#39547877)

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

Hurray for Slashdot! (0)

Anonymous Coward | more than 2 years ago | (#39547893)

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

You need to have the Adobe Flash Player to view this content.
Please click here to continue.

On second thought, forget the hurray.

First JpKost (-1)

Anonymous Coward | more than 2 years ago | (#39547903)

Downsides (4, Insightful)

biodata (1981610) | more than 2 years ago | (#39547925)

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.

Yo! (0)

Anonymous Coward | more than 2 years ago | (#39548011)

I put a SQL in front of your SQL so you can SQL while you SQL...

library instead (1)

hey (83763) | more than 2 years ago | (#39548025)

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.

Re:library instead (1)

Shoten (260439) | more than 2 years ago | (#39549367)

No administrative commands? You mean "SELECT", as is used in most injection attacks? THAT administrative command?

Look, there's a reason that everyone in the application security space says to whitelist when you sanitize your inputs, rather than blacklist. There are too many ways to slip things past a blacklist which are often defined by the nature of the application rather than the COTS and OSS software used to architect it. No library call is going to effectively stop "bad stuff." If you have authentication credentials in your DB (hint: you do) and I can inject SQL into the query that is passed to it, I can get those credentials, without using any SQL calls that aren't used in a very innocuous and mundane request for data. And most of the time, I can use those credentials directly, in the same manner as the person who is intended to use them. And this is just one example...one single example...of one kind of injection attack. (It's also one of the most common ones.)

Whole lotta pompous attitude all up in here (-1, Troll)

goodmanj (234846) | more than 2 years ago | (#39548095)

"You don't need this. Just write SQL that doesn't suck."

Not everyone is a billion-dollar corporation that can hire you to write their website. There are millions of websites in the world run by people who use prebuilt web service packages on LAMP servers. These are bakeries, car dealerships, WoW guilds, churches, with volunteers they don't have the time or money to rewrite WordPress from the ground up, and their prebuilt software gets hit by SQL injection attacks on the regular.

If you feel they should either hire a full-time SQL expert, stick to Facebook, or get the hell off the Internet, then you don't have a clue what the Internet is about.

Apparently not an anti-ddos tool (1)

Karl Cocknozzle (514413) | more than 2 years ago | (#39548155)

...as they are slashdotted into next Tuesday.

GreenSQL vs mod_security (1)

gridzilla (778890) | more than 2 years ago | (#39548271)

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.

Forgive My Potential Ignorance but... (1)

rsmith84 (2540216) | more than 2 years ago | (#39548485)

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?

Yes let's add another layer... (1)

holophrastic (221104) | more than 2 years ago | (#39548653)

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.

Paid editorial (0)

Anonymous Coward | more than 2 years ago | (#39548881)

Aren't there moderators to filter out spam like this?

Performance concerns... (3)

Shoten (260439) | more than 2 years ago | (#39549317)

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.

Is it webscale? (1)

Hognoxious (631665) | more than 2 years ago | (#39550305)

MongoDB is.

No thanks. (1)

petteyg359 (1847514) | more than 2 years ago | (#39550349)

I'll just sanitize my SQL inside my application, rather than purchasing some totally unneeded shit solution looking for a problem.

SQL injection is not the only way in (0)

Anonymous Coward | more than 2 years ago | (#39554117)

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

Does MySQL not allow account privilege control? (1)

PJ6 (1151747) | more than 2 years ago | (#39555863)

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

Get used to it. It and it's like are here to stay. (1)

SoupIsGood Food (1179) | more than 2 years ago | (#39556215)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...