Web 2.0 Security Means Fighting Malicious Third-Party Content

Security issues caused by third-party content are nothing new for Website admins. 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 organisations. According to Dasient, a new Web page is infected every 1.3 seconds. In 2009, nearly 2 million Web pages were infected with malware every month, many of these compromises are the result of what Dasient calls "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, 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.

This is pretty similar to all the problems with CGI [Common Gateway Interface] scripts in the early days of Web 1.0, basically, tons of vulnerabilities in little things like guestbooks, hit counters, etc. that get reused, First wave—lots of vulnerabilities and hackers exploit them. Second wave—smarter attackers put out Trojaned versions and then exploit their own backdoor code. Now, 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, As such, the Web widgets' entire underlying hardware/software infrastructure must be included as part of the 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. This should require the third-party Web widget provider to legally consent to a security assessment, and finally, 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, Restricted Sites Security Zone prevents the running of JavaScript / VBScript ... redirecting to other sites and other actions. If a Web Widget provider is not considered trusted ... or doesn't need this functionality, then using this feature is highly recommended whenever possible.

[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. 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. The problems this can pose can be seen for on sites like  Facebook, which has a large third-party developer community and has taken several steps to ensure application security. 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, More use of whitelisting is the best path forward.