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