March 19, 2009 at 12:33 pm
I like Charles's list as well and am kind of an extremist too. The solution to solving SQL Injection attacks is simply for every RDBMS system to flat out not allow inline SQL. Everything must be done with stored procedures and parameters.
I first heard about SQL Injection back in like 1997 or 1998. It amazes me how big of a topic it still is today and how many problems it still causes. Ridiculous!
March 19, 2009 at 12:53 pm
kevin77 (3/19/2009)
The solution to solving SQL Injection attacks is simply for every RDBMS system to flat out not allow inline SQL. Everything must be done with stored procedures and parameters.
Even that's not sufficient. I spent a good couple hours explaining to a fairly experienced web developer why this is vulnerable to injection, regardless of what the procedure does.
Pseudo C# code:
SqlCommand cmd = new SqlCommand();
cmd.CommandText = "Exec SomeProcedure @Param1 = '" + txtSomeValue.ToString() + "', @Param2 = '" + txtSomeOtherValue.ToString() + "';"
cmd.ExecuteNonReader();
And don't forget the nicely parameterised stored procedure that goes and builds up a SQL string with those parameters and EXECs it.
No inline SQL
All stored procedure calls must be properly parameterised
Any dynamic SQL within said procedures must be properly parameterised and must not include values from the front end or from the database.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 19, 2009 at 1:07 pm
Seems like Charles' list touches a chord.
I too am surprised at how common SQL injection vulnerabilities (still) are. Having recently implemented an EDRMS system, our supplier provided a small addin to integrate with another system. I knew they would be taking values from a form to query a database and my first test was for SQL injection - I don't need to tell you it failed. They fixed it straight away, but these are supposedly professional developers, who do this sort of work for a living. Such tests should be part of any good QA regime and never make it off the factory floor.
Chris
March 19, 2009 at 2:12 pm
GilaMonster (3/19/2009)
kevin77 (3/19/2009)
The solution to solving SQL Injection attacks is simply for every RDBMS system to flat out not allow inline SQL. Everything must be done with stored procedures and parameters.Even that's not sufficient. I spent a good couple hours explaining to a fairly experienced web developer why this is vulnerable to injection, regardless of what the procedure does.
Pseudo C# code:
SqlCommand cmd = new SqlCommand();
cmd.CommandText = "Exec SomeProcedure @Param1 = '" + txtSomeValue.ToString() + "', @Param2 = '" + txtSomeOtherValue.ToString() + "';"
cmd.ExecuteNonReader();
And don't forget the nicely parameterised stored procedure that goes and builds up a SQL string with those parameters and EXECs it.
No inline SQL
All stored procedure calls must be properly parameterised
Any dynamic SQL within said procedures must be properly parameterised and must not include values from the front end or from the database.
Right, Gail. One of the most often missed points in discussions about SQL Injection is that the injection can happen on the Client side as well as the server side.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
March 19, 2009 at 8:48 pm
I am late to this but Microsoft have improved the System.Security.Cryptography class with the implementation of the new Elliptic Curve Diffie-Hellman classes which are more secure than the previous version. This will improve application layer encryption so all that is needed is improved SQL Server based encryption.
The reason is these classes cannot be used for CLR assembly so there must be a solution for the persisted data in SQL Server.
http://blogs.msdn.com/shawnfa/archive/2007/01/22/elliptic-curve-diffie-hellman.aspx
Elliptic Curve is modular Taniyama-Shimura
Kind regards,
Gift Peddie
March 20, 2009 at 10:51 am
Gift Peddie (3/19/2009)
I am late to this but Microsoft have improved the System.Security.Cryptography class with the implementation of the new Elliptic Curve Diffie-Hellman classes which are more secure than the previous version. This will improve application layer encryption so all that is needed is improved SQL Server based encryption.The reason is these classes cannot be used for CLR assembly so there must be a solution for the persisted data in SQL Server.
http://blogs.msdn.com/shawnfa/archive/2007/01/22/elliptic-curve-diffie-hellman.aspx
Elliptic Curve is modular Taniyama-Shimura
You have to love the fact that the whole Crypto class is not in Dot Net for the Mobile. Let's see if I'm out on the road or setting at a desk right next to the server where would I most need encryption? Hmm. Anybody? Want to hazard a guess?
ATBCharles Kincaid
March 20, 2009 at 2:51 pm
You have to love the fact that the whole Crypto class is not in Dot Net for the Mobile.
The quick thing that comes to mind is prime numbers and limited resources don't mix, Microsoft have to create a version more constrained than the current implementation to run in compact framework. The same reasons SQL Server compact is not similar to Express or the other editions.
Kind regards,
Gift Peddie
March 20, 2009 at 3:52 pm
Gift Peddie (3/20/2009)
You have to love the fact that the whole Crypto class is not in Dot Net for the Mobile.
The quick thing that comes to mind is prime numbers and limited resources don't mix, Microsoft have to create a version more constrained than the current implementation to run in compact framework. The same reasons SQL Server compact is not similar to Express or the other editions.
While that's true for some features of SQLCE, it's not true for others which were limited more by development team bandwidth than by device limitations. But what do I know?
October 2, 2013 at 7:34 am
..The NSA, along with a number of other companies, is trying to do something about poor programming practices. They have release a list of the 25 most dangerous programming mistakes..
Here are a couple of tips for the NSA:
#1 Don't post top secret documents on SharePoint.
#2 Don't outsource your system administrators.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 3, 2013 at 10:30 am
Eric M Russell (10/2/2013)
..The NSA, along with a number of other companies, is trying to do something about poor programming practices. They have release a list of the 25 most dangerous programming mistakes..
Here are a couple of tips for the NSA:
#1 Don't post top secret documents on SharePoint.
#2 Don't outsource your system administrators.
#3. http://WWW.Snowden.edu is not your friend
Not all gray hairs are Dinosaurs!
October 4, 2013 at 10:19 pm
Well, back in 2009 SANS published its list. It was going to be regularly revised. In 2010, there was a revsion, and an archive of the 2009 version was retained on line along with the new (2010) version. In 2011 there was another revision, and the 2010 version was archived, so now there was a current version and two archived versions online; and the current version contained the statement "The TOP 25 Errors List will be updated regularly and will be posted at both the SANS and MITRE sites"; that was June 27th, 2011. There has been no update to the SANS site since. Is that because there are no new mistakes to be made, or because the world has not learnt anything so that all the old mistakes are still being made just as much as before? Do they think it's a perfect list (if so they are nuts)? The 2011 page at the MITRE site (http://cwe.mitre.org/top25/[/url] has a discussion of each error and a whole pack of advice on how to avoid these errors - the SANS site doesn't even have a decent description of what the errors mean (the 2010 and 2009 verson were better in that respect) let alone advice on avoidance. The Mitre page was being updated up to september 2011, presumably to provide all the material that SANS doesn't have. Although it is two years out of date, just as the SANS page is, it is an infinitely more useful page than the one at SANS.
I look at their insecure interaction category, and see that it includes SQL Injection, OS Command Injection, Cross-site scripting, Unrestricted upload of file with dangerous type (that one makes me wonder how the type is to be determined, and which types are considered dangerous, but never mind), Cross-site request forgery, and redirectipn to untrusted site. Well, apparently if there are several components of the application all running on the same server it doesn't much matter of they pass each-other rubbish instead of what they should pass; if one application component unintentionally is such that now and again it will effectively do an injection attack against not SQL server and not the OS but against another application component, that doesn't matter; it isn't important for each application component to validate all its parameters - oh, it has to validate strings (and their lengths) and if it's taking a security decision it mustn't rely on untrusted inputs, and a critical function must authenticate its users (you might guess that's what CWE-306 is about if you read the SANS page; but you won't know unless you read the Mitre page); but one component validating parameters (other than strings) passed by another - failue to do that isn't a sufficiently serious error to be on the list, while validating strings is on at least twice (once as check the length and once as check the format; presumably the OS command injection issue will mean checking the content, so maybe it's three times; SQL injection should be avoided by allowing only calls to stored procedures and ensuring that those calls are seen from application level as parametrised calls where the command part consists only of the procedure name, a technique which is as old as the hills, so that won't include ding validation of string content beyond the format and length issues). To me this seems wrong - put strings in once - validate that they will fit the input buffer before copying them into it and ensure that teh format is valid, and mentionvalidation of other parameters too as another thing whose very common omission can be a big and unpleasant error.
I would recommend everyone to look at the cwe websites front page, not just the top 25 page, and see which other parts of the site they might find useful to read; in my view we would have far fewer bugs if all developers read and inwardly digested the whole site, but that's probably asking too much.
Steve expressed concern about the way software development is taught, about dumbed down examples, doing it the easy way without regard to best (or even great) practises, and keeping things simple by avoiding robust error checking, error handling, and security practices. I share that concern. I would go so far as to say that people are usually not taught to do software development or to be software engineers; they are taught something about a couple of programming languages and how to do some clever tricks in those languages, but nothing about error management or the design of something that would take the average student more than eighty hours to design and write. Universities should be teaching error management, code verification techniques, designing modular systems with clear boundaries and tight and narrow interfaces, as declarative a programming style as possible, how to estimate computational complexity, how to design for testability, how to test, and how to distinguish good practise from bad. Some universities/colleges/training companies do try to teach all of this to their students, others attempt some of it, and yet others teach none of it and instead concentrate on how to write code using C++ or Java or some other fairly awful but very fashionable language without any regard to error management, security, modularity, or declaritiveness. It's the developers educated (if you can call it that) by this last group that are the cause for concern; fortunately they usually can be taught despite the bad habits there education has instilled in them.
Tom
October 7, 2013 at 8:13 am
The mistake of "Execution with Unnecessary Privileges" should be #1 on the list. That's really the root of all exploits. SQL injection and buffer overflow are common, and the techniques for prevention are common too. There are 100 different ways to exploit an application, but the end game for most of them involves performing some privillaged operation once the back door has been pried open. However, if the OS or database account under which the application runs is tightly constrained in terms of what and how it can access resources (tables, file system, network, etc.), then the exploit will result in nothing but an access denied error message.
Another good general security practice to hide error messages from the end user. You shouldn't need the user to tell you what error occurred, you should instead be logging and monitoring errors operationally on the back end. An error message is information that a hacker can use to measure the success of their exploit attempts.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 7, 2013 at 9:25 am
Eric M Russell (10/7/2013)
Another good general security practice to hide error massages from the end user. You shouldn't need the user to tell you what error occurred, you should instead be logging and monitoring errors operationally on the back end. An error message is information that a hacker can use to measure the success of their exploit attempts.
Eric,
I could not agree more. Using a canned message and logging the stack, parms, conditions or whatever you can to give the developer a chance to get back to the same point as to reproduce the error and fix it are optimal. The message to the user is something simple but detailed enough to let them know potentially what is wrong and what their next step should be. The notification/email/logged message to the developer should be where the truth lies.
To parapharse => Never give a hacker an even break!
Miles...
Not all gray hairs are Dinosaurs!
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply