RTFA

Posted Mar 31, 2006 22:17 UTC (Fri) by GreyWizard (guest, #1026)
In reply to: Nonsense by hppnq
Parent article: SQL injection attacks

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.

to post comments

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.