Skip to content

CISA asks software devs to stamp out ‘unforgivable’ SQL injection vulnerabilities

CISA asks software devs to stamp out ‘unforgivable’ SQL injection vulnerabilities

On Wednesday, March 27, CISA and the FBI issued a cry for help: We need to stamp out SQL injection vulnerabilities, and we need to do it yesterday, they said in a joint Secure by Design alert aimed at any and all software manufacturers that continue to develop products with this defect. 

… A defect, mind you, which is 26 years old and continues in its starring role on the OWASP Top 10 list of the most critical security risks to web applications. 

The cry for help was fueled by the recent, widely covered exploitation of the CVE-2023-34362 MOVEit vulnerability by the CL0P ransomware gang, the Cybersecurity and Infrastructure Security Agency (CISA) and the FBI explained in Wednesday’s advisory. In June 2023, U.S. feds were so eager to get to the gang, they put up a $10 million reward for clues that might help them track down the crooks who punched holes in networks worldwide, affecting thousands of organizations.

SQL injection: An ‘unforgivable’ vulnerability

“Despite widespread knowledge and documentation of SQLi vulnerabilities over the past two decades, along with the availability of effective mitigations, software manufacturers continue to develop products with this defect, which puts many customers at risk,” the advisory states.”Vulnerabilities like SQLi have been considered by others an ‘unforgivable’ vulnerability since Contrast Security Co-founder and Chief Technology Officer Jeff Williams put it in the first OWASP Top 10 list in 2002. Despite this finding, SQL vulnerabilities (such as CWE-89) are still a prevalent class of vulnerability.”

What is SQL injection? 

SQL injection simply means that a developer passed untrusted data to a database function.  This call may not be obvious, as it might happen deep in a library or as part of the application framework. Unfortunately, unless an organization is using Runtime Security to protect web applications in production, they’re compromising their ability to stop attacks that prey on these extremely common vulnerabilities. 

This can be true even if organizations have swaddled themselves in Application Security (AppSec) tools.  For example, Static Application Security Testing (SAST) struggles with SQL injection because doing data flow analysis (DFA) statically is highly error prone. Dynamic Application Security Testing (DAST) tools may not stumble on the exact right exploit to trigger detection.  And web application firewalls (WAFs) are unlikely to have a signature for all the possible ways to attack the targeted function.

Risks associated with SQL injection attacks

The risks are capital-B Bad. You can see why the Feds dangled a cool $10 million in exchange for finding the CL0P gang. Possible scenarios: 

  • A bad actor hacker performs an SQL injection to delete data or tables from the database. In this case, even if there are database backups, deleting the data can affect the application’s availability until the database can be restored. Further, backups may not include recent data. 
  • Attackers use SQL injection to alter or update data in the database and add additional data. For instance, in the case of a financial application, an attacker can use SQL injection to change account balances. Even worse, attackers can gain administrative rights to an application database.
  • The most common risk of an SQL injection attack is the theft of user data. Email addresses, login credentials and personally identifiable information (PII) can be stolen and sold on the dark web. Therefore, a successful SQL injection poses a threat not only to the organization but also its users. 

Even after 26 years since SQL injection discovery, SQLi vulnerabilities remain one of the primary concerns when it comes to a data breach and security of data.

Thanks for the free ad, CL0P

Talk about a public service announcement for Runtime Security.   

Contrast tackles the root cause of AppSec  issues such as SQLi by automatically introducing security checks into powerful dangerous functions.  We call these checks “Contrast Trust Boundaries,” and they operate a bit like mini-firewalls around these functions. Our Trust Boundaries prevent these functions from being misused by attackers in production.  And those same Trust Boundaries also warn developers immediately when functions are used unsafely or insecure libraries are used.  

Specifically with regards to SQLi, we add boundaries to all the functions that send queries to the database. If we track any data from the user that hasn’t been properly escaped or parameterized into those methods, we know there’s an exploitable SQL injection, and we instantly warn the developer. In production, if that data changes the meaning of the query, we know it’s an attack, and we prevent the exploit.

Read about eliminating SQLi the Contrast way

Zero days blocked before discovery — Contrast protects those same functions in production in order to prevent both known and unknown vulnerabilities from being exploited.  As a result, Contrast has a long record of successfully preventing zero days before they were officially discovered (prior to CVEs being issued). Examples of zero days that were blocked by Contrast include the Struts 2 Path Traversal, where files and directories were made accessible to external parties; the Spring/Kafka deserialization that opened risks to remote code execution (RCE); the Spring4Shell command injection/ClassLoader manipulation; and the widespread Log4Shell exploit that used expression language injection.  

Zero Days Blocked Before Discovery Hall of Fame

In fact, we have a Hall of Fame to track just a few of the bigger zero days we’ve blocked before they were discovered.  Sometimes years before they were discovered.

Check it out:

​​CVE-2023-22527 Atlassian Confluence – Template Injection

CVE-2023-34040 Spring/Kafka – Unsafe Deserialization

CVE-2023-22965 Spring4Shell – Malicious Data Binding

CVE-2021-44228 Log4Shell – JNDI Injection RCE

CVE-2021-26084 Atlassian Confluence EL Injection

CVE-2020-17530 Apache Struts2 – EL Injection

CVE-2020-11651 Python Salt – Authentication Bypass

CVE-2020-11652 Python Salt – Directory Traversal

CVE-2020-9484 Apache Tomcat – Unsafe Deserialization

CVE-2019-2725 WebLogic – Unsafe Deserialization

CVE-2019-0230 Apache Struts2 – EL Injection

CVE-2018-11776 Apache Struts2 – EL Injection

CVE-2016-0792 Jenkins XStream – Unsafe Deserialization

… which is all well and good, but as our Co-founder and Chief Technology Officer Jeff Williams points out, “The overwhelming majority of attacks and breaches are due to known vulnerabilities, not exploitation of zero days.” 

CISA and the FBI urged executives of technology manufacturing companies to prompt formal reviews of their organizations' software and implement mitigations to eliminate SQL injection (SQLi) security vulnerabilities before shipping.

We can show you how to eliminate entire classes of vulnerabilities. Join us on a no-pressure, no-commitment demo call. 

Get a Demo

Read more:

Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas is a content machine, having spent years churning out reporting and analysis on information security and other flavors of technology. She’s now keeping the content engines revved to help keep secure code flowing at Contrast Security.