July 14, 2012 at 12:54 pm
Comments posted to this topic are about the item Write Better Code
July 14, 2012 at 4:45 pm
I think that the best way for this is invoking stored procedures that validate requests.
July 14, 2012 at 6:44 pm
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.
July 15, 2012 at 12:21 am
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.
July 15, 2012 at 6:28 am
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?
July 16, 2012 at 6:51 am
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.
July 16, 2012 at 8:48 am
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.
July 16, 2012 at 9:17 am
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
July 16, 2012 at 9:47 am
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.
July 16, 2012 at 10:01 am
Great link, thanks!
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply