Feeds

back to article Next-gen SQL injection opens server door

A vulnerability estimated to affect more than 1 in 10 websites could go lethal with the finding that it can be used to reliably take complete control of the site's underlying server. Research to be presented at the Black Hat security conference in Amsterdam later this month will show how so-called SQL injection attacks open the …

COMMENTS

This topic is closed for new posts.
Bronze badge
Boffin

Short shrift to software engineering

When things like this pop up, it amazes me that the concept of engineering software is given such short shrift. I recently worked with a developer in a senior position who claimed that engineering software never worked. Of course, he never tried. There are boundless horror stories about control software physically hurting people. Yet the concept of screwing around and messing with this and that is enshrined, as Agile is holy.

I'll just have to continue to be a blasphemer.

Agile is development by schizophrenic random approximation.

0
0
Paris Hilton

Hiltonian mechanics

But what does all of this have to do with Paris Hilton?

0
0
Bronze badge

um... apostrophe?

Whatever way I parse that headline, it maek no sense.

0
0

Last time I checked

All these problems, and all, or at least some of, the other ones, had something to do with 'Buffer OverFlow Twaddles'. That was back in 18xx.

Being silly I would have thought that the people providing software that lets people provide services that might be exposed to overflowing things would have arranged for the provided software to stop such things happening in the first place.

Mind you...... Lah Lah Lah Lah Lah.

It's all above my head.

0
0
Bronze badge
Alert

Stop it, please!

SQL-Injection can happen to any DB for flips sake! All you need is a muppet with no understanding of the SQLI concept writing frontends with no sanity checks, backing directly onto any DB that accepts SQL, which is almost every DB these days!

I would hazard a guess that the 1/10 figure is probably a lot higher, given the pace at which companies expect developers to code apps these days!

0
0

Not just 'search boxes and fields'

Don't forget other ways of using GET and POST requests to a server (EG Manually) lots of people think that if they protect the 'forms' on their website, they're invulnerable.

There's also cookies, which if used without care can be a nice vector for attack.. and even persistant data, if you're reading from a database that's written to by other, untrusted (or just badly written, including your own!) applications, that can be used to inject too.

0
0
Silver badge

@Camilla

A fair point. For such attacks to succeed, it requires inadequate input validation at two points: the web interface (allowing XSS and SQL injection attacks) and the underlying DB software (allowing buffer overflow attacks). So, you have two choices to prevent them;

a) wait for Microsoft, Oracle, MySQL etc to produce a database server guaranteed free of buffer overflow vulnerabilities (might be a long wait, and you'd still be vulnerable to XSS); or

b) proper validation of web input strings.

The latter looks more attractive to me given that:

1. It isn't too technically demanding (the most popular web servers provide tools to help, although they aren't 100% effective).

2. It doesn't require a huge effort (given reasonably documented and structured code, admittedly not a very likely contingency :).

3. It protects against XSS as well as SQL injection.

0
0
Anonymous Coward

Trivial to do, trivial to fix

Validate your input, parameterise your queries, limit specific permissions for specific functionality.

SQL injection has been well understood for a very long time, there's absolutely no excuse for a professional outfit to still have these holes in their systems.

0
0
Anonymous Coward

@Brian Miller

Agile does not preclude engineering. You might want to read up on the subject a bit before commenting on it.

0
0
Flame

I call fud.

The fact that you can use SQL injection techniques to attack the DB as well as the data is nothing new.

Any "opening" can then be used to carry out all the possible attacks at the next layer. The fact that you can get a shell instead of pulling out credit card details is like saying that someone coming out with a new car that's purple instead of red is doing something new...

0
0
Anonymous Coward

SQL injection is easy to stop

It only works because idiots won't add a few lines of code to scrub their input clean.

Serves them right.

0
0

begin of fix

As a webmaster, sql and the millions of other attacks are a right annoyance to say the least.

Its true its impossible to stop them, but you can build sites that wont make it easy.

For example if a user enters something, such as a real name we know people dont have 200 character names, so say 15 characters for a first name and 17 characters for a double barrel second name usually is enough. Maxchars = 15. that gives them 15 characters on a form post to use, but there not likely to use your form, so repeat it on the processing page, limit the post characters to 15 as well. do the same for every type of input.

That works for simple single entry items, but exploits can be very small '0=0 so you need to render those useless as well, so where available you use magic quotes and stripslashes and addslashes etc.

Then theres text that users can enter, that needs to be handled and turned into nothing more than a comment, and weblinks shouldnt be allowed in there, you overlay those afterwards by using a whitelist NOT a blacklist.

So then a user entering data on the forn, or sending data direct to the processing page has less options, and thats STILL NOT SECURE.

You then need to code the page so it understands the data its being fed, so if an attempt is made to try and trip up the page or overflow the page the code itself will reject the stream. And even that code needs to be secure so itself cant be used for the attack, some windows attacks use the very protection to initiate it.

The rest is damage limitation, for example banks use ssl for a reason, and even then they have been hacked too, so no matter what you do someone will given enough time find a way round it, but when people find exploits, why dont other groups form together to counter them?

im sure a group of dedicated people, could create classes in all languages that would prevent much of this occuring for others to learn from, but then you get arrested and put in jail under uk law - because you "made available information" by accident as well that can be used for bad things.

A webmasters life is a boring thankless one which is a constant battle. And its why i dont like these people who create new and exotic methods to really mess up my day.

0
0
Flame

@Brian Miller

Hmm. Interesting that you seem to not understand Agile at all.

Are you recommending that instead we use waterfall models with full Engineering type timescales?

Wouldn't this mean that the system you eventually deploy is based on a design which in itself is based on the security needs of an internet landscape already out of date?

Just curious.

0
0
Anonymous Coward

@Graham Wood

Actually this is new, if it's as advertised. Currently an SQLI attack might open up unlimited queries on the web facing database, but if that web facing database doesn't contain the data the attacker wants - and it damn well shouldn't - then the DB environment is effectively a sandbox. Another breach is required to get at the sensitive stuff.

At the moment there are no known ways to break out of, say, MySQL. It was designed to prevent that - xp_cmdshell is a Microsoft 'feature' that other DB designers didn't copy. The best the attacker can hope for is to be able to use the DB to write out a file into the web server's documents area, and if the admin has tightened permissions to ensure that's not possible then there's no way out.

The article suggests the researcher has found a way to break out of that MySQL sandbox and expose the rest of the system - local files, networks, other databases. As a security consultant I can't wait to hear about it.

0
0
Silver badge

Important, yes but isn't this somewhat old hat?

Does this cover any new forms of SQL injection, ie. are parameterised queries susceptible? Parameterised queries have the not inconsiderable advantage of delegating the checking and quoting to the database driver. This replaces n different and incomplete application level checks. It is possible that this allows attackers to concentrate on the database's quoting routines in the hope of finding a one-size-fits-all exploit, but it also makes testing and fixing this single vector easier and also the responsibility of the database manufacturer.

I seem to remember a fix to PostgreSQL's quote function a couple of years ago but haven't come across anything since.

Never "SELECT .... " + some_variable_from_the_web "...."

Possibly "SELECT ..." + homegrown_quoting_function(variable) + "..."

Better "SELECT ..." + db_quoting_function(variable) + "..."

or "SELECT ...?...." (variable, )

0
0

Next Gen???

Really???? This kind of attack is far from new. Jesper Johansson, formerly of Microsoft, used to show exactly how SQL Injection attacks could be used to exploit the underlying OS. I saw him demonstrate this 4 years ago and I'm sure it wasn't new then....

0
0
Anonymous Coward

It's a new way of exploiting SQLI

No, SQL injection isn't new. This doesn't open up any new forms of SQLI vulnerabilites. What it opens up is what can be done when an existing SQLI is exploited.

Microsoft based servers have always been susceptible to this because SQL Server can run shell commands (this 'feature' now defaults off I believe). More sensible database servers don't allow that, and as long as permissions have been set correctly on the filesystem then exploiting the underlying OS from within the DB is hard, bordering on impossible.

Or not, apparently. My guess is it's clever shenanigans with system files that are normally publicly readable and writable, like /proc or something.

0
0

@Damien Thorn

Or you could just bind your variables and not have to worry about it. Of course that would mean hiring someone who knows what they are doing. Not popular in this day and age.

0
0
Stop

a likely story

Yeah, this is hardly new, and I seriously doubt the 1 in 10 and the $3b - $8b price tag for fixing it. Even PHP turns off magic and has bound parameters for database statements these days

In summary, sensationalist claptrap

0
0
Linux

YAWN

SQL Injections are nothing new. lIke has been said before. Also buffer overflow and allsorts of extra nasties arnt either.

1 in 10 websites are vulnerable. Is a strong statment. Just from my usual daily google dorking for sql vuln websites i dont see that many (The UK seem to have even less lol)

But its not hard to filter input to protect form XSS and sql. Even a basic coder can find info online

0
0
Flame

Incredible that this still occurs ...

A developer who doesn't use parameterised queries for all SQL calls (which should also be in their own DAO away from the view handling classes) deserves to be fired and work in fast food preparation for the rest of their lives.

It's like "SQL Injection 101: Use parameterised queries". It's not 1998 anymore. Not only do parameterised queries make your code look cleaner and neater, they're safer too! Even if you're building an SQL string dynamically, you can still be building a parameterised query, it's just a little more work. User data should never be getting into an SQL string by design. Software that still does it is faulty by ineptitude and laziness. I can only thank database abstractions like Hibernate and LINQ for hiding SQL from these cheap-ass developers.

Now bugs in the database software itself is another issue. I thought that this article was going to be about an attack that wriggles its way past parameterised queries, but it appears not.

0
0

This article is a bit irresponsible

"SQL Injection" isn't what happens when you don't validate your input. It's what happens when you use a way of talking to your database that requires validating your input in the first place!

Like many of the commenters have suggested, using parameterized queries / bound variables, or whatever you want to call it.

Validating your input is for preserving the sanity of your data, _NOT_ for preventing injection attacks. Optionally, you might quote/validate input that you know is only going to be output in one format (say, text in a web page) to save you doing output validation (but I prefer to escape html entities on output and leave my data "pure")

0
0
This topic is closed for new posts.