The Unbearable Stubbornness of SQL Injection Vulnerabilities

On March 25, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) jointly issued a stern warning to software manufacturers stating that the time to eradicate SQL injection vulnerabilities for good is upon us.

This call to action reverberated across the digital landscape, prompting a flurry of reactions from the security community. As expected, security media outlets fell in line. They obediently reported about the alert, many making it the news of the day and only a few questioning the practicality or depth of the recommendations published.

Nokod Security commends CISA and the FBI for their efforts to distribute a secure-by-design philosophy and alert commercial software vendors. Still, we feel inclined to peel back some layers:

• Naming the alert “Secure by Design” is misleading, if not outright wrong. SQL injection vulnerabilities were never a software design problem but of the later coding and implementation phase in the software development lifecycle.
• We get it. The house was on fire, and priorities shift. This renewed effort to combat SQL injection flaws came in the wake of the Clop ransomware gang’s exploitation of such a vulnerability in the MOVEit file transfer software. The attack led to the exfiltration of data from thousands of corporate clients, impacting tens of millions of customers worldwide, and the Clop ransomware gang might have made up to $100m from its campaign.
• While practical recommendations were hard to find in the alert (besides the good advice to use parametrized queries – AKA prepared statements), the calls upon the senior management took center stage: Take responsibility, improve transparency, and unleash the coffers of resources.

Unasked questions and missed opportunities

What CISA and FBI didn’t do was ask the fundamental question, which immediately comes to mind, like here in this Cybersecurity Reddit: Why are SQL injections still a thing?

Despite being a well-documented and longstanding issue with known mitigations, SQL injection vulnerabilities persist as a common defect in commercial software. But is this all the result of the software industry’s complacency? It’s a pity that CISA and FBI didn’t address that question, initiate and sponsor new research, or compile existing sources.

How, with code scanners in place and ongoing security training for developers, does this problem persist? Here are some of our speculations:

• Err is human, and the more code developers write, the more mistakes are made.
• The more open-source code vendors use, the less control they have over the coding practices.
• As organizations become increasingly proficient in detecting and weeding out SQLi vulnerabilities in mature software, the market faces spikes of new attack risks when popular demand drives rapid adoption of emerging technologies that rely on less mature code. 

SQL injection attacks are evergreen for hackers, and with automated tools to search for and exploit SQLi vulnerabilities in their arsenal, launching an attack against any new targeted application is easy. It’s an attack where there’s everything to gain and nothing to lose. 

Brace of impact: SQLi in Low-code/no-code app development

The number of SQL injection attacks will not shrink, but entirely on the contrary. And we want you to be prepared for yet another wave.

While CISA and FBI call upon software companies and professional developers, a completely different cyber storm is approaching. By next year, it is expected that over 70% of apps will be developed using low-code/no-code app development platforms like Microsoft Power Apps / Power Automate, UiPath, ServiceNow AppEngine, Automation Anywhere, and many others. [Source: Gartner]

This means that most apps will never even go through the hands of a software developer. Instead, they will be created by citizen developers who are experts in the business processes they manage and automate but who might spell out SDLC as Scottish Digital Library Consortium or Student Diversity Leadership Conference.

So, the next peak of SQL injection attacks will be brought upon us by:

• The vast scale of citizen app development and people without security training
• The false – and dangerous – perception that SQL injections cannot happen in apps created on LCNC platforms
• The failure of the existing AppSec stack to deal with the LCNC development environment

Watch how Amichai Shulman demonstrated the problem of SQL injection attacks in low-code/no-code app development only a couple of weeks ago. By the way, he threw in an HMTL injection as well.