Third-Party Web Widget Security FAQ

Millions of websites such as online news, blogs, e-commerce, banks, webmail, social networking and more utilize third-party hosted content on their webpages in the form of JavaScript, Adobe Flash, Microsoft Silverlight, HTML IFrames, and images. Often referred to as Web Widgets, common examples are banners (Google AdSense), search boxes (Yahoo), traffic counters (StatCounter), games (Pogo), videos (YouTube), Twitter / RSS feeds, user polls, security badges (VeriSign Secured Seal), social buttons (Facebook Like), etc. Tens of thousands currently exist for Web developers to choose from. While not widely understood or recognized, Web Widgets represent a serious and wide reaching security risk to websites, and their users, who use them.

Websites that utilize arbitrary JavaScript-style Web Widgets supplied by a third-party (i.e. ) 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 website owners implicit or explicit trust model. When websiteA includes a JavaScript Web Widget from websiteB, websiteB receives essentially total access over a websiteA. As Doug Crockford (Sr. JavaScript Architect, Yahoo) said, "A mashup is a self inflicted cross-site scripting attack," because just like a persistent XSS vulnerability third-party JavaScript WebWidgets may:

1. Directly access and potentially hijack user accounts by ripping off session cookies
2. Open up DOM-Based XSS vulnerabilities
3. Modify the destination of links and form submissions to log the data.
4. Steal passwords by altering what is viewed on the screen
5. Deface a webpage with false or objectionable content
6. Redirect visitors to malware laden websites with zero warning
7. Force visitors Web browsers to attack other computers on the Internet

etc.

Risks are exacerbated when or if a third-party is compromised by a malicious outsider. Consider for a moment what third-party Web Widgets are currently located on your webpages and if you believe those providers treat their security equal to or greater than your own -- because they should be. Most of the time the answer is “no” or “I don’t know.”

Either way there have been numerous occasions where millions of pieces of malware were distributed through advertising Web Widgets, in so called malvertising attacks, on networks including those belonging to Google, Microsoft, and Facebook. As a sign of the pervasiveness of Web Widgets, Google Analytics found its way onto the administrative interface of two websites belonging to the then U.S. presidential candidate Barack Obama. Simply put, Google had complete DOM access to Change.gov and BarackObama.com.

Websites that include arbitrary Flash, Silverlight, IFrames, and images supplied by a third-party face similar risks to that of JavaScript WebWidgets, but to a slightly lesser degree. With Flash, Silverlight, and IFrames remote code is executed in a different domain, the domain of the third-party, rather than the calling website. When websiteA includes a Flash, Silverlight, IFrames, or image Web Widget from websiteB, websiteB’s executed code receives no DOM read access (including session cookies) on websiteA.

There are exceptions in some cases where cross-domain communication is specifically allowed. Flash supports a allowscriptaccess=always attribute. Flash and Silverlight support a crossdomain.xml policy file where the calling website specifies what third-party hosts are trusted. Similarly Silverlight also supports a clientaccesspolicy.xml policy file and some Web Browsers / Servers support Cross-Origin Resource Sharing (CORS) that all achieve the same result.

Exceptions aside, all the aforementioned risks of JavaScript Web Widgets #1 - #3 are not present in this context, but #4 - #6 remain with Flash, Silverlight, IFrame and image Web Widgets. Case in point, the developer of John McCain's MySpace template asked to be given credit for his work and for the included images to be hosted by the campaign, rather than on his servers. Neither was done, so the developer in a display of retribution swapped one of the images giving MySpace visitors the impression that Mr. McCain reversed his official position on same sex marriages.


Enterprise Questions & Answers:

Should we be using Web Widgets?
Whenever possible, no website should include third-party Widgets from locations that they do not trust or are not trustworthy. Furthermore, website that require a high-level of security assurance should not be using Web Widgets at all unless they are prepared to treat the third-party as a trusted entity with at least the same level of due care.

How do we discover the type of Web Widgets a website(s) is currently using?
Crawl the website paying close attention to any content that is SRC’ed in from an off-domain or untrusted location, particularly using SCRIPT, IFRAME, OBJECT, EMBED, and IMAGE HTML tags.

Will anything “bad” happen by simply removing a Web Widget from a website?
Some Web Widgets contain various JavaScript libraries (i.e. Image Rollovers, object prototypes, Ajax calls, drag-drop, etc) that Web developers utilize for extended functionality. If a Web Widgets is arbitrarily removed for “security reasons” without proper testing, doing so may “break” the website. It is strongly encouraged that QA testing be performed prior to the removal of Web Widgets.

How do you check if a Web Widget is making a website(s) vulnerable to a DOM-based XSS vulnerability?
Web application vulnerability scanner has some, but very limited capability of identifying DOM-based XSS. The more comprehensive and accepted approach is by having an expert perform a manual vulnerability assessment who may use tools such as Firebug.

How do you detect if a Web Widget is distributing malware to visitors?
There are free and paid-for monitoring services, such as Armorize’s HackAlert and Dasient’s Web Anti-Malware, which periodically check if a website is either hosting or redirecting vistors to malware.

Beyond malware, how do you detect if a Web Widget is “hacking” visitors?
Currently there is no reliable method to detect (or prevent) a Web Widget from carrying out malicious activity beyond malware monitoring. Unfortunately the primary way malicious activity, including Phishing Scams and DOM-based XSS attacks, are detected is when users or websites are noticeably adversely affected.

How can unexpected Web Widget code change be detected?
At the time of this writing, there are no widely known tools capable of detecting unexpected changes to Web Widget code without a substantive departure from how they are typically deployed. Depending on the Web Widget, code changes may occur with each visitor request. Some websites have opted to locally proxy / host Web Widget traffic to obtain some visibility and control, but this approach may break some Web Widget functionality.

Is it possible to limit the permissions granted to a Web Widget?
For Internet Explorer 6 users and above, IFrames support a security=restricted attribute designating that the Web Widgets must run in the browsers Restricted Sites Security Zone. Restricted Sites Security Zone prevents running of JavaScript / VBScript, invoking ActiveX controls, sending cookies, redirecting to other sites, and so on. If a Web Widget provider is not considered trusted, trustworthy, or doesn’t need this functionality, then using this feature is highly recommended whenever possible.

What business process controls are recommended for using Web Widgets?
Organizations should have a well-defined and enforced process for the vetting the security and trustworthiness of third-party Web Widgets before they are deployed. This will require the third-party Web Widget provider to legally consent to a security assessment. Secondly, while not always possible for business reasons, WebWidgets should not be used on website that require a high level of security assurance.

What are the security risk for third-party Web Widget providers?
If the website calling in the third-party Web Widget has malicious intent they could perform a clickjacking attack. In a clickjacking attack the malicious website transparently superimposes the Web Widget over something a visitor click on (link, image, button etc). When a visitor attempts to click the link for example, they are really clicking on something invisible in Web Widget. Facebook "Like" buttons have been abused in this way. Secondly, through various DOM manipulation techniques, anything a visitor physically types could be either stolen from or redirected to a Web widget in an attack know as strokejacking. This would include comments, log-in credentials, search strings, etc.