CISA: What to do about SQL injection
Yes, we've been saying that for 20 years, it's not going to change because CISA says it
CISA has published a document about SQL injection. I have some comments. Namely, the document tells you what to do, making the same statements we’ve been telling you what to do for 20 years. If it hasn’t already worked yet, it’s not likely to work just because CISA says it.
The document should be praised for giving correct advice, namely that the solution is “parameterized queries” rather than “input sanitization”. But that’s the only good thing about the document.
An example what we are talking about is pasted queries vs. parameterized queries. The two differences can be seen in this ChatGPT example. The first example simply pastes data plus code together, making them indistinguishable. In other words, if the data also contains code, the database will run that code, too. They hacker can then “injection” their code by supplying it in data parameters. The second example keeps data separated from code all the way to the database, such that the database won’t get confused.
In the above example, ChatGPT gave the vulnerable answer in response to my question. I didn’t get a safe parameterized query until I specifically asked for it. This is the true problem.
The underlying problem is that if you read a textbook or take a class in college on how to build websites, this is the example they give you. In other words, they teach you to write vulnerable websites by defaults.
They do mention the SQL injection flaw, but only as some theoretical idea that might affect your website. No, no, no. The above example produced by ChatGPT isn’t “risky”, it’s “hackable”. Hackers can hack it right now by injecting code. It’s 100% certain that hackers have full control over your database. The only uncertainty is whether hackers can find you.
This is what makes cybersecurity professionals crazy. They tell the developers that it can be hacked, they demonstrate the hack in front of the developers, but the developers still think it’s merely a theoretical risk. After all, it’s been deployed for months and there is no problem, so why are you cybersecurity people so upset?
So imagine you are an executive at the company. You quickly lose faith in the cybersecurity professionals claiming it’s an immediate problem and instead trust your developers who claim it’s no problem — because the developers are proven right.
Moreover, when you hire more developers, like those fresh from the university, it’s they way they all develop websites. Much of your website is third party products, and they all are built the same way as well.
CISA’s document is the same vein. It’s crap. Its moralizing/political nonsense about “Secure by Design” instead of focusing on the specific problem. When it gets into specifics, it fails to empathize with the organizations confronting the problem and understanding their difficulties. It simply tells them what to do without real any explanation why.
I don’t know how to solve SQL injection in the face of these realities. I know some things are part of the solution.
The first is to stop schools/textbooks from teaching students to paste together code. As long as we keep pumping out new workers taught to create websites like this, they’ll keep doing it.
The next is to address the process. Only fixing the “dangerous” queries, while leaving the paradigm of pasted queries intact, is expensive and ineffective. It means every change to the code needs to be reviewed to see if a vulnerability has been introduced, and some will go unnoticed. On the other hand, if there is a hard rule like “no pasted queries”, getting rid of the query() function in PHP, is really easy to manage. It’ll annoy the website developers, but it’ll be both effective and cheap to implement.
I’m not saying organizations should do this, I’m saying that I don’t know anyway to address the problem without doing this. Any statement like CISAs telling people what to do without empathizing with their problems, without explaining why, is fundamentally broken. I’m trying to point out that companies like MOVEit (mentioned in the CISA document) already know about SQL injection, already had processes in place to prevent it, but still allowed pasted queries. Their processes probably involved sanitization and tracking “taint”. I’m saying that I don’t think this can work, and that I think forcing all queries to be prepared statements will work.
The upshot is this: the CISA document tells people to do, repeating the same language we’ve been telling people to do for 20 years. That language hasn’t helped yet, and isn’t going to help simply because CISA says it.