Feds to CIOs: Actively ask your vendors if they’ve done a SQLi audit...
Fix up, look sharp: Uncle Sam is running out of patience with tech firms shipping insecure software. Vendors? Get familiar with the phrase "query parameterization"...
Federal authorities are calling on technology vendors to mount a “formal review of their code to determine its susceptibility to SQLi compromises.”
CISA and the FBI said they actively “encourage all technology customers to ask their vendors whether they have conducted such a review.”
Their bullish joint advisory represents the latest indicator that federal patience with poor software security is running distinctly thin.
Both security researchers and cybercriminals frequently find highly exploitable SQLi vulnerabilities; often simply using freely available tools.
The Stack analysed over 90,000 CVEs in NIST’s NVD catalogue in early 2023. We identified a sharp rise in frequency of many of the top 25 most dangerous Common Weakness Enumeration (CWE)* types over the past five years, including both SQLi and cross-site scripting (XSS) vulnerabilities, suggesting perhaps that software vendors were pushing more and more software to market without effective QA happening.
The advisory is the first in a promised series intended to flag basic product security failures by vendors and comes as federal authorities progressively ratchet up pressure on software companies – fuel no doubt added to the fire by the fact that multiple government agencies have fallen victim to hackers exploiting vulnerabilities in commodity software.
Lest the thrust was not clear, the agencies spelled out that software vendors need to “take ownership of customer security outcomes…
“Software manufacturers should adopt the use of prepared statements with parametrized queries as a standard practice in software development,” CISA and the FBI added. (Parametrised queries are a technique that aims to separate the SQL query from the user input values, meaning user input values ultimately no longer contain executable code.)
“This should be enforced in their development environments via, for instance, development libraries that make the secure route the default one for developers and checks at the time of pull requests. Additionally, senior executives at software manufacturers must take accountability for the security of their customers starting by conducting formal reviews of their code to determine their susceptibility to attack,” the agencies said.
The advisory follows mass exploitation in 2023 by the Cl0p ransomware group of a SQLin vulnerability (CVE-2023-34362 – one of several SQLi bugs) in Progress Software's file transfer solution, MOVEit Transfer.
It comes the same day that CISA added another SQLi vulnerability to its “known exploited” catalogue: Fortinet FortiClient’s CVE-2023-48788. (Who else did you expect to be doing the walk of shame, c’mon?)
Matt Middleton-Leal, Managing Director EMEA at Qualys, told The Stack: “SQL Injection was first documented in 1998, and it was classed as an ‘unforgivable vulnerability’ by MITRE in 2007. Yet we still see software that is vulnerable to this kind of attack today. It’s common where application languages are not automatically set up to protect against bad inputs, or where those inputs are not sanitised before they hit the application. Sadly, this step is all too often overlooked…”
He added: “As security teams, we have to encourage developers to carry out threat modelling around their applications, so they are aware of the potential issues and then they can protect against them. We also have to provide automated ways to check for vulnerabilities like SQLi, so that developers can see where they have an issue and then fix the problem.
“[Organisations should be] testing any internal application that your team puts together for flaws around common vulnerabilities including XSS and SQLi. You should automate this so that tests can be conducted regularly and produce consistent results, as this helps you flag potential problems faster and reduce any false positives [and] look at how you provide these results back into your developer team – are these results that they are in control of and that they can manage as part of their workflows, or are they put into a queue for remediation alongside everything else?
He added tartly: “Just because you paid someone else to create your applications for you (or parts of them), does not mean they are secure.”
* CWEs are potentially exploitable weaknesses that can occur in architecture, design, code, or implementation. The CWE open standard dictionary is maintained by The MITRE Corporation. To create the "Top 25" list the CWE team assessed CVSS scores associated with each CVE record and CWEs associated with CISA's Known Exploited Catalog and applied a formula to score each weakness based on prevalence and severity. The Stack then ran a search for these top 25 most dangerous CWE types in NVD's CVE database over the five years up to 2022.
