Feeds

back to article Signatures no good at protecting databases, says Juniper

One of the most common forms of attack is the SQL injection, and although the vector is ancient and well-understood, it's notoriously difficult to defend against. Kevin Kennedy, senior director of product management for Juniper Networks' security business unit, is in Australia to demonstrate Juniper's latest shot at defeating …

COMMENTS

This topic is closed for new posts.
Bronze badge

Really?

Is SQL injection really still a problem? Any half-baked coder knows to use parameterized queries. What's more, their proposed solution sounds ridiculously complex.

5
1

Re: Really?

I'm also interested to know if this is still a problem. And on what databases?

The proposed solution does sound complex but I guess it could be turned to different things too, such as an attacker sniffing for scripts that might allow directory traversal.

As the author notes though, this would only keep the skiddies out. Any attacker that knows their stuff will be hopping IP and blocking all cookies of any sort.

0
0
FAIL

Re: Really?

If I was still building database applications I would personally still prefer to use some form of stored procedures, with parameter inputs that don't use the names of fields or tables in the database. It really should be obvious to any database application engineer today that the engine of any database system (SQL or otherwise) should never be exposed to the wider world, and the names of any database's objects shouldn't be either.

7
0

Re: Really?

Also the article notes that the attacker may be looking for vendor specific error messages.

Anyone that pumps the actual output of errors to the wide world should be considered foolish.

0
0
Anonymous Coward

Re: Really?

"Any half-baked coder knows to use parameterized queries"

Yes - and they don't write code with bugs in either.

And all code is less than 5 years old. And all code is written by people who care. And all code is written by at least half-baked coder.

0
0
Anonymous Coward

Re: Really?

"on what databases?" What? This is a coding issue not a database issue.

0
0
Bronze badge

Re: Any half-baked coder knows to use parameterized queries

Some college courses (I'm looking at you, Glasgow Uni) were still teaching embedded input SQL as of 2012 with only cursory caution to the students, who are then turfed into the wild and often subsequently find themselves writing their first real code for small start-ups where there is no one else there who knows better.

This can be a recipe for much comedic japery when it comes to database design.

0
0

Re: Really?

The trouble is that there’s still a lot of code developed by third parties who have yet to get the message.

DreamWeaver generates PHP code that is notoriously convoluted and doesn’t used prepared statements. I’m not sure, but I have the feeling that PHPMyAdmin does things the Old School Way. WordPress seems to be OK, but I don’t know how many other popular CMS packages use them.

Of course, people who rely on off-the-shelf packages are not always best placed to implement a sophisticated defense such as is described. Still, slowing down and misleading attackers is not a bad thing.

0
0
Anonymous Coward

Re: Any half-baked coder knows to use parameterized queries

> This can be a recipe for much comedic japery when it comes to database design.

http://xkcd.com/327/

0
0
Bronze badge

Re: Really?

Yes - and they don't write code with bugs in either. And all code is less than 5 years old. And all code is written by people who care. And all code is written by at least half-baked coder.

It's true that relying on developer competence is a poor way to improve security.

In this specific case, though, it's not terribly difficult to enforce good practice. Restrict permissions on the database accounts used by applications so they can only execute stored procedures, not perform any queries directly. Yes, that will break old code; but it doesn't rely on developer vigilance.

0
0
Anonymous Coward

Well, I think that programmers can protect against SQL injection, in all cases. With a combination of libraries that escape the data correctly (such libs have existed for years and are rock solid at preventing DB level injection) and proper input validation/sanity checks on all user supplied data. Sure its possible to slip up, but if your developers understand the risks and what not to do they can work inside those parameters.

As for 'super cookies'.. not all live CDs need to have no write access. Theres these things calls virtual machines which can be rolled back to a snapshot.

But I guess these products will still sell, some people cant have enough protection.

2
0
Bronze badge

With a combination of libraries that escape the data correctly (such libs have existed for years and are rock solid at preventing DB level injection) and proper input validation/sanity checks on all user supplied data.

Fragile and unnecessary. As other contributors have already noted, you're far better off with restricting applications to parameterized operations (stored procedures). Even better, combine that with a proper DAL (data access layer) and/or ORM (object-relational model) - business logic and the UI layer shouldn't know anything about how the data storage works. That should be a black box to them, accessed via a minimum-privilege API. It shouldn't matter if the UI/business layers throw garbage at the data-access layer.

0
0

Another technique

Once attackers have been identified, redirect all traffic from them to a second server, full of good-looking but fake data. The intention is to make them waste time attacking the fake server, and even let them think they've succeeded, while preventing them from accessing the real database.

0
0

Re: Another technique

The tricky bit is avoiding false positives -- read: pissed-off customers.

2
0

Re: Another technique

I'll be sure to call you up to administer that second parallel system, then, because I don't know anyone else who would. Using the test/dev system has its own security implications.

I'd just redirect them to a trollface.

0
0
Silver badge

Super Cookie

Rather than watching for something easily changed, like the IP address, the system is now looking for the fingerprint of the super-cookie, and acting accordingly.

Eh? Surely the mere presence of the supercookie and a unique associated ID is sufficient to recognise the machine. IE what's the purpose of the fingerprinting?

0
0
Silver badge

Re: Super Cookie

IE what's the purpose of the fingerprinting?

You can sell your fingerprinting technology as a must have security service to techno-illerate managers, and create your very own profitable niche market.

0
0
Silver badge

Re: Super Cookie

Ah, of course. I was begining to wonder if my brain had seized.

0
0
Silver badge

So with this recognition and super-cookie technology you can definitely recognise one of the hundreds of zombie machines that the attacker is using?

1
0
FAIL

How can this still be a problem?!?!?!

Too easy not to get caught out by this problem!!

A simple way around this is check all parameters at the start for banned items like <script and replace them with something harmless. Personally, I replace hacking attempts with the word "cheeseburgers".

Took 30 seconds for global back-end protection from XSS & SQL injection in one project.

1
0

Re: How can this still be a problem?!?!?!

Yup, it's the silently zeroing out invalid data that allows attackers to layer it up into a real attack. Better to replace them with placeholders.

But this isn't about XSS, and you can't exactly ban real words like "SELECT" from most text input fields.

0
0
Bronze badge

Re: How can this still be a problem?!?!?!

A simple way around this is check all parameters at the start for banned items

Sure, because blacklisting has no failure modes.

Ah, the security "solutions" invented by non-experts. Always entertaining.

0
0
Bronze badge

Further Protection

As well as validated & parameterised inputs, I have also assigned the login used by the application the public role and assigned its user explicit rights to every stored procedure.

So even if an SQL Injection were to be successful, the attacker can do little more than execute specific SPs, which while not actually a good thing, is better than assigning the application user dbowner rights and allowing the potential dropping of tables and so forth.

0
0
Bronze badge
Childcatcher

Distribution

Am I wrong in assuming that performing a distributed attack rather than running this from the attackers own machine would get around most of the detection offered by this, if not the actual protection? I know that some idiots use their actual home computers for attacks and that there are non-trivial number of idiots out there, but it seems this is picking low-hanging fruit at most.

0
0
FAIL

It depresses me that IT gets excited over an absurdly complex solution to an embarrassingly simple problem. It's like a fast food manager discovering that his employees aren't washing their hands after the bathroom, and instead of training them on proper procedures, he injects powerful antibacterial chemicals into all the food. Or something.

The problem is caused by connecting two languages (a frontend and a database) to each other using a ridiculous string parsing layer. The entire IT industry has accepted this as OK, why exactly?

0
0
Anonymous Coward

Super Cookies - Other online banks using these unwisely?

"the browser, the installed fonts, timezone, screen resolution, pointer device, camera type and so on – the system can capture a fingerprint of the attacking machine"...

Super-cookies are being abused by non-attackers as well IMHO. I'm trying in vain to get my bank, one of the USA's largest, to stop using Super Cookies. Its the only explanation I have for how their 2-factor authentication challenge question and answer is being continuously cached. I am ensuring all cached sessions / Etags, cookies, flash cookies, temp files are being purged after every login....

1
0
This topic is closed for new posts.