SQL Injection Is Not Acceptable

SQL Injection has been a problem for my entire career. Thirty years ago I could have easily just blamed this on ignorance, as most of our developers didn’t think about the nefarious ways that hackers enter data in our applications. These days, there isn’t a good reason for this to keep happening, and the problem is us. I think that we don’t provide good examples or training on secure coding or secure architecture as a normal part of teaching programming. In many organizations, we don’t check for issues and prevent their release. Some do, but many don’t. On top of this, the existing code is usually a poor template for writing future code. I do think Microsoft aims for secure coding in SQL Server but in Windows, there is work to be done there.

A few months ago, I saw an article that noted the US CISA organization and the FBI issued a secure-by-design alert (PDF) that noted there is no excuse for SQL Injection vulnerabilities (SQLi) in modern software. This alert notes that SQLi has been an “unforgivable vulnerability” since at least 2007. Inside the document on vulnerabilities, it notes that a single quote can’t be used in certain fields: username, password, ID field, or numeric field. They also note that co-mingling user data and query data, like constructing queries on demand, is a poor practice.

The alert even emphasizes that developers are engaging in poor practices when they “fail to treat user-supplied content as potentially malicious.”

I agree, and their recommendations are worth reading and implementing. If your boss doesn’t want to spend time on these, point out the bulletin and note that since this is a published advisory, I wouldn’t be surprised to start seeing lawsuits in the US or even insurance claim denials if your software team doesn’t follow these practices. Note that the list includes leadership support of secure coding and secure design principles.

I doubt this has changed a lot, but I think some managers likely see this as a) a good idea, and b) a way to mitigate potential issues down the road. Changing the habits of software developers, updating code snippets or patterns, and even adding linting/static-code-analysis to CI pipelines take time, as does the training for developers. However, it’s something that has to start changing over time to get better at building higher quality, more secure software.

I’d like to see insurance companies refuse to indemnify or cover losses or problems from software that is written from this point forward and is vulnerable to SQL Injection. There are far too many tools out, and software is too critical to allow these types of simple coding errors to proliferate. I’d also be pressuring companies to ensure older code is being actively refactored to reduce the number of vulnerabilities over time for all software they still support.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.

4 Responses to SQL Injection Is Not Acceptable

  1. SQLi has been and still is a huge problem with the accounting software predominantly used in my companies industry and frankly I doubt there will ever be any effort to address that until someone, possibly a client, gets massive punished monetarily because of it. Sadly business is often motivated only by hits to teh bottom line even when it involves customer safety/security. Every business that sells a product or service feigns “You’re business is valuable to us” but in reality it’s typically a few big clients that really have any impact on the vendor and in my industry I doubt any major players will push for having the accounting software vendor address this until they get fined heavily for something related to it. This is the downside to letting social morality decay, those in charge and who have influence don’t do things just because their the right thing to do any more.

    Like

    • way0utwest says:

      I don’t think this is any societal delay. History is full of companies sacrificing any number of things for profit. Going back to ancient times, it’s a very human thing to not care about the best thing for society over the best thing for me/my family/my company.

      I think insurance and legal actions are the best way to change things as individuals won’t change, the government can’t mandate this in any meaningful way, and companies won’t listen to pressure unless it’s wide swaths of their customers. Even then, customers moving to new companies just moves the problem to the new company

      Like

    • I say societal decay because 75-100+ years ago if a company did some of the things we just accept today their heads would have been shamed by others in their own circle into reversing course. Granted there were still bad actors but the problem has been made worse by a societal wide spread drop in morality.

      Like

  2. way0utwest says:

    Hardly. History shows plenty of more horrific things by companies not remotely shamed into changing.

    Morality hasn’t dropped. There are more people period, and hence, more bad actors. Visibility of stuff has also increased thanks to electronic media.

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.