Thursday, July 01, 2010

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.

12 comments:

Pento said...

I also think that web widgets and other 3rd party code/content can become real problem for web site. There were a lot of such incidents.

Dee Watson said...

Yikes. So a DNS cache poisoning for www.google-analytics.com potentially brings you a wealth of user data from all over the intersphere.

jwilliams said...

Great article about a massively underrated risk. But it occurs to me that this is less likely and less damaging than malicious libraries on the server side-which is probably even more ubiquitous than this problem. The malicious library is easier to obscure and far more difficult to detect. But more importantly, the damage is complete application takeover-and perhaps takeover of the host and other backend systems. Yet virtually nobody looks at libraries.

Anonymous said...

http://www.gohacking.net is great hacking service! Thanks to Learn-To-Hack.com for giving me the Facebook password. I will use hack someones facebook password hacking service again. These guys are fast, professional, and trustworthy! My order was ready within 2 days of request, and I received the my husband's email account password an hour after sending my Paypal payment! Thank you Thank you! WOW fast and efficient. VERY impressed with how to hack hotmail accounts free service, I hope that I will have to use Learn-To-Hack.com but it is good to know it is available

BTW, I found another website which is providing for free a free facebook hacking software and other one specialized in hack into someone's facebook password, hack facebook account id number

Wladimir Palant said...

Note that Flash can in principle inject JavaScript code into your webpage which would have all the implications of remote JavaScript includes. Fortunately, this misfeature is no longer enabled by default (http://kb2.adobe.com/cps/403/kb403183.html). However, the embedding code offered by YouTube for example includes allowscriptaccess="always" which would open a huge XSS hole in your webpage - for no good reason from what I can tell. At least the video embedded on my webpage works perfectly fine with script access being forbidden.

Btw, you probably meant to say "but #4 - #6 remain with Flash," (not #3).

Jeremiah Grossman said...

@jwilliams: Thank you. Your probably right, bad guys will probably not use this attack vector... yet. Too many easy to find XSS, SQLi, CSRF, Clickjacking on the table... but when those dry up... look out! Your reference to evil libraries makes me think about the trusting-trust paper, scary. You know, someone really should blog that that subject. :)

@Wladimir: allowscriptaccess="always" that's right, forgot about that one. And thanks for the correction!

TeleSign Matt said...

Awesome insight into an overlooked threat.
-TeleSign Matt
http://www.TeleSign.com

Nora said...

Hi,

On the other hand, do you know of any third party widget vendors that you know of to be reliable in this area? Thanks!

Nora said...

I ask because I have been tasked with determining whether my employer (a financial institution) can utilize this as a tool for sharing our educational and PR content.

Jeremiah Grossman said...

@Nora, you mean a vendor that can monitor and track third-party widget usage on your website? If so, none that really specialize in that area no. But there are sites like http://builtwith.com/ that can be used on an ad hoc basis.

Joffemannen said...

Even though this attack vector hasn't been used very much, PCI-DSS requires you to have control of the code on your site. The server side libraries are under your control, hopefully, but for this issue I'm still looking for solutions. http://owasp.blogspot.com/2011/06/question-on-3rd-party-js.html is a start, tell me if you find more references!

Anonymous said...

I have a question!! For example my website say mywebsite.com is using 3rd party widget. when user access my website, how will I make sure whatever he is seeing is coming from my site only? I mean how will vendor check the request came from mywebsite.com? can any one hack or edit javascript and replace mywebsite widget with someone else widget and access from mywebsite?