Given the ongoing cybercriminal interest in SQL injection flaws, organizations may need to be asking themselves what they are doing to improve this aspect of software security.

Experts say more code review, better design is needed to catch SQL injection flaws

on May 28, 13 • by Chris Bubinas • with No Comments

Given the ongoing cybercriminal interest in SQL injection flaws, organizations may need to be asking themselves what they are doing to improve this aspect of software security...

Home » Code Review » Experts say more code review, better design is needed to catch SQL injection flaws

The SQL injection attack has been a core part of the hacker tool set for years, and, despite increased awareness, its prevalence continues unabated. In fact, injection flaws recently topped the Open Web Application Security Project’s list of the top 10 vulnerabilities. A 2012 study from data security firm Imperva found that SQL injection attacks, along with DDoS attacks, were one of the two most frequently discussed topics on hacker forums. Given the ongoing cybercriminal interest in SQL injection flaws, organizations may need to be asking themselves what they are doing to improve this aspect of software security.

Fundamental to the ongoing prevalence of SQL injection flaws is the fact that they reliably work, a recent Dark Reading article noted. They are also among the easiest attacks to perform, as they require little in the way of computing resources: As opposed to distributed attacks that require massive botnets, for instance, a single desktop can deliver the altered input needed to carry out an SQL injection attack. Given the volume of valuable information in databases underlying applications, hackers have a tempting target, and factors ranging from poor code design, unsecure legacy code and limited code review ensure that there are plenty of vulnerable entities.

Enduring SQL injection problems
Several ongoing design issues contribute to the persistence of SQL injection attacks, Dark Reading reported. One of the biggest problems is that developers tend to trust too much in user inputs instead of taking steps to sanitize them on both the front end and the processing side.

“Trust without verification is one key reason why SQL injection is still so prevalent,” Dwayne Melancon, CTO for security firm Tripwire, told Dark Reading. “Some application developers simply don’t know any better, they inadvertently write applications that blindly accept any input without validation.”

Even if developers are cautious about the way they treat inputs, though, their predecessors were often not. Legacy code remains a significant challenge in preventing SQL injection attacks, as many early applications never anticipated the possibility of such incidents, Christian Gainsbrugh, lead developer for Big Step Consulting, told Dark Reading. The technical marvel of tying an application to a database outweighed early security concerns.

Now, organizations hesitate to alter legacy code if they can avoid it due to the cost and the possibility of breaking it, Dark Reading noted. As a result, many errors persist. Furthermore, these legacy code bases remain the reference points for developers learning to build SQL programs.

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

Catching SQL injection flaws with code review
Additionally, catching and preventing SQL injection vulnerabilities remains difficult, experts explained. Finding every single instance in a program is time consuming, and the queries that use string concatenation have to be addressed individually. One study found that programmers only mistakenly enabled concatenation in around 2 percent of cases, Dark Reading noted. However, over a code base that includes thousands of queries, those oversights can leave a number of vulnerabilities for an attacker to exploit.

Companies could do more to catch these remaining cases with tools such as code review, Gainsbrugh told Dark Reading. The chief impediment, however, is often budgetary pressure.

“Ideally any organization writing new code should be doing code reviews to ensure that their code is not exploitable,” Gainsbrugh told the publication. “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.”

Organizations can control these costs by leveraging tools designed to streamline peer code review or using source code analysis software. By taking these added steps in the development process, businesses can limit the likelihood of SQL injection flaws in their applications and protect themselves against one of the most popular cybercrime tools.

Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top