Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

Secure Programming Expand / Collapse
Author
Message
Posted Friday, March 20, 2009 10:51 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, February 6, 2014 12:59 PM
Points: 801, Visits: 1,962
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?


ATB

Charles Kincaid

Post #680573
Posted Friday, March 20, 2009 2:51 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 10:22 AM
Points: 3,433, Visits: 14,430
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
Post #680728
Posted Friday, March 20, 2009 3:52 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, June 24, 2013 11:26 AM
Points: 208, Visits: 380
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?
Post #680756
Posted Wednesday, October 2, 2013 7:34 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:39 PM
Points: 1,660, Visits: 4,748
..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.
Post #1500772
Posted Thursday, October 3, 2013 10:30 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 5:34 PM
Points: 2,341, Visits: 1,401
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. WWW.Snowden.edu is not your friend


Not all gray hairs are Dinosaurs!
Post #1501274
Posted Friday, October 4, 2013 10:19 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 2:08 PM
Points: 8,844, Visits: 9,405
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/ 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
Post #1501812
Posted Monday, October 7, 2013 8:13 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:39 PM
Points: 1,660, Visits: 4,748
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.
Post #1502155
Posted Monday, October 7, 2013 9:25 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 5:34 PM
Points: 2,341, Visits: 1,401
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!
Post #1502218
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse