Myth-Busting SQL- And Other Injection Attacks

While different security researchers may haggle over the exact ranking of SQL injection attacks compared to other common maladies, such as XSS and CSRF, few would deny that SQLi and its other injection-attack cousins are kicking enterprise applications and databases in the collective rear end.

"Injection flaws still remain the most ridiculous problem in application security," says Sumit "Sid" Siddharth, head of penetration testing for 7Safe Ltd. in the U.K., and blogger for notsosecure.com, pointing to the continued No. 1 position these flaws maintain on the OWASP Top 10 list for 2013 as evidence of the severity of the problem.

An experienced pen tester who has dedicated a fair amount of his free time researching server-side security flaws, Siddharth has seen his fair share of examples of how injection attacks have been used in the lab and in the wild to wreak havoc on databases. He's compiling his knowledge in a two-day training at Black Hat USA dedicated solely around injection attacks.

Dark Reading caught up with Siddharth recently to get his thoughts on injection attack hot-button issues and for a few teaser highlights on what he plans to cover at the conference later this summer. His bottom-line premise is that many real-world injection attacks are more sophisticated than developers and security pros may have been led to believe, which means that a lot of pat answers brought to the table as easy fixes don't always work as advertised. He emphasizes that as much as tools and approaches have improved, organizations can't totally automate injection defense, and they need to employ advanced thinking and problem-solving to test for injection vulnerabilities they may not have thought of.

[Why does SQL injection linger? See 10 Reasons SQL Injection Still Works.]

"If you look at some of the case studies of SQL injections in the wild, they have not been the very simple put-in-the-code-in-and-the-application-falls-for-it [kind of attack]," Siddharth says. "They've been fairly complicated and sophisticated attacks."

For example, one case study he likes to point to is a WordPress vulnerability that attackers went after in 2009. Siddharth says the problem with WordPress was in the way a certain part of the application was taking users' input, going through input sanitization, then decoding and using the decoded input in a SQL statement, rather than the proper way of doing the decoding first, followed by sanitization and then using the information in a SQL statement.

"Because these steps were in the wrong order, what an attacker was able to do was send an imported string, which was an encoded piece of SQL injection, to the application," Siddharth says. "The application when it tested sanitization was not able to find the attack pattern -- but when it decoded the input, then suddenly the attack pattern emerged. And when this pattern was used in the SQL statement, suddenly vulnerability was triggered."

So it wasn't necessarily that there was no sanitization in place, but that the sanitization didn't occur at the proper time to prevent an injection attack from occurring. Siddharth says that he sees many examples of misapplied SQL injection prevention measures and techniques giving application and security professionals a false sense of security.

For example, many developers lean on the approach of blacklisting coding connectors as a primary defense against SQL injection.

"While it might help to safeguard your application against some script kiddie attacks, an attacker with more knowledge of the system of how the back-end SQL works will be able to bypass these checks and still carry out the exploitation," he says.

Similarly, Siddharth believes that organizations shouldn't buy into the "myth" that stored procedures and prepared statements are always a slam dunk for SQL injection protection.

"What we try to convey to people is that these methods are all good, but try to understand why a prepared statement or stored procedure is not reliable," he says.

Meanwhile, while tools have made it possible to automate a great deal of SQL injection testing, they have their own set of limitations.

"Not only have the number of tools which we have available in our industry increased, but so have their quality," Siddharth says. "And while this is all good, it is important to understand the limitations of any tool."

For example, if an organization is running a full-fledged application scanner, then it should be considering the implications of running it against an authenticated session and, most importantly, whether the tool is actually seeing what a manual attacker will see.

"That is the most important question and, in most cases, it is very difficult or nearly impossible to configure a tool that [equals] pen testing in any of their applications," he says, explaining that each application is so different that scaling to that becomes a problem.

And then there is the issue of determining the difference between a false positive and a real positive. This is particularly an issue in BURP, a tool that Siddharth considers one of the best in the arsenal for SQL injection testing out in the wild. But there are a number of checks for which BURP regularly crops up a number of false positives -- to the point where some testers could become complacent.

"We should not just go through the motions every time BURP complains about this particular check to find SQL injections [and assume] a false positive," he says. "Maybe nine out of 10 times this particular check will be really annoying, and it will be a false positive, but this one time out of 10 it is not a false positive, and you may have failed to report a valid SQL injection. That, to me, is a crime."

Siddharth also believes organizations would be doing themselves a disservice by not taking the lessons about injection attacks learned from SQLi and applying them elsewhere because, as he puts it, there is a whole world of injection attacks beyond SQL. In fact, half of his upcoming class is dedicated to other injection types, such as LDAP, hibernate query code, and XPATH.

"The bottom line here is that these attacks have the same pattern: that the developer used unsanitized input in making the back-end calls," he says, "whether it is SQL or any other systems like LDAP or a back-end XML document."

One particularly dangerous injection type he believes more developers and pen testers should have on their radars is through XPATH 2.0. Used to query XML documents, XPATH has long provided hackers the means to manipulate the output on a screen, extract the entire back-end XML document, and reconstruct the entire XML document just like in a blind SQL injection.

The vulnerabilities have only been exacerbated by new additions to the XPATH 2.0 library, which "brings a lot more functionality into the picture," Siddharth says.

"Some of these functionalities can actually aid the attacker in doing a little bit more than what a conventional XPATH attack would do," he says. "An attacker can carry out the same attack in a much more effective and quick way -- he needs to send fewer amount of queries to extract the entire XML file."

What's more, new functions in XPATH 2.0 make it possible for attackers to not only read the current XML file under attack, but any arbitrary XML file on the system.

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.