SQL injection attacks

Posted Mar 30, 2006 2:28 UTC (Thu) by jwb (guest, #15467)
Parent article: SQL injection attacks

Another great article. One of the many horrors of MS-SQL is the incredible amount of functionality
available to a SQL injection attacker. MS-SQL can be made to open a connection to any other
database, even on other hosts or networks. A SQL injection attack against MS-SQL can allow the
attacker to tell your database to connect to any random instance of SQL Server and replicate itself.
This obviously takes all the guesswork out of trying to reverse engineer the schema. An attacker
can rip off an entire MS-SQL instance with a single HTTP request.

to post comments

Guess work?

Posted Mar 30, 2006 23:49 UTC (Thu) by GreyWizard (guest, #1026) [Link] (8 responses)

s/guess work/security through obscurity/

Database features do not excuse sloppy applications.

Guess work?

Posted Mar 31, 2006 6:39 UTC (Fri) by hppnq (guest, #14462) [Link] (7 responses)

Basically, you are suggesting that in order to kill a fly, you should use a proper gun, practice at a firing range, isolate the fly in a safe environment, surgically optimize your eye-hand coordination, calculate environmental influences, suppress urges to start shooting at random, before taking a shot at removing the annoying intruder.

Sure, if a gun is my only tool, I'd go through all that. But I'd rather whack the bastard with a newspaper.

Nonsense

Posted Mar 31, 2006 15:07 UTC (Fri) by GreyWizard (guest, #1026) [Link] (6 responses)

That is a perfectly ridiculous analogy. Whining that the database has too many features that might be useful for someone exploiting SQL injection vulnerabilities in an unrelated application is not so much swatting the fly as cursing the publisher for printing a newspaper that's too hard to swing while the thing is still buzzing around your head.

Nonsense

Posted Mar 31, 2006 15:36 UTC (Fri) by hppnq (guest, #14462) [Link] (5 responses)

So what are you suggesting then? That we should all write perfect code? Yes, that would solve the problem. Is it realistic? Not a chance in hell.

Most or all security implementations heavily depend on defining proper interfaces to resources and making sure that access to resources is only possible through these interfaces.

It follows quite simply that it's wise to start off with as little resources and interfaces as possible if you care about security.

RTFA

Posted Mar 31, 2006 22:17 UTC (Fri) by GreyWizard (guest, #1026) [Link] (4 responses)

Contrary to your raving, filtering user input does not require perfect code. I suggest reading the article to which this thread is attached. There you will find suggestions such as using prepared statements or stored procedures. As stated above, "SQL injections [...] can be thwarted relatively easily once one understands the problem and the ways to program around it." On the other hand, no database can provide protection from gaping security holes in external applications.

Mmmmhh

Posted Apr 1, 2006 8:53 UTC (Sat) by hppnq (guest, #14462) [Link] (3 responses)

It seems to me that we are making a lot of fuss about something that we basically feel the same about. If you take the time to calm down and read the comments as well as the article you might see this too.

Now, you were the one that brought up the topics of sloppy programming and "security through obscurity", taking this discussion explicitly to the realm of the real world, where the perfect solution does not exist. You observed that database features are no excuse for bad programming, while I am of the opinion that they should not be an excuse.

In the real world resources are limited. At some point a decision will have to be made: is it good enough? Since security means nothing in the laboratory, and everything in the real world, this is a very important observation. This is also why I mention writing perfect code: it cannot be done, and the only way to avoid having to make suboptimal decisions is to remove the necessity of making those decisions. This is a classic trade-off between security and functionality.

Instead of having to protect features one does not need, it is better to not have them available in the first place. That of course leaves more resources available to get the actual job done: defining the correct interfaces to the functionality you want to provide or use and protecting those interfaces properly.

On the other hand, no database can provide protection from gaping security holes in external applications.

This is the same problem. Do take some time to think about it.

Practice What You Preach

Posted Apr 3, 2006 15:50 UTC (Mon) by GreyWizard (guest, #1026) [Link] (2 responses)

You reply to a comment about security through obscurity with an irrelevant analogy to shooting mosquitoes, and now you accuse me of not reading what I reply to? You rant and rave about the impossibility of perfect code, and now you tell me to calm down? Amusing. But your airy hand waving about "protecting features one doesn't need" still misses the point: using the dumbest database available would be a trade-off between security and functionality only if this were an effective substitute for plugging SQL injection holes in the application. As long as there are remote exploits the application cannot meet even the least demanding security requirements with any database.

This is really not so complicated. Practice what you preach, especially with regard to taking the time to think about it.

Practice What You Preach

Posted Apr 3, 2006 22:19 UTC (Mon) by hppnq (guest, #14462) [Link] (1 responses)

Well, I just tried to add some more perspective to your rather simplistic "thou shalt not program sloppily" statement. It appears to me that in your enthusiasm to slight me, you seem to miss your own point completely.

*plonk*

Perspective Indeed

Posted Apr 4, 2006 2:58 UTC (Tue) by GreyWizard (guest, #1026) [Link]

You are confused. "Database features do not excuse sloppy applications" is simple. "Thou shalt not program sloppily" is simplistic. The latter is your contribution, not mine. Rambling about mosquitoes, whining about perfect code, splitting hairs over "are" and "should" and pretending I don't understand my own point is your idea of adding perspective, is it? Spare me such generosity.

SQL injection attacks

Posted Mar 31, 2006 11:06 UTC (Fri) by pdc (guest, #1353) [Link] (1 responses)

To try to avoid this we do all access from a web app to the SQL Server database via stored procedures, with user input passed as parameters. At least then you can reastrict the privileges of the web application to just the procedures it needs to use. Makes the database development rather tedious, however.

SQL injection attacks

Posted Mar 31, 2006 19:20 UTC (Fri) by dwkunkel (guest, #5999) [Link]

I use Oracle stored procedures to simplify my web applications. All the business logic is handled by stored procedures and there is no sql in the web pages. The pages just pass parameters to the appropriate stored procedure.

An Oracle stored procedure can return multiple reference cursors that can be cast to Java ResultSets and used directly in a web page. The reference cursors can also be converted to Cached RowSets and used in Data Transfer Objects. Performance is quite good because everything is done in a single trip to the database.

I don't know about SQL Server, but I find Oracle's PL/SQL to be an easy to use programming language that makes it relatively simple to produce very readable code.