February 17, 2015 at 9:21 am
Thanks!!!
Luis Cazares (2/17/2015)
Just to give an example on what can be done. But I agree that future replies should be done on a new thread.
February 17, 2015 at 9:43 am
Thanks for the idea for a great topic for an upcoming user group meeting.
Now, Just need to find someone to present it.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
February 17, 2015 at 9:45 am
There's no shortage of [SQL] code that comes from frameworks and application templates, not to mention naive or ignorant developers.
It's not a complete solution, but whenever possible, I've been encouraging our programmers to develop and deploy web services.
February 17, 2015 at 9:50 am
Gary Varga (2/16/2015)
On top of the "lazy" experienced developers the bar appears to be getting lower for new developers. Perhaps that is not accurate. Developers are being gauged on how quickly they can develop nice looking UIs and how many frameworks they can use as well as whether they can pair program and know how to run a scrum. There appears to be little emphasis put on quality.Two coders pair programming without any emphasis on quality will lead to poor quality code.
Quite simply, we have moved consumerism into engineering and, as an industry, are aghast at the results whilst at the same time refusing to acknowledge the cause. Because it is deemed an uncompetitive strategy to pay to do it properly.
A bit of that, but more that some of the framework guidance and development needs to be sure that it thinks about SQL Injection. some of the frameworks prevent it, some don't.
February 17, 2015 at 9:59 am
It shouldn't be to hard to develop a function, or functions, on the application development side that test all SQL statements to prevent injection. Once that's done, just have to use these before executing any SQL statement.
Doesn't sound do hard.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
February 17, 2015 at 10:16 am
Alvin Ramard (2/17/2015)
It shouldn't be to hard to develop a function, or functions, on the application development side that test all SQL statements to prevent injection. Once that's done, just have to use these before executing any SQL statement.Doesn't sound do hard.
It is. Like validating email addresses. Seems simple. Isn't.
Far too many exceptions needed.
February 17, 2015 at 10:29 am
However there are two big problems that prevent us from eradicating SQL Injection: aging code and bad habits.
I know it gets old, but we should never assume we're preaching to the same crowd. New programmers are entering the workforce every day, and a lot of them, perhaps most of them, are younger and less compensated with a minimal grasp of the fundamentals covering a broad range of topics, as opposed to something like a database specialist. They see data in terms of objects and documents, and whether the middle tier or back end RDMS properly handles dynamic SQL is just not forefront in their mind. So, SQL Injection may be one of those timeless software engineering topics just like error handling, least privilege, and source control.
My concern is that a lot of IT shops, even those within large organizations that manage critical data, just don't "get" database engineering. For them a "database developer" is someone who can whip up a nice looking SSRS report or ETL job in addition to their regular job coding Java and HTML5.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 17, 2015 at 10:38 am
My concern is that a lot of IT shops, even those within large organizations that manage critical data, just don't "get" database engineering. For them a "database developer" is someone who can whip up a nice looking SSRS report or ETL job in addition to their regular job coding Java and HTML5.
I wonder whether many of those IT shops - especially those within large organisations - include code review as part of their software development process? More specifically, how many include SQL code review by those in the shop who do understand database engineering?
It's a matter of quality assurance, assured by those who know best. Yet, sadly, QA seems to be flying out the window as the commercial pressures to 'get the code to market first' increase.
February 17, 2015 at 10:45 am
Steve Jones - SSC Editor (2/17/2015)
Gary Varga (2/16/2015)
On top of the "lazy" experienced developers the bar appears to be getting lower for new developers. Perhaps that is not accurate. Developers are being gauged on how quickly they can develop nice looking UIs and how many frameworks they can use as well as whether they can pair program and know how to run a scrum. There appears to be little emphasis put on quality.Two coders pair programming without any emphasis on quality will lead to poor quality code.
Quite simply, we have moved consumerism into engineering and, as an industry, are aghast at the results whilst at the same time refusing to acknowledge the cause. Because it is deemed an uncompetitive strategy to pay to do it properly.
A bit of that, but more that some of the framework guidance and development needs to be sure that it thinks about SQL Injection. some of the frameworks prevent it, some don't.
Hence my preference for stored procedures regardless of frameworks used (a bit odd from an agile developer huh?)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 17, 2015 at 10:54 am
It is management that says "Just make it work and ship it!". Most developers would extend development to get it right if given the choice..
February 17, 2015 at 10:55 am
Gary Varga (2/17/2015)
Steve Jones - SSC Editor (2/17/2015)
Gary Varga (2/16/2015)
On top of the "lazy" experienced developers the bar appears to be getting lower for new developers. Perhaps that is not accurate. Developers are being gauged on how quickly they can develop nice looking UIs and how many frameworks they can use as well as whether they can pair program and know how to run a scrum. There appears to be little emphasis put on quality.Two coders pair programming without any emphasis on quality will lead to poor quality code.
Quite simply, we have moved consumerism into engineering and, as an industry, are aghast at the results whilst at the same time refusing to acknowledge the cause. Because it is deemed an uncompetitive strategy to pay to do it properly.
A bit of that, but more that some of the framework guidance and development needs to be sure that it thinks about SQL Injection. some of the frameworks prevent it, some don't.
Hence my preference for stored procedures regardless of frameworks used (a bit odd from an agile developer huh?)
I'm with you on the stored procedures bit, but I don't really like frameworks, at least the ones I've seen. They just don't generate efficient SQL code and end up creating performance problems. I don't know of a wizard, GUI query tool that'll do it either. In the end, there's just no substitute for writing good code.
February 17, 2015 at 11:15 am
It is management that says "Just make it work and ship it!". Most developers would extend development to get it right if given the choice.
I agree, assuming those developers are cognisant of SQL injection issues and how to avoid them. Steve Jones' point is that there are always 'newbie' developers coming on line, who may not be familiar with the issue, nor schooled in its avoidance.
February 17, 2015 at 11:18 am
Gary Varga (2/16/2015)
On top of the "lazy" experienced developers the bar appears to be getting lower for new developers. Perhaps that is not accurate. Developers are being gauged on how quickly they can develop nice looking UIs and how many frameworks they can use as well as whether they can pair program and know how to run a scrum. There appears to be little emphasis put on quality.Two coders pair programming without any emphasis on quality will lead to poor quality code.
Quite simply, we have moved consumerism into engineering and, as an industry, are aghast at the results whilst at the same time refusing to acknowledge the cause. Because it is deemed an uncompetitive strategy to pay to do it properly.
While I'd agree that we should aspire to raise our craft to an engineering level, there are few shops that even remotely have the discipline to be called "computer engineering". In most case - there is no science, no real stated functional definition, and certainly no reliability, performance or safety specs to speak of, so trying to assign "engineering" titles to those shops is an insult to true engineers.
IT these days looks more like a craft brewery where we keep changing the recipe: sometimes it works, and sometimes it's disgusting.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 17, 2015 at 11:21 am
IT these days looks more like a craft brewery where we keep changing the recipe: sometimes it works, and sometimes it's disgusting.
I'm tempted to make a comparison between American brewing and American coding, but shall refrain in the interest of trans-Atlantic comity.
February 17, 2015 at 11:22 am
But are most data breaches the result of SQL injection or even ad-hoc database access by outsiders?
From what I've seen, most of these massive data breaches are done by:
- sniffing unencrypted wifi network traffic (Google Street View)
- malware installed on retail POS terminals (Target)
- privilleged database users who dump a data load to a USB drive and then walk out the door (NSA and Defense Department)
- improperly designed website caching (HealthCare.Gov)
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 16 through 30 (of 75 total)
You must be logged in to reply to this topic. Login to reply