- 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.
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.
Yikes. So a DNS cache poisoning for www.google-analytics.com potentially brings you a wealth of user data from all over the intersphere.
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.
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
Btw, you probably meant to say "but #4 - #6 remain with Flash," (not #3).
@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!
Awesome insight into an overlooked threat.
On the other hand, do you know of any third party widget vendors that you know of to be reliable in this area? Thanks!
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.
@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.
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!
Thank you for a great article! We are a team of developers, and we also take our customers' security very seriously. When developping any of our plugins, we consider a multitude of factors that will ensure the users' security. You can check out our plugins at https://elfsight.com/
Post a Comment