A French security blogger gained access to private user data on personal homepage service Netvibes last weekend, exposing stored usernames and passwords for popular integrated web services as well as user content loaded in the page. The blogger’s account has since been deleted from Blog*Spot (currently cached on Yahoo!), but he provided extended details to French blog Le blog de ¥€$ (English translation). Netvibes has since claimed to patch “a security vulnerability in webnotes” exploited by this developer. I alluded to some of these issues with stored user information, phishing, and general brand confusion in a post two months ago about the popularity of available widgets regardless of their makers.
An external developer created a Netvibes module and submitted it for inclusion in the Netvibes Ecosystem module directory. A Netvibes employee examined and approved the submitted module for inclusion in the directory. The remotely-hosted module was then altered by the developer to retrieve stored preferences from other configured modules and store information from other modules loaded in the page such as the contents of a webnote, the user’s latest Gmail messages, upcoming appointments and contacts, etc. The developer stored this data in a remote database and later examined his collected findings.
A developer can choose to store and retrieve small pieces of data through the Netvibes servers such as a ZIP Code, color preference, or the username and password to remote web services. This personal data is stored in the Netvibes database and authenticated using a token stored in a Netvibes.com cookie.
This external developer was able to access other rendered content on the page, including content stored in other modules such as a user’s latest e-mails or text stored in a webnote. A Netvibes employee stored his login credentials for an internal development wiki inside of a text note on his homepage, and the third-party developer was able to read this information and access data stored inside Netvibes development servers. The developer did not access the Netvibes.com storage methods directly, but was able to gain access through the internal database.
Other web widget homepages place modules inside of an
iframe by default, creating a page within a page with restricted access to other content. It’s possible to create inline content on services such as Microsoft’s Live.com or Google Personalized Homepage but it raises an extra user warning when granting this higher level of access. A widget directory might also store an approved snapshot of the developer’s module code on their own controlled domain for quick, dependable access and reliability. Typically you want to separate the widget homepage and the widget storage into separate domains to restrict access to cookies and other information bound by a domain name.
Tips for installing new widgets and modules
The exposure of this Netvibes user data is a reminder of the tradeoffs between the demand for content and the trustworthiness of the mini-applications we add to our websites and desktops. We might be eager to unblock our PayPal account when we receive a supposed e-mail alert, so eager that you might not even recognize the unfamiliar URL requesting that data with ill will. Widget users (and toolmakers) need to apply similar caution when adding special 200 pixel squares to their homepages and blogs as well, as they are allowing a new publisher to access both the data on the page and the data he or she configures within the module. Web developers should really be using authentication proxies such as Google AuthSub or Yahoo! BBAuth instead of creating their own input boxes for user credentials on those networks.
The best bet for end-users lies in the widget directories for their platform of choice or on the websites of already trusted brand. A Gmail module produced by Netvibes or Google is likely to be more secure than a third party module and provide trusted storage of credentials and secure over-the-wire direct access to your remote data.