Web Applications still posing risk while businesses shift funds elsewhereby Steve Ragan - Apr 30 2010, 20:35
Web Applications are quickly becoming the redheaded step-child of the business world, based on a recent study from the Ponemon Institute and practical lessons by researcher Rafal Los. While the idea that WebAppSec is another layer of consideration for business continuity is nothing new, actually making it happen is another matter entirely.
Previously, Rafal Los talked with us about WebAppSec (Web Application Security) where he explained a few situations where executives and developers had a reality check and watched as their applications exposed the figurative keys to the kingdom, both by handing over company information and allowing a network wide compromise by the Zeus family of Malware. [Story: The reality of Web development and security]
Last Friday, during a presentation titled "Dr. Evil’s Guide to Web 2.0" at Thotcon in Chicago, Los used a free tool called SWFScan, which is offered by his employer HP, to examine Flash-based applications. The tool allows anyone, legit security professional or criminal, to download and decompile a given Flash application and examine it for holes or information.
SWFScan isn’t the only tool of its kind, but it served its purpose in the talk. Those using the tool in the live examples didn’t simply discover flash-based application bugs, but another level of vulnerability – sensitive information simply hardcoded into the application itself.
A personal accounting of the talk, given by Christopher Kois, explains further.
“Rafal did a good job in pointing out that the majority of people using Flash are marketing people with just enough technical knowledge to use Flash to create web sites. The flash tools make it very simple for them to drag and drop objects on a screen, while not paying any attention to or keeping in mind any potential security vulnerabilities of allowing the client access to the compiled code,” Kois wrote on his blog. [Link]
“I was in the audience sitting very close to a guy who pointed out a website where a login and password with what appeared to be Administrative credentials could clearly be read in the decompiled flash code.”
Another example from the same talk showed a popular site making open-ended database calls in clear text via HTTP. Los explained in a blog post on the issue that by decompiling the Flash application, it was trivial to follow the code and enumerate all the data in each of the five databases discovered. [Link]
Another challenge that developers will face in the coming months are the new Flash Shared Objects (FSO), also known as Flash Cookies, Local Shared Objects, Flash Player Local Shared Objects, etc., implementations from Adobe with the pending release of Flash Player 10.1.
As part of their plans for Flash Player 10.1, due out in the first half of 2010, Adobe will deliver on promises to eliminate privacy concerns by blocking FSO use for persistent identification. Ori Eisen, chief innovation officer at 41st Parameter, noted that this will have a significant impact on most online fraud prevention efforts.
However, at the same time, when the banks move to recode security measures in their Web applications, without proper consideration, they can inadvertently expose users to risk from not only fraud, but other attack vectors.
While this example of issues in FSO usage is aimed at banks, they are not the only ones who take advantage of Flash in such a fashion, these changes will impact all Web applications, and require that they be considered in the development and security cycle.
WebAppSec tossed to the side
Los’ examples, both in the previous article and this one, are just a small sample of the issues that can plague Web Applications. However, despite those, businesses are more concerned with other things, and spend their IT dollars accordingly.
Commissioned by Imperva and WhiteHat Security, a study [Link] from the Ponemon Institute interviewed 638 IT security practitioners, and noted that while they consider theft of data to be the biggest threat to their websites, many think that their respective organizations fail to view Web security as a strategic initiative.
Of those who took part in the study, 70-percent said that the organizations they work with do not allocate sufficient funds to WebAppSec. Most of the IT funding for security goes towards network protections.
In addition, 55-percent of them say that developers are simply too busy to respond to security issues. That last percentage helps shed light on the line of thought that WebApp development and WebAppSec are two sides of the same coin.
“Applications are getting too complex,” Los explained to us during an interview on a related story. “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.
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 said.
In the study, the Ponemon Institute concluded that corporate security should join forces with business leaders to make WebAppSec an integral part of business operations.
“In addition to a serious misalignment between the risk to Web application security and the budget allocated to address the risk, we also found that developers do not have an incentive to respond to vulnerabilities in a timely fashion. For many, security is not considered as much a priority as other responsibilities they have,” the conclusion noted.
Developers are paid to code, they are given a project and expected to complete it on time and under budget. While security is important to those who code for a living, they can only secure so much at a time, and they value their jobs more than they do spending days running security audits.
It’s up to the business leaders to help this, but budgets alone won’t solve the problems. You can’t fix everything by tossing money at it.