For more than a decade, injection vulnerabilities have literally topped the charts of critical software flaws, deemed more severe than all other vulnerability types in the 2010, 2013, and 2017 top 10 lists maintained by the Open Web Application Security Project (OWASP ). .
However, the warnings failed to eliminate the problems. Last year, the Cl0p group stole data from companies using a previously unknown SQL injection (SQLi) vulnerability in the MOVEit file transfer application. In late March, the Cybersecurity and Infrastructure Security Agency (CISA) called on companies to redouble their efforts to eliminate the security flaw, which application security experts believe one of 13 different classes of “unforgivable” vulnerabilities. that programmers should acquire during development.
“Despite widespread knowledge and documentation of SQLi vulnerabilities over the past two decades, along with the availability of effective fixes, software vendors continue to develop products with this flaw, which puts many customers at risk,” the agency said in its advisory of March 25th. “Vulnerabilities like SQLi have been considered by others to be an ‘unforgivable’ vulnerability since at least 2007.”
The root of injection vulnerabilities is the lack of input sanitization; when your application receives variable input, there’s always a risk that that input will be contaminated, says Randall Degges, developer relations manager at application security firm Snyk.
“Although this has been a problem for as long as programming has existed, the reason it is still in the top 10 vulnerabilities after all this time is because there are an infinite number of ways to use input, and often time purification is complicated,” he says.
For software developers looking to solve this particular problem, here’s how.
1. Educate yourself and others
The first step is always education. OWASP Offers SQLi cheat sheet, how to detect vulnerability, and ways to create secure code. Some web application frameworks aim to instruct developers as they code, using Application Programming Interface (API) names to make the risk of certain functions clear, such as “dangerouslySetInnerHTML” says James Kettle, director of research at PortSwigger, an application security testing company.
Developers also shouldn’t necessarily trust creators of open source software – especially components that haven’t been well vetted – to use secure code, and even online tutorials are often unsafe, he says.
“I think the main problem is that there are a lot of insecure APIs, where anyone using the API is vulnerable by default,” Kettle says. “Even when more modern secure APIs are available, new code is written using the insecure versions, thanks to the old insecure examples in StackOverflow.”
2. Strengthen your DevOps pipeline using automated tools
Developers should implement unit tests to check for SQLi defects in code and other common security issues during development, add static application security tests (SAST) both before and after commits, and include scans for SQLi as part of the tests Dynamic Application Security (DAST) ).
You can add unit tests using frameworks like tSQLt to test Microsoft SQL Server, pgTAP for testing applications using PostgreSQL and Pytest and SQLAlchemy for unit tests in Python programs. A variety of Best practices for SQL unit testing should be followed to make tests more useful, for example by isolating SQL tests from dependencies and avoiding descriptive test names.
In addition to automated testing in the development pipeline, developers should make sure to use SQL frameworks, such as SQLAlchemy, because many security improvements are already built in, says Snyk’s Degges.
“Virtually all modern SQL frameworks and tools provide practical methods to help with this nowadays, so your best bet is to carefully read the relevant framework’s documentation to ensure you’re using it correctly when building queries,” he says.
3. Play with SQLMap
THE SQLMap open source program is a great tool for penetration testers to experiment with SQLi, exploit any vulnerabilities, and download a database to demonstrate that the vulnerability can be exploited. The tool can also educate application developers about the true dangers of SQLi and how to exploit vulnerable code.
However, the tool isn’t necessarily the best way to spot potential vulnerabilities, PortSwigger’s Kettle says.
“In my experience, detection capabilities are slow, cumbersome, and prone to false positives,” says Kettle. “It also cannot scan websites to find the attack surface, which is one of the biggest challenges in automatically finding these vulnerabilities.”
4. Consider a DAST service
Automating SQL injection scanning using DAST as part of the quality assurance phase – and even earlier in the DevOps pipeline, if possible – can help spot any overlooked vulnerabilities. Also, DAST scanning is a good way to find SQLi in legacy code.
While Web application firewalls (WAFs) can prevent SQLi attacks from reaching an application, they should only be used as part of a defense-in-depth strategy, Kettle says.
“Personally, I’ve seen runtime protection like WAFs ignored so many times that I don’t have much faith in them,” he says. “I would instead recommend a bug-bounty program as an effective way to surface undetected vulnerabilities and use WAFs as a last resort for systems that are in such bad shape that known vulnerabilities cannot be fixed.”
5. Expand Beyond SQL
Finally, companies should also look for other types of injection vulnerabilities and ensure their developers recognize risky patterns, as SQLi is only one class of injection vulnerability.
OWASP has expanded the definition of an injection vulnerability to any software flaw in which user-supplied data is not validated or sanitized by an application and then sent to an interpreter. Cross-site scripting, SQL, operating system scripting, and Lightweight Directory Access Protocol (LDAP) parsing are all areas that can be vulnerable to injection.
With the advent of artificial intelligence models, for example, prompt injection is the latest form of injection attack.