SQL Injection, Still?

  • 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.

  • Thanks for the idea for a great topic for an upcoming user group meeting.

    Now, Just need to find someone to present it.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for 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]

  • 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.

  • 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.

  • 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.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for 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]

  • 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.

  • 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

  • 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.

  • 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!!!

  • 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..

  • 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.

  • 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.

  • 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?

  • 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.

  • 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