Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Write Better Code


Write Better Code

Author
Message
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36083 Visits: 18738
Comments posted to this topic are about the item Write Better Code

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
MikeAngelastro-571287
MikeAngelastro-571287
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 177
I think that the best way for this is invoking stored procedures that validate requests.
Rich Dudley
Rich Dudley
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
Points: 4 Visits: 34
Agreed!

I remember having a discussion about 10 years ago with Kent Tegels on the old SQL Junkies website. It was just after Kent had remarked it was up to DBAs to secure their databases better (or something of that nature). I pointed out to him that all the efforts of a DBA were for naught if a developer implements some idiotic code. Time and again (and very recently) bad code has compromised what were probably considered very secure databases. I actually can't think of one breach due to weak database security in the last several years--they've all been SQL Injection or compromised network credentials.

If there's any argument to be made for utilizing stored procedures it's that the query code is in the database, and the review of such is the DBA's responsibility. Most devs don't like the idea of the idea of their code being reviewed by a non-developer.

I'm not sure how to bridge the often contentious divide between DBAs and devs. I've never experienced it myself, and I've had one foot firmly planted on both sides of the SQL Connection for years. But I've heard plenty of horror stories. I think it's incumbent on managers to not only not promote the contention in the first place, but to get both teams working together when there is strife. Make awesome, not war.
emmchild
emmchild
Valued Member
Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)

Group: General Forum Members
Points: 72 Visits: 408
When designing a system I go out of my way to keep stored procedures in use and database credentials secure. The software expects to get an environment variable and operate accordingly. The data access layer knows which stored procedures to call. The system works well unless someone takes a shortcut and decides to bypass the data access layer AND decides to supply an embedded config file with data access information exposed in the clear.



pdanes
pdanes
SSC-Addicted
SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)SSC-Addicted (442 reputation)

Group: General Forum Members
Points: 442 Visits: 1350
No arguments from me on this one. I remember in one of my first programming courses, assembly language on a Univac 9300, one of the things the prof stressed was checking the length of input data. Back then it was to keep data from accidentally trashing a segment of code, rather than a security measure, yet today, almost forty years later, still one of the most common attack methods is utilizing buffer overruns. Hasn't anyone learned anything in the interim?
chrisn-585491
chrisn-585491
SSC Eights!
SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)SSC Eights! (944 reputation)

Group: General Forum Members
Points: 944 Visits: 2311
Steve Jones wrote:
. Managers need to allow more time for code to be written as developers learn to implement the patterns and frameworks that result in secure code. Management needs to make it a priority for developers to continunally learn about new secure coding techniques, and allow for security testing of code.


Bingo!

I can't take the time to educate myself, write secure code and test it if management wants it shipped yesterday. The bro-grammer down the hall may get the kudos just on time to deployment, not withstanding that the maintenance programmers will spend years cleaning up his shit.
sturner
sturner
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1475 Visits: 3254
So glad you wrote this Steve I couldn't agree with you more. But as you state it does need to start top down and I really believe that too many "managers" are clueless about the realities of software development much less leveraging the security enhancements of .NET and SQL server.

I hear a lot about "agile" and "scrum" but without the basis of a clear functional and design specification they are just buzzwords that make people feel good about what they are doing (or not doing). It is really all about leadership in the development department based inclusion, mentoring, training and standards.

The probability of survival is inversely proportional to the angle of arrival.
GSquared
GSquared
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: General Forum Members
Points: 14375 Visits: 9729
The company I work for has software from a vendor who still thinks that SQL injection is best-prevented by "sanitizing the input strings", instead of by parameterization. So, you can inject code if you avoid the word "select" in your injection, but you also can't search the site for "Bob's Select Steakhouse". Security scans of their websites routinely find SQL injection vectors, and cross-site-scripting vectors, and they just add more dunnage to their string-cleaning, time after time. (Names redacted to protect the guilty.)

Just knowing about security, and following "well, it's a standard, who cares if it's not working" methodology, isn't enough. The handling has to be correct. The line between security and paranoia is largely one defined by those who want you to think that keeping them out is paranoia. Remember, "Annonymous" is ready to attack anyone, for any reason or no reason at all. They, and like-minded criminals, might attack your site just to see what happens, or just for the fun of it, and they're very much interested in you thinking that "that extra bit of security" is "expensive" or "paranoid", or both.

Of course, if you like the idea of your servers being used to send out phishing spam, or serving up kiddy-porn, supporting human trafficking, or whatever, then avoiding "paranoia" is probably okay. Just remember, it's not necessarily about what you have on the servers, which might very well be "nobody wants it", so much as what the Russian maffia wants to put on your servers. It works both ways.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36083 Visits: 18738
On a related note: http://www.troyhunt.com/2012/07/heres-why-we-keep-getting-hacked-clear.html

Send to your boss if you still use ASP.

Send to your developers if they don't know about that stuff.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Rich Dudley
Rich Dudley
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
Points: 4 Visits: 34
Great link, thanks!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search