Edit

Communications

Mashup Security

Companies search for ways to mix data from different sources without opening themselves up to attack.

Mashups–online applications that combine data and tools from different websites–are becoming increasingly useful. Although they started out as simple consumer programs, such as a tool that placed housing listings from Craigslist onto Google Maps, mashups have grown in complexity and are becoming popular with corporations, too. As a growing number of tools are released to help people easily build mashups, experts are also taking a look at how to head off the security risks.

An insecure mix: Current methods of making mashups, which combine data and tools from multiple sources on the Web, can introduce security concerns. Experts are looking into ways to preserve the broad creative freedom that mashups offer while making them safer to use. This is of particular concern to business users who want to build mashups.

Many mashups share text only, says David Boloker, cofounder of the OpenAjax Alliance and IBM’s CTO of Emerging Internet Technologies. They risk, at worst, including incorrect or copyrighted data. However, as mashups become more complex, they’ve begun incorporating computer code from multiple sources. “At this point, we’re now bridging to untrusted code,” Boloker says. For example, a real-estate company might want a mashup to work with listings from an internal database. The mashup might run the listings through third-party tools for comparison with competitors’ prices in the same zip codes, and then use an additional third-party tool to map all the houses on the market. Without security safeguards, this mashup could make the company’s internal database vulnerable to malicious code in any of those third-party tools.

Web browsers weren’t designed with mashups in mind, and “the warts have been there from day one,” Boloker says. Browsers contain a security feature called the same-origin policy that’s meant to keep malicious code hosted on one site from grabbing data, such as stored credentials, off another site. The same-origin policy prevents websites from one domain from requesting data belonging to another domain.

However, Helen Wang, a senior researcher in the systems and networking group at Microsoft Research, explains that the same-origin policy fails by forcing “Web applications today to either sacrifice security or functionality.” She says that a lot of great functionality, such as that of mashups, comes from using tools from multiple sources. The problem is that when the website creator embeds code written by a third party on her site, the same-origin policy no longer offers any protection, and the embedded code likely has access to information stored on the creator’s site. For example, if the creator of a forum embeds a mapping application on her site, the code in the mapping application could potentially access log-in data for the forum. Mashup makers, Wang says, either give up security by accepting those risks and trusting third-party tools, or they give up functionality by denying themselves the use of untrusted tools.

Chuck Willis, principal security consultant for Mandiant, an information security firm, says that many developers would like to see some of the controls, such as the same-origin policy, relaxed. The average user needs things to stay the way they are, he says, since most users don’t understand the consequences of giving access to third-party tools. But efforts to relax existing protections need to be approached with care.

Microsoft’s Wang has been working on solving the problem by providing a way for browsers to recognize code that comes from a third party, and to treat that code differently than that from the host website. She proposes enclosing third-party code in a “sandbox” tag, which would act as a sort of one-way glass. It would allow the larger website to make use of the code contained within the sandbox but treat that code as unauthorized content, with no authority outside the sandbox. Any information that the third-party code required could be included inside the sandbox. However, in order for this solution to be effective, the sandbox tag would need to become an accepted Web standard. Wang has built a prototype of Internet Explorer that recognizes the tag, but she notes that it would take time for the tag to be adopted in all browsers.

Earlier this month, IBM released a security tool called SMash (short for “secure mashups”) that aims to solve the problem without changing the browser. SMash allows content from multiple sources to be displayed on a single page, and it enables tools to communicate in a safe way, explains Larry Koved, Web 2.0 security scientist for IBM Research. A secure communication channel monitors information sent between tools, while still maintaining their separate identities and separate sets of permissions. A mashup creator using SMash connects each tool to a hub that then takes charge of monitoring the messages sent between tools, looking for suspicious activity. Koved says that each tool included in the mashup can control how its data is transformed and presented.

SMash, says Boloker, trades off the ability to tightly interconnect widgets within a mashup in order to keep it secure and easy to make. IBM plans to incorporate SMash in its Lotus Mashups product, to be released this summer, and the company has also donated the code to the OpenAjax Alliance, which allows any mashup maker to use it.

Chris Warner, director of marketing at mashup maker JackBe, says of existing offerings, “In general, mashup security is still a bit of a Wild West.” As a member of the OpenAjax Alliance, he says, JackBe plans to support SMash and other standards released through the alliance. He adds that “the next step for the mashup industry is to make sure that we develop a universal picture of security.”

Uh oh–you've read all five of your free articles for this month.

Insider Online Only

$19.95/yr US PRICE

Communications

You've read of free articles this month.