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 Wednesday, March 18, 2009 3:03 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:02 PM
Points: 33,062, Visits: 15,176
Comments posted to this topic are about the item Secure Programming






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #678933
Posted Wednesday, March 18, 2009 10:43 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Thursday, June 5, 2014 10:54 AM
Points: 9,902, Visits: 9,480
What I find most interesting about the NSA'a list is that the #3 worst practice on their list is specific to SQL: SQL Injection vulnerability.

-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc.
"Performance is our middle name."
Post #679149
Posted Wednesday, March 18, 2009 11:15 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 @ 2:20 PM
Points: 3,122, Visits: 11,401
It isn't always easy to convince even experienced developers that SQL Injection can be a problem. Look at this current thread.

Avoiding injection on stored procedure
http://www.sqlservercentral.com/Forums/Topic678702-8-1.aspx
Post #679162
Posted Thursday, March 19, 2009 2:56 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 2:38 AM
Points: 67, Visits: 709
Michael Valentine Jones (3/18/2009)
It isn't always easy to convince even experienced developers that SQL Injection can be a problem. Look at this current thread.

Avoiding injection on stored procedure
http://www.sqlservercentral.com/Forums/Topic678702-8-1.aspx



I've put a suggestion at http://www.sqlservercentral.com/Forums/Topic678702-8-2.aspx for that one.


There is no problem so great that it can not be solved by caffeine and chocolate.
Post #679233
Posted Thursday, March 19, 2009 2:58 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 2:38 AM
Points: 67, Visits: 709
Is it me, or did they miss "Check for NULL"?


There is no problem so great that it can not be solved by caffeine and chocolate.
Post #679234
Posted Thursday, March 19, 2009 3:00 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:57 AM
Points: 1,049, Visits: 3,002
Well, I've just added that list to my browser favourites. It's an excellent resource.

I'm a DBA who, at various points, has had to branch out and learn sufficient about various development platforms to achieve certain business requirements. It's easy enough when learning something new to find out what can/can't be done, but it's actually very difficult to find out what should/shouldn't be done. If you simply use your common sense, you don't know enough about the new environment to identify the risks. If you ask for recommendations from a community (such as this), you'll get chapter and verse, and you'll have problems sifting out the important nuggets.

Therefore, I'll be using that list as a benchmark for any of my applications, and thanks for pointing it out.


Semper in excretia, sumus solum profundum variat
Post #679235
Posted Thursday, March 19, 2009 7:03 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, May 12, 2014 1:27 PM
Points: 1,386, Visits: 824
In my experience it's fairly difficult to squeeze any sort of good coding practice out of most developers. They have deadlines, code quality be damned.
As Steve pointed out Security and error handling are significant culprits, but there are others that are less visible, and i think perhaps more common: poor/lack of naming conventions, spaghetti code, useless/missing comments, orphaned functions, etc.
I can't think what else might belong on that list but i'm sure there's something.

We can hope that the NSA list will be used as a benchmark for adequately secure code, but the chances of it being used widely are, i think, quite small.
Post #679358
Posted Thursday, March 19, 2009 8:35 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, July 7, 2014 10:01 AM
Points: 1,136, Visits: 697
Let's go back to the overused analogy of building a house. If you tell a carpenter to build a house that can't be broken into or that is impervious to fire, that carpenter is going to look at you like you are a fool. However, with the help of some specialized subcontractors, namely someone who installs security systems and fire alarms, that person can give you some insulation to the problems of breaking in and fire. They aren't full proof solutions, but they make it tougher on the burglar.

As a programmer or DBA, we can't be expected to be experts in everything. Yes we can use some security best practices, but we also need the help of specialists that focus on security issues in whatever environment we are working in. We also need more standards to help guide us. This would be similar to the Building Codes carpenters and general contractors have to use.
Post #679477
Posted Thursday, March 19, 2009 9:11 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
You've heard the old saw "drive defensively". Well code defensively.


  • Assume that all data is CRAP

  • Assume that all code is broken. Especially if you wrote it.

  • I don't give a hang what DRI is in place you can still have orphans and invalid data in tables.

  • "That can't happen." is most often heard right after it just did.

  • Code, reports, etc. that work just fine in the shop can and will drop dead upon deployment.

  • Managed code is managed but not perfect.

  • Even Micro$oft has bugs.



One of my customers switched to a large famous ERP system. The new system had been tested for months. What brought it down on the first day live? Someone posted a memo stating that all users should log on at precisely 10 AM Eastern. Jammed the logon queues and, a couple of minutes later, the phone system. Perfectly working software. Killed by several thousand people all watching the clock tick down and hitting the button together.


ATB

Charles Kincaid

Post #679532
Posted Thursday, March 19, 2009 9:40 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:02 PM
Points: 33,062, Visits: 15,176
Charles, that's a good list. I need to keep that one around.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #679574
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse