Edit

Computing

Web Security Tool Copies Apps' Moves

Microsoft software clones the environment running on a user’s machine.

Nowadays, it’s easy for developers to build fully fledged applications that run inside the browser. Keeping these applications safe from hackers is another matter.

Play it safe: Microsoft researchers have used Ripley to secure several Web applications, including games.

With this in mind, scientists at Microsoft Research have unveiled a new way to secure complex Web applications by effectively cloning the user’s browser and running it remotely.

Many of the latest Web applications split their executable code between the server and the client. The problem is detecting whether the code running on the user’s home PC has been compromised in some way. The new Microsoft solution, known as Ripley, was announced on Tuesday at the Association for Computing Machinery’s Computer and Communications Security Conference in Chicago.

Ripley goes further than previous efforts to secure the integrity of Web applications. “It takes integrity protection to its logical extreme,” says Adam Barth, a researcher at the University of California, Berkeley who specializes in the security of Web applications. He was not involved with the project. “Instead of just verifying that a request came from the proper website, Ripley verifies that the user’s actions are actually allowed by the application’s user interface.”

Ripley prevents a malicious user or remote hacker from altering the behavior of code running inside a Web browser by creating an exact copy of the computational environment and running that copy on the server. Ripley then sends all of the user’s actions, including mouse clicks, keystrokes, and any other inputs, in a compressed “event stream” from the client to the server. This stream is run through the cloned client application on the server, and the behavior of that virtual doppelganger is compared to that of the application running on the user’s browser at home. If there are any discrepancies, Ripley disconnects the client.

“You cannot trust anything that happens in the client,” says Ben Livshits, the lead researcher at Microsoft Research on the Ripley project. “It’s basically the devil in the browser from the developer’s point of view.”

Ripley is invisible to the end user and does not affect the normal function of a Web application. “It’s only the malicious guys who have to worry about what happens once they submit a result,” Livshits says.

One of the challenges that Livshits and his collaborator at Microsoft, Emre Kiciman, faced when building Ripley was how to create a copy of the entire client environment–the Web application and software engine that runs it–that was small enough to be practical for a high-volume Web server handling requests from hundreds or thousands of users at once.

On the server, said Livshits, “if you have to run the replica within a browser, you would incur a memory footprint of 50 to 60 megabytes per browser instance.” The solution that he and Kiciman devised was to instead run a “headless browser”–an emulator that simulates only the functions of a Web browser essential to Ripley. This drove down the memory footprint of the cloned browser and application to between one and one and a half megabytes per application.

By shrinking the server-side clone of the user’s browser-based application, Livshits and Kiciman–together with colleagues from Cornell University, NY and the Indian Institute of Technology, Delhi–reduced the performance overhead of Ripley further still. Out of five experimental applications, which included a shopping cart, several games, and a blogging engine, the average increase in latency due to the increased efforts of the server’s CPU was around one millisecond.

In some cases, Ripley even enhanced the performance of Web applications, because the server-side clone of the client application is rewritten in .NET, a programming language that is 10 to 100 times faster than the JavaScript running on the client side. Sometimes this allows Ripley to predict what the next client-side application request will be before it has even been made by the client, and preemptively push data to the client.

“This is a magical situation, if you think about it,” says Livshits. “It leads to zero latency remote procedure calls.”

At present, developers interested in using Ripley to secure their Web applications would have to reimplement the ideas in the paper presented on Ripley on their own favorite Web application framework. Eventually however, Livshits and Kiciman think Ripley could help democratize an essential part of Web application security, putting it within reach of non-expert developers.

“Up until now I think people have attacked these problems manually,” says Kiciman. “You get experts who dive in and they tailor their applications to meet these challenges, but that’s not very scalable, and not very agile when you need to make changes. What we’re trying to do is get the Web development platform to a point where anyone can take advantage of the types of technology these experts are using.”

UC Berkeley’s Barth notes that Ripley is part of a larger trend in solutions that protect the integrity of client-side code by assuring that no unauthorized behavior can occur. “I see Ripley as more of a thought experiment: What would happen if the server validated everything?” he says. “The work suggests that security would benefit if we validated more than we’re validating today.”

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

Insider Online Only

$19.95/yr US PRICE

Computing

From the latest smartphones to advances in quantum computing, the hardware behind today's digital age is rapidly changing.

You've read of free articles this month.