New Study Shows Nearly No Difference in Security of Web Frameworks

A new study by a Web security firm has found that despite the myriad differences in the common programming languages and frameworks deployed on the Web today, there is virtually  no difference in their practical security and resistance to attack.

A new study by a Web security firm has found that despite the myriad differences in the common programming languages and frameworks deployed on the Web today, there is virtually  no difference in their practical security and resistance to attack.

The study, done by WhiteHat Security and based on statistics gathered from nearly 1,700 sites owned by the company’s customers, shows that the choice of Web development environment is just one of many elements that contributes to the overall security of a site–and may not even be near the top of the list of important factors.

“Technically speaking, one Web programming language / development framework can be made basically just as secure (or not) as any other. Empirically, languages / frameworks only show moderately varying security characteristics, such as the classes of attack to which they are
most prone, how long they tend to be vulnerable, and so on. From a security posture perspective however, the languages / frameworks appear more the same than different. As such, we concluded that an organization’s chosen website development technology alone does not guarantee application security success (or failure) — many other factors must be considered,” the study concludes.

“That was the really big takeaway for me. They’re all pretty bad once they get into production, and the difference when they get into production isn’t great,” said Jeremiah Grossman, the CTO of WhiteHat. “Some of these languages and frameworks have more security mechanisms built in than others do, but it’s questionable whether people use them in the field. There’s a difference between theory and practice.”

WhiteHat, which specializes in helping enterprises secure their Web applications, analyzed data on a number of the more popular Web development frameworks and languages, including Microsoft .NET, ColdFusion, Struts, Perl and others. The information on which applications had which vulnerabilities, how long those vulnerabilities were open and how severe the flaws was collected from the thousands of sites owned by WhiteHat’s customers.

The company found that the distribution of certain kinds of vulnerabilities across the spectrum of languages and development frameworks was quite interesting. For example, more than 80 percent of sites written in Perl contained at least one cross-site scripting vulnerability, while the number of .NET sites with the same kind of flaw was about 50 percent.

Unsurprisingly, WhiteHat’s data shows that enterprises are taking their time when it comes to remediating vulnerabilities in their Web applications. The company looked at data from the last 12 months on the most common classes of vulnerabilities identified and fixed in Web applications. Remediation of common flaws, such as XSS or SQL injection, can take days, weeks or even months, the study found.

“Across essentially all classes of attack, remediation requires weeks to months. In today’s threat landscape, where most incidents are Webbased, this average response time is not nearly fast enough. This signifies a need for organizations to improve their capability to monitor incoming attacks and respond to verified vulnerabilities. Unless a software security development lifecycle effort can guarantee perfection, which it can’t, organizations must be prepared to react
appropriately without being operationally disruptive. We have seen several cases where issues have been fixed within a 24 to 48 hour window, through prioritization and use of tools like Web Application Firewalls, demonstrating that it is possible,” WhiteHat found.

Grossman said much of this problem can be put down to the competition for internal resources in enterprise IT departments.

“There’s a bargaining for resources that takes place,” he said. “A lot of these applications are custom code, so there aren’t patches available for them. They have to develop the patches internally and they have to negotiate for development resources. The questions is, do we spend time on pushing this potentially money-making feature or do we develop a patch for a flaw that may not get exploited? The security teams have to educate the development groups, and there’s a knowledge and respect gap, as well.”

Suggested articles