| 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 - SSC Editor Join the debate, and respond to today's editorial on the forums | 
