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 12»»

Review Your Code Expand / Collapse
Author
Message
Posted Saturday, August 10, 2013 11:54 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 2:28 PM
Points: 33,062, Visits: 15,174
Comments posted to this topic are about the item Review Your Code






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1483044
Posted Monday, August 12, 2013 3:08 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 7:57 AM
Points: 1,610, Visits: 5,480
Surely the amnesty cutoff date should be whenever this was posted?

http://xkcd.com/327/
Post #1483197
Posted Monday, August 12, 2013 6:30 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:36 PM
Points: 2,514, Visits: 3,705
I may need some educating here. But, is the article Denny Cherry referenced really discussing a SQL injection? It was injecting malicious Javascript to a web page. It seems to me that's different than a SQL injection.

Post #1483258
Posted Monday, August 12, 2013 7:47 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 3:00 PM
Points: 567, Visits: 6,231
Ugh, this rings far too true at present. The company I work for currently uses third-party software, and after examining the system, I've found that its search procedures are all very SQL-injectable by running some test injections against it. Worse yet, the search procedures aren't stored procedures, they're just SQL strings concatenated together in the ASP.NET front-end.

Not sure if I can rewrite these monstrosities without breaking the service agreement with the third-party company, and they've said they don't intend to fix the vulnerability. If I had a say in it, the whole software company would be "fired" from our usage, and their program replaced


----------------------------------
My journal of things I'm learning about SQL
Post #1483321
Posted Monday, August 12, 2013 8:22 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:55 PM
Points: 6,582, Visits: 8,860
IMO, the amnesty cutoff date should be 2003. And not just for SQL Injection - there's all kinds of vulnerabilities in code that have been exposed (another example that should have died a long time ago is cross-site scripting), methods to do it safely and properly have been implemented, and the dang developers are either completely incompetent or too lazy to do it right. Fire them all, and get competent programmers that will actually work with the DBA to do it correctly.

But it boils down to the companies. If you are going to have an emphasis on hiring the cheapest person, you get what you pay for. If you aren't going to have regular training on how to do things correctly (including newly discovered things outside of your company), you deserve what's coming to you. If you sweep it under the rug... shame on you. Where is the code review for this code that's being written with all of these vulnerabilities? That usually comes down to a resource availability to do it - something that the company controls and not the developer. There are programs that will test your code for vulnerabilities - not using these is a company decision. This is a topic that you just can't take a shortcut with.

From a developer standpoint, there's no excuse for implementing such shoddy code.
From a business standpoint, there's no excuse for allowing it. And the onus is on the business to ensure that it is done properly. If your business has an environment where this is allowed to persist, there's no incentive to ever change from "we've always done it this way". And your developers never will.

And if your business sells this product, your business should be held liable for every individual instance of these security preventative measures not being followed, with a minimum fine a $500,000 (USD) per occurrance. Unfortunately, businesses usually won't change until it becomes less expensive to do it right the first time, and the only way this will happen is by steep fines when they don't.


Wayne
Microsoft Certified Master: SQL Server 2008
If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
Links: For better assistance in answering your questions, How to ask a question, Performance Problems, Common date/time routines,
CROSS-TABS and PIVOT tables Part 1 & Part 2, Using APPLY Part 1 & Part 2, Splitting Delimited Strings
Post #1483345
Posted Monday, August 12, 2013 9:47 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, July 11, 2014 1:27 PM
Points: 1,370, Visits: 1,540
Set the amnesty date in 2003 and you'd have to fire some Microsoft programmers. I was shocked to see sample code on the architecture and practices site with concatenated queries much later than that.

Worse still, recent version of SSIS have decreased the opportunities to add parameters to queries on sources, opting for expressions. The chance of a SQL Injection in SSIS is very rare, but it sets the wrong expectations and habits.

It is a correct observation that this problem stems from low cost which is further fueled by the low barrier to entry. As a profession, we have done a bad job of setting standards and communicating the value of those standards.

I expect this will get much worse before it gets any better. New web companies emerge every day and each is an opportunity for bad code to expose private information. As far as fining the offending companies...the big guys have their license agreements written to exclude damages incurred from their bugs. I don't expect that to change either.
Post #1483377
Posted Monday, August 12, 2013 10:16 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 2:28 PM
Points: 33,062, Visits: 15,174
OCTom (8/12/2013)
I may need some educating here. But, is the article Denny Cherry referenced really discussing a SQL injection? It was injecting malicious Javascript to a web page. It seems to me that's different than a SQL injection.



The JS is injected into the database. It's spread the next time a dynamic version of a page is rendered. At least, that's my understanding and how I've seen things spread before.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1483385
Posted Monday, August 12, 2013 10:19 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 2:28 PM
Points: 33,062, Visits: 15,174
brdudley (8/12/2013)
Set the amnesty date in 2003 and you'd have to fire some Microsoft programmers. I was shocked to see sample code on the architecture and practices site with concatenated queries much later than that.

Worse still, recent version of SSIS have decreased the opportunities to add parameters to queries on sources, opting for expressions. The chance of a SQL Injection in SSIS is very rare, but it sets the wrong expectations and habits.


I completely agree, but I'd also put this same burden on bloggers/ speakers. Stop showing sa/blank, or joke about sa/test as an easy combination. Stop showing simple passwords and bad code.

We are also to blame in pushing out bad code.

Not that MS has any excuse. They should practice what they preach, even if it means slightly delayed products or more architecture.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1483386
Posted Monday, August 12, 2013 12:33 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 7:46 AM
Points: 76, Visits: 340
Steve says today (8/12/2013) in the editorial "I wasn't surprised when a piece from Denny Cherry appeared recently"

Um, the Dennis Cherry post says "This entry was posted on Monday, October 24th, 2011 at 2:36 pm".

The code snippet linked in the Cherry post was posted 10/12/2011.

The IT World article linked in the Cherry post was posted 10/24/2011.

Is this perchance a reprinted editorial from 2011?
Post #1483417
Posted Tuesday, August 13, 2013 7:21 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:36 PM
Points: 2,514, Visits: 3,705
Steve Jones - SSC Editor (8/12/2013)
OCTom (8/12/2013)
I may need some educating here. But, is the article Denny Cherry referenced really discussing a SQL injection? It was injecting malicious Javascript to a web page. It seems to me that's different than a SQL injection.



The JS is injected into the database. It's spread the next time a dynamic version of a page is rendered. At least, that's my understanding and how I've seen things spread before.


Thanks Steve for the explanation.
Post #1483724
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse