10 Reasons SQL Injection Still Works

After all of these years, SQL injection vulnerabilities still stand as an old reliable for attackers seeking to break into corporate databases.

"SQL injection is still out there for one simple reason: It works!" says Tim Erlin, director of IT security and risk strategy for Tripwire. "As long as there are so many vulnerable Web applications with databases full of monetizable information behind them, SQL injection attacks will continue."

Even though some recent data out from WhiteHat showed that SQL injection attacks bumped down from the top 10 most prevalent Web attacks in 2012, other data from Veracode saw SQLi attacks holding steady last year. And consensus from development, security, and IT consulting experts is that these attacks continue to expose enterprise databases on a daily basis.

[Why isn't DAM taking hold in the enterprise? See Five Hurdles That Slow Database Security Adoption.]

Beyond the obvious "hackers do what works" explanation, there are additional dynamics at play that keep SQL injection in the limelight. Among the top 10 most impactful reasons why SQL injection persists, experts named technical missteps, business process issues, and attack environment factors. Here's how they broke things down.

1. We're Maintaining Juicy Targets
"What if after executing a SQL injection attack and dumping the database, an attacker discovered that there wasn't very much of value there?" says Sandra Carielli, senior product manager of access and data protection at RSA.

According to Carielli, not enough organizations are engaging in distributed security -- in other words, they're putting all the eggs in one risky basket.

"If the data in the SQL database is encrypted, and the encryption key is sitting somewhere else, that's a form of distributed security," she says. "It's like taking a secret formula written down on a piece of paper, ripping it into multiple pieces, and storing each piece in a different safe."

Part of the issue is that SQL injection attacks generally yield very valuable pay dirt. If organizations did a better job of reducing the attractiveness of the target, that would greatly reduce the incentives for attackers to use that attack vector, she says.

2. At Least Go Least Privilege
In the same vein, SQL injection attacks remain an attacker favorite because so many organizations make it a cinch for attackers to dive deeper into the network following a successful injection attack. They do this by failing to follow the rule of least privilege within application accounts.

"Far too often applications use database logins that have complete administrator privileges, a perfect setup for SQL injection attacks," says Andrew Storms, director of security operations. "Web applications don't need administrative access to the schema -- they shouldn't be creating or deleting tables."

3. SQLi: Attacker's "Easy Button"
If ever there was a hacking equivalent to the Staples "Easy Button," it would be a SQL injection attack.

"Undoubtedly, SQL injection is among the easiest attack vectors at the application layer. All it requires is a quick user input alteration of a database query," says Bala Venkat, CMO of Cenzic.

And unlike other types of Web attacks, the resources necessary are limited to a single PC, says Ronen Kenig, director of security solutions at Radware.

"Other attacks require hackers to recruit a botnet of thousands of PCs or coordinate the attack with multiple users, both of which require more resources than those needed for SQL injections," he says.

4. Insecure Development Architecture
One of the big reasons why SQL injection maintains traction is due to improper development planning and the use of insecure development architecture, says Randall Agee, CEO of Allshore Global Resources.

"Protecting yourself from these attacks lies in the architecture and design in which a portal is developed, and there are many techniques which, individually or combined, can improve the security of a portal against SQL injections," says Agee. "Some techniques include proper validation of values being passed to the database through code checks, using stored procedure or pattern checks, or even extra security at the database level."

5. Trusting Input
Technically, the lack of many of those techniques Agee alludes to comes down to developers and their organizations putting too much trust into user input.

"Trust without verification is one key reason why SQL injection is still so prevalent," says Dwayne Melancon, chief technology officer for Tripwire. "Some application developers simply don't know any better; they inadvertently write applications that blindly accept any input without validation."

It's very similar to the principle that allowed Steve Wozniak to build the blue box in the 1970s that could give him and Steve Jobs the power to make free international phone calls by mimicking the sounds telephone infrastructure used to relay calls, says Andy Chou, co-founder and CTO.

"The designers of the infrastructure made the mistake of putting the voice signals -- the data -- into the same channel used to communicate control signals -- the controlling instructions," he says. "Nobody would think to make those odd signals, would they? SQL injection is a similar kind of mistake at a technical level."

In this case, it is the user's input being put into a database query, and if a developer uses string concatenation, "the equivalent of a copy and paste," Chou says, the user is in the driver's seat of writing the query.

If organizations want to decrease the risk of SQLi, then they need to sanitize input.

"Sanitizing input is often done on the front end, but data checks need to be taken into consideration on the processing side as well so that injection doesn't become 'unlikely' -- it becomes 'impossible,' says Lew Weeden, vice president of technology for RevTrax.

[Learn more about injection flaws and the flaws arising from this vulnerability at Black Hat. Attend The Art of Exploiting Injection Flaws.]

6. Agnosticism At All Costs
The allure of SQL, or the Standard Query Language, is the fact that it acts as a common language that works across database platforms. But that quest to keep application code database server-agnostic is a double-edged sword, says Dan Kuykendall, CTO of NT OBJECTives, because stored procedures or prepared statements are often specific to a database platform.

But both of these techniques separate code from data, says Eddy Dreger of Epco Technology Solutions, and are important in the prevention of SQL injection.

"Detractors may complain about lack of portability between DBMSes," he says. "However, assuming that 'code' has been properly abstracted and modularized away from "data," porting-related changes can be made quickly."

7. Legacy Code
According to Melancon, legacy applications are often a "ticking time bomb" for SQL injections. It's a sentiment often repeated by experts, who say that even if organizations follow best practices for their new applications, there are scores more already live with SQL injection vulnerability.

"When the Internet was new and scripting languages were dominant, most organizations were amazed to have the know-how to connect a database to a Web page," says Christian Gainsbrugh, lead developer for Big Step Consulting. "Little thought was given to security, and SQL injection as a exploit did not exist in most developers' minds. As such, these systems were not developed to take a variety of what are now very well-known attack vectors."

And at the end of the day, organizations would rather not change legacy code if they don't have to.

"Companies loathe changing legacy code. Touching the code is expensive, it requires a lot of testing, and it might break something that's already 'working,'" Chou says.

8. Code Samples Outdated
What's more, that legacy code doesn't just exist within live application, but also within sample code that programmers learn from and dip into.

"Most code samples from which programmers take their first SQL programs are vulnerable to SQL injection, so programmers grow to use the same techniques," says Amichai Schulman, CTO of Imperva.

If organizations use legacy technologies or components that promote construction of ad-hoc queries, then they're likely to increase their risk of SQL injection attacks, says Michael Zino, once a software architect and now the CEO of Yayme.com, a new social media platform.

9. Flaws Easy To Fall Through Cracks
As easy as it is for hackers to find and exploit SQL injection vulnerabilities, it is infinitely harder to find every single one of them that could potentially be targeted.

"We've known about SQL injection for decades, so why haven't we fixed it? The answer is that each and every query that uses string concatenation has to be mitigated one by one," Chou says.

In a study of millions of lines of open-source Java code released in a report a few months ago by Coverity, the firm showed that programmers overwhelmingly got their code right when it came to leaving off on-string concatenation. Only in about 2% of cases were user-controlled dynamic data concatenated into queries. But that slim percentage still leaves a huge attack surface.

"Over thousands of queries in a moderate- to large-size application, that 2% can result in a handful of SQL injections," Chou says. "All an attacker needs to do is find one of these, and you'll have millions of records stolen and a headline in Dark Reading."

10. Budget Shortfalls
The money factor inevitably comes into play when talking about SQL injection, says Gainsbrugh, who acknowledges that budgetary constraints are keeping the vulnerabilities alive.

"Ideally any organization writing new code should be doing code reviews to ensure that their code is not exploitable," Gainsbrugh says. "In the industry at large, this is very rarely happening, largely, in part, because it takes time, adds to cost, and the technology market these days is very competitive and cost conscience."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.