Application Security // Database Security
5/8/2013
00:28 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

10 Reasons SQL Injection Still Works

Developer techniques, business process choices, and attacker preferences all play a part in the continued relevance of SQLi

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. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
notsosecure
50%
50%
notsosecure,
User Rank: Apprentice
5/8/2013 | 8:56:28 AM
re: 10 Reasons SQL Injection Still Works
Learn Advanced SQL Injection and other lesser known injection flaws such as LDAP, XPATH, HQL, XXE etc at Black hat 2013. 2 days hands on training: https://www.blackhat.com/us-13...

Identify, Extract, Escalate, Execute...!
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-7298
Published: 2014-10-24
adsetgroups in Centrify Server Suite 2008 through 2014.1 and Centrify DirectControl 3.x through 4.2.0 on Linux and UNIX allows local users to read arbitrary files with root privileges by leveraging improperly protected setuid functionality.

CVE-2014-8346
Published: 2014-10-24
The Remote Controls feature on Samsung mobile devices does not validate the source of lock-code data received over a network, which makes it easier for remote attackers to cause a denial of service (screen locking with an arbitrary code) by triggering unexpected Find My Mobile network traffic.

CVE-2014-0619
Published: 2014-10-23
Untrusted search path vulnerability in Hamster Free ZIP Archiver 2.0.1.7 allows local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse dwmapi.dll that is located in the current working directory.

CVE-2014-2230
Published: 2014-10-23
Open redirect vulnerability in the header function in adclick.php in OpenX 2.8.10 and earlier allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the (1) dest parameter to adclick.php or (2) _maxdest parameter to ck.php.

CVE-2014-7281
Published: 2014-10-23
Cross-site request forgery (CSRF) vulnerability in Shenzhen Tenda Technology Tenda A32 Router with firmware 5.07.53_CN allows remote attackers to hijack the authentication of administrators for requests that reboot the device via a request to goform/SysToolReboot.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.