WepAppSec: The reality of Web development and security

Rafal Los, a senior WebAppSec (Web Application Security) specialist at HP, recently offered a room full of developers and executives live proof of why application development needs to have security built in. He spoke with us earlier today, explaining a recent SQL Injection discovery, as well as some reasons as to why SQL Injection exists in the first place. 

Despite the amount of news and information that is available to Enterprise operations and development teams the world over centering on application security, many of those teams still take one of the following stances: it isn’t important, we don’t have the funding, or that “it can’t happen to me”.

The reality is that unless the code is checked and rechecked, any forward-facing Web application is vulnerable to a number of attacks online. The aftermath is what hurts the most, considering the potential business losses, recovery expenses, and loss of face in the public eye.

The 2010 Top 25 Most Dangerous Programming Errors list, put together by CWE and SANS [Link] counted SQL Injection (SQLi) as number two on the list. SQLi issues are constantly mentioned when discussing WebAppSec. So we asked Los why it's such a consistent problem.

He explained that some of the cause is due to the nature of Web development. Outsourced development or internal development, the basic problem remains the same. In short, developers are inherently paid to write code in a timely maner.

While many skilled developers know how to include security in the design, they often are restricted by several factors. In the case of outsourced development, one restriction is project turnover. As the number coders who touch the code grows, the different styles of programming will introduce potential pitfalls. In the case of internal development, those different coding styles exist as well, and include the same risks.

“Applications are getting too complex,” Los explained. “Even if the development teams do know how to code securely, there is too much code to keep track of.”

The average Web application of medium complexity has several million lines of code. “You can’t audit this, let alone secure it,” he explained.

In context, this makes sense. Yet, it makes things tough for the developers when you consider the stress of producing a finished product on time and under budget, while known security factors hang over their heads.

Security pundits and professionals would like to think that a business would have their Web application tested by the best minds in the WebAppSec world. The reality is that companies will go with what they can get away with, and what is most affordable.

Sometimes development teams do have security people as part of the mix. However, more often than not they are QA staffers who have the added task of security testing. While they may be enthusiastic, and knowledgeable of several attack methods and mitigations, they are not solely focused on WebAppSec. Eventually they will miss something through no fault of their own.

“It takes somebody that is more than a security enthusiast to test and check the applications properly. Most companies don’t have that,” Los noted.

Live demonstrations of SQLi vulnerabilities leave the best impression. If you talk about them, and only talk, some executives and developers will remain skeptical. However, show them such vulnerabilities on their own systems, and there is a change of opinion.

This is exactly what happened during a talk Los gave recently. It was a tough room, full of crossed arms and disbelieving faces, but he was attempting to stress that vulnerabilities such as SQLi were real, and they existed on most websites. One of the crowd commented, “I'm just not convinced we have developers that write such terrible code, and even if they did, I don't see how all this complex attack stuff would even get them anything.”

Los suggested a live test of a production server, so that any potential issues would prevent serious downtime and loss. A URL was offered up and Los went to work. After some digging, he discovered – within minutes – exactly what was needed to execute an SQL Injection attack.

With prompting from those watching the talk, he dug deeper and discovered not only was the production site vulnerable, it had already been exploited. The exploitation was serious, further investigation showed, as the site was serving pages with embedded JavaScript, linked to the Zeus Trojan.

The room watched as proof was presented to them that, not only were they vulnerable to attack, they were attacked, and as a result Malware was being offered up to anyone who would happen across that site.

We asked Los what the reaction was to the demonstration. A three stage reaction ensued. “It went from curiosity, to panic, then to sheer terror,” he said. Naturally, the meeting soon ended as the various developers and executives went into recovery and cleanup, as they now had an active threat to deal with.

The lesson from the demonstration is a simple one. Los used a common SQLi attack vector to exploit the flaw. As such, the problem could have been avoided by following established WebAppSec practices, and if the code itself was thoroughly checked for input flaws.

“I’d love to tell you that finding sites that are broken or already hacked is a rare occurrence, but it’s not,” Los told us, and explained a similar incident in 2008.

During a software quality conference in Vegas, Los spoke to a room full of military types. “I started talking about high level risks,” he said, mentioning that he noticed a military man in the back of the room who looked skeptical. Eventually, the man spoke up and stated those skepticisms.

The skeptic wouldn’t offer his own site for testing, but volunteered the site of a supplier he used, who just happened to be in the room at the same time. After testing for about ten minutes, Los was viewing the skeptic’s recent order on the supplier’s site, no authentication needed.

When it comes to SQLi mitigations, many seasoned developers or those knowledgeable of the attack methods often mention Prepared Statements as a solid defense.

However, when asked if this was the case, Los explained said that, “Yes but it has to be done intelligently,” he said. “I’ve seen cases where Prepared Statements used ad-hock data, and were still broken.”

One example of an ad-hock blunder would be prepared statements that take user content directly, which defeats the purpose of using them entirely.

It’s proven that developers who code with security in mind make stronger, more resilient applications. The problem is that developers can only do so much on their own, and as the business model pushes them for results, security is often seen as something to add after the fact.

There are experts to audit the code, but as that codebase grows, it becomes an impossible task to do so, hence the need for automated solutions. At the same time, the automated solutions have their limits, and they could never replace skilled developer’s eyes. This is why most experts agree on a happy medium that uses automation and solid development practices.

Yet, is there any real solution to defeating SQL Injection?

The only real solution is to know what data the application is expecting, accommodate that, and throw away everything else, Los told us.

“There’s no magic solution to SQL Injection, if there is I’ve yet to see it.”

Like this article? Please share on Facebook and give The Tech Herald a Like too!