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 Tuesday, August 13, 2013 9:59 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 6:20 PM
Points: 33,078, Visits: 15,192
TGwinn (8/12/2013)
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?


No, I didn't check the date. Denny posted a note just the other day about this, and I thought it was new. My mistake.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1483846
Posted Thursday, August 15, 2013 7:41 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 8:33 AM
Points: 122, Visits: 612
If we want to see the back of sql injection harpooning the developers is probably the wrong way to go about it. Yes they should be using parametized queries and yes you could fire them for concatenating values into their sql strings but the chances are the next developer you hire is going to do the same damn thing... even if you specifically ask it as an interview question. There will always be bad developers and some of them are going to sneak in under the radar.

What I'd like to see is this prevented at the development language level. I'd like to see is an abstraction that sits above the level of ADO etc. and builds my sql for me in a guaranteed safe fashion. It should pull in the schema and allow me to select the various sql operations etc. Basically something similar to the query builder that comes in management studio or access. Of course, those query builders are truly horrible which is why nobody uses them so this abstraction would have to be GOOD. I'm not sure what it would look like, whether it would be graphical or textual but it would have to be easy to use, powerful and flexible. It would also need to keep up with new additions to the various flavours of sql. It would be no mean feat to create such a tool but until it exists I will continue to write my own sql strings and, as long as I do that, I am more than capable of idiocy.
Post #1484763
Posted Monday, August 19, 2013 10:44 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:18 PM
Points: 2,266, Visits: 1,320
There are OTC solutions that will read your code and scripts and warn you of potential security problems. All of the SQL Injections are identified and you can change as needed. Problem is that these solutions are very costly and take a specialized skill set. And they can add weeks to the release cycle depending on what is found in the QA/QC and Security check. Many companies will not hold a production release of software for a Security evaluation. The idea is to get to market as quickly as possible and to make money!!! And this will continue for as long as Marketing is allowed to control the release dates and versions.



Not all gray hairs are Dinosaurs!
Post #1485905
Posted Thursday, August 22, 2013 2:18 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:07 PM
Points: 5,191, Visits: 2,811
I agree with what I think the general consensus is: the time when this was acceptable as a flaw due to lack of knowledge and education has passed.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1487108
Posted Thursday, August 22, 2013 11:30 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 6:44 PM
Points: 8,562, Visits: 9,062
Gary Varga (8/22/2013)
I agree with what I think the general consensus is: the time when this was acceptable as a flaw due to lack of knowledge and education has passed.

Yes, that time passed long ago.
back in the summer of 1988, when an SQL Injection attack managed to result in one and a half million web pages on US and UK government sites being sufficiently damaged that they began to spread malware, it was already long past the time when people should have stopped writing stuff that allowed this to happen, but there were idiots claiming that preventing injection was very difficult to do. I commented on it then (not on SQL Server Central):
(8/13/2008)

I find it appalling that our government has so many sites that suffer this problem, in fact appalling isn't strong enough it is outright disgraceful. It's equally disgraceful that there are those here who are commenting to the effect that avoiding SQL Injection isn't easy, when in fact it is pretty trivial.

It seems to me to be amazingly easy to design and produce web applications, even using oldish technology like MS ASP with ADO (and SQL Server 2000) that are free from any possibility of succumbing to web injection attacks, and permitting injection seems actually to require a extreme lack of awareness of simple principles of design.

The situation has not changed: it's just as easy with ASP.NET as it was with ASP, and with SQLS 2012 as it was with SQLS 2000. But people still want to construct queries by concatenating user supplied strings in the front end, which in my opinion is definitely be an offence for which a web developer should be fired (if the employee protection rules / laws permit it).


Tom
Post #1487428
Posted Thursday, August 22, 2013 12:49 PM
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
Perhaps its just a figure of speech, but the fixation on firing people for this seems misplaced.

Surely, coding to prevent SQL Injection is a learned skill, like many others.

If a company had rigorous guidelines, training, or quality control initiatives and a programmer stubbornly refused to change coding pratices, then termination makes sense. Otherwise, it seems like it falls into the category of a teachable mistake.

The ultimate responsibility for public errors, incursions, and data loss should rest much higher in the organization.
Post #1487456
Posted Thursday, August 22, 2013 3:33 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 6:44 PM
Points: 8,562, Visits: 9,062
brdudley (8/22/2013)
Perhaps its just a figure of speech, but the fixation on firing people for this seems misplaced.

Surely, coding to prevent SQL Injection is a learned skill, like many others.

If a company had rigorous guidelines, training, or quality control initiatives and a programmer stubbornly refused to change coding pratices, then termination makes sense. Otherwise, it seems like it falls into the category of a teachable mistake.

The ultimate responsibility for public errors, incursions, and data loss should rest much higher in the organization.

Obviously there would only be a question of firing if such code got out of the door; trainees and other junior developers are not responsible for what goes out of the door, checks (code reviews as well as testing) are needed that things conform to corporate standards and if they don't training can be given. For more senior people who are new to the shop, QA of their output should include testing for susceptibility to injection during an initial period: that's easy enough to do. They should have had an induction which makes corporate policies and standards clear, and these should be reinforced by seminars from time to time. Even so, if they don't do it during the period when injection checks are being done in QA and then do it afterwards, they aren't going to be fired the first time - but it had better not happen twice. For really senior people (system architects, departmental and divisional chief designers, the person to whom responsibility for security policy design, and others at that level, there should be very harsh words and firing is certainly a possibility if the response to those words indicates the wrong attitude to their responsibilities. But "fire anyone who does it" is , as you suggest, more a figure of speech intended to indicate the seriousness of the problem than a statement of fixed policy; firing a trainee who gets it wrong is just stupidity (firing a trainee who is incapable of learning or just unwilling to learn is a different matter).


Tom
Post #1487549
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse