Web 2.0 Security Means Fighting Malicious Third-Party Content

 
 
By Brian Prince  |  Posted 2010-07-26
 
 
 

Security questions posed by third-party content are nothing new for Website owners. But a look at how widespread third-party widgets, applications and advertisements are on the Web-and how that affects the security landscape-underscores how much of a challenge this is becoming for Web 2.0 organizations.

According to security company Dasient, a new Web page is infected every 1.3 seconds. In 2009, nearly 2 million Web pages were infected with malware every month, the company said. For site owners, many of these compromises are the result of what Dasient CTO Neil Daswani referred to in a report released July 26 as "structural vulnerabilities"-security problems caused by third-party applications, widgets and malicious advertisements that if exploited can threaten the entire site.

"Traditional implementation vulnerabilities like SQL injection or cross-site scripting can 'be fixed' by fixing the software," Daswani said. "But one of the things that's distinctive about structural vulnerabilities is that it's not anything that can really be fixed. Websites rely on third parties for part of their content and deciding not to ... use the ads typically is not an option."

In many ways, this is a new twist on an old issue, Gartner analyst John Pescatore pointed out.

"This is pretty similar to all the problems with CGI [Common Gateway Interface] scripts in the early days of Web 1.0-lots of vulnerabilities in little things like guestbooks, hit counters, etc. that get reused," Pescatore said. "First wave-lots of those have vulnerabilities and hackers exploit them. Second wave-smarter attackers put out Trojaned versions and then just exploit their own backdoor code."

Today, the same problem is occurring with content like third-party widgets.

"Websites that utilize arbitrary JavaScript-style Web widgets supplied by a third party ... are granting that third party complete DOM access equal to that of their local code," WhiteHat Security CTO Jeremiah Grossman said in a blog post July 1. "As such, the Web widgets' entire underlying hardware/software infrastructure must be included as part of the Website owners' implicit or explicit trust model."

"Organizations should have a well-defined and enforced process for vetting the security and trustworthiness of third-party Web widgets before they are deployed," Grossman wrote.

"This will require the third-party Web widget provider to legally consent to a security assessment," he noted. "Secondly, while not always possible for business reasons, Web widgets should not be used on Websites that require a high level of security assurance."

In addition, "For Internet Explorer 6 users and above, iframes support a security=restricted attribute designating that the widgets must run in the browser's Restricted Sites Security Zone," Grossman added. "Restricted Sites Security Zone prevents the running of JavaScript / VBScript ... redirecting to other sites" and other actions, he said. "If a Web Widget provider is not considered trusted ... or doesn't need this functionality, then using this feature is highly recommended whenever possible."

In the Dasient paper, the company analyzed roughly 5,000 sites and found 75 percent used third-party JavaScript widgets. Travel, entertainment and leisure sites were most likely to have them, with 99 percent of those sites found using them.

"[Attackers] can compromise one widget and then they've effectively taken every Web site, thousands, tens of thousands or even more, that already use that widget to make all those Websites part of the malware distribution platform," Daswani said.

In addition, the company found third-party advertisements are used by 89 percent of publisher sites, and 91 percent of businesses had outdated software powering their sites.

"While businesses and enterprises typically have good control over the parts of the sites that they do directly run themselves, they typically do not have as direct control over the software development life-cycle processes or other aspects of security of the third parties they use," Daswani said.

The problems this can pose can be seen for example on sites such as Facebook, which has a large third-party developer community and has taken several steps to ensure application security. In the end, Daswani said, the answer comes down to monitoring for problems as well as vetting third-party content providers. Pescatore suggested whitelisting as well.

"It's a big challenge, but not a new challenge ... What it really comes down to is AJAX code, JavaScript, widgets, gadgets and in the old days CGI scripts-all mean more moving parts for Websites, more places for vulnerabilities and malware to be inserted," the analyst told eWEEK. "More use of whitelisting is the best path forward."

Rocket Fuel